<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote
cite="mid:CAOfpbvFu_FC_ChLPQ5jPr=ZM4EgPTLGJb6PY_O=om9AMt5zotQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, these global objects force us to do a bunch of hacks
in unit<br>
tests. We need to do tricks to ensure the object is
initialized as<br>
we want. We also need to save and restore its state
between runs.<br>
</blockquote>
<div><br>
</div>
<div>
<div>I don't agree with the statement that they force "a bunch
of hacks," clearing</div>
<div>state is a perfectly normal thing to do, it is done for
any servers that get</div>
<div>started, any mocks that are made, and every test
database. Making sure that</div>
<div>modifications to a configuration object are cleaned up is
no different: there</div>
<div>is no "save and restore" just always start from a blank
slate and set things</div>
<div>as required, same as in the non-global model.</div>
</div>
<br>
</div>
</blockquote>
But ensuring that we are back at tabular rasa is difficult with
global objects and running tests in a single process space. Many of
the test cases are dependant on second order effects of function
calls to configure internal objects, instead of being true unit
tests that only call on a single object.<br>
<br>
This kind of refactoring is the norm in large projects, and leads
to better tested code paths, reusuable objects, and objects that
are easier to understand and track.<br>
<br>
One way that these types of things have been described is via the
SOLID acronym. THis is a collection of best practices:<br>
<br>
<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29">http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29</a><br>
<br>
The Global config violates quite a few of these principals. By
reading from a configuration object, you implicitly violate Single
responsibility. Now it has at least two, one of which is figuring
out how to construct and initialize itself. It also doesn't really
follow the Open Closed principal: Once you get state from a Config
object, you can no longer easily extend it, unless that extended
object also gets its state from the same config. The big one is D:
Dependency. By using a global config, you make dependencies on
implementations, not abstractions. Dependency injection is pretty
much impossible with a global config. <br>
<br>
<br>
Keystone really stands to benefit from reusability. An example:
right now, we can only have one SQL Datasource, but it is likely
that some users would have one data source for Identity and a
different one for Tokens. That same set up has been describved for
LDAP: Using a centralized LDAP server for Authentication, but a
local one for Authorization. To do that, we have to split the LDAP
config (and allow multiple) from the Identity config. <br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>