Shall the environment be global? - Object

Responding to DeMarcus...

> Most applications have a need for an environment entity to store
> application global accessible parameters, factories, devices,
> preferences, etc.

I would avoid having a single such entity if there is a lot of
environmental information. Putting everything in one entity defeats the
way the OO paradigm avoids the traditional problems of access to global
data.

The OO paradigm uses relationship participation to limit access to data.
But if the data is in a single object, then everyone who needs any of
the data must have a relationship path to navigate to the same entity.
IOW, everyone participates in relationships to the object and one has
the equivalent of a FORTRAN COMMON.

Break up the environmental data by subject matter context and put it in
multiple objects that have limited relationship paths to just the
objects that need that data.

> Shall the parameters be globally accessible from a singleton environment
> class? Or shall the environment always be passed on to instances that
> need access? e.g. new SpreadSheetWindow( environment )

You probably don't need a Singleton. Typically environmental data is
initialized only at startup, so there would be no opportunities to
create clones in the main solution processing.

Passing object references in collaboration messages is usually a bad
idea because it represents the worst form of coupling. In this case that
is less of a problem because the entity is presumably just a dumb data
holder. Nonetheless, having the object needing the data navigate
directly to it on an as-needed basis ensures consistency in data access.

<aside>
There are some practical advantages for doing so. Relationships have
roles in the OOA/D so when maintenance is done the developer needs to
think about whether the access is consistent with that role, which helps
avoid inadvertent abuse of the data.

More important, when one uses DbC to rigorously define flow of control
in the solution (e.g., among object state machines), one can separate
the timeliness of the data as an issue for DbC preconditions for
executing the receiver method. One must then check that the data object
has been updated properly for the receiver context. Psychologically when
a reference is passed there is a tendency to assume that the sender has
already ensured that it was updated properly. If you are into defect
prevention in software development, eliminating opportunities to be
careless is important.
</aside>

--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.lahman@verizon.net

"H. S. Lahman" <h.lahman@verizon.net> wrote in
news:WzjSk.866$U5.516@nwrddc01.gnilink.net:

> Responding to DeMarcus...
>
>> Shall the parameters be globally accessible from a singleton
>> environment class? Or shall the environment always be passed on
>> to instances that need access? e.g. new SpreadSheetWindow(
>> environment )
>
> You probably don't need a Singleton. Typically environmental
> data is initialized only at startup, so there would be no
> opportunities to create clones in the main solution processing.
>
> Passing object references in collaboration messages is usually a
> bad idea because it represents the worst form of coupling. In
> this case that is less of a problem because the entity is
> presumably just a dumb data holder. Nonetheless, having the
> object needing the data navigate directly to it on an as-needed
> basis ensures consistency in data access.
>

Could you elaborate on the approach you are recommending?

For "the object needing the data to navigate directly to it on
an as-needed basis", doesn't it need a reference to the object
containing the data, as shown in the example where the environment
object is being passed to the new object's c'tor?

Perhaps I have missed something.

MV

--
I do not want replies; please follow-up to the group.