Re: Really "BIG" class name wanted
markspace <-@.> writes:
But in general I've found that defining an ApplicationContext with
smaller objects like Configuration, Persistence, Gui, etc. makes it easy
to decouple large modules in the code, as well as makes it convenient on
the programmer, since there's only one object to pass around and keep
track of, and it has your entire context in it.
I have an object of an interface I call ?environment? that I
pass around a lot in my code.
Here, a ?main? method obtains a default environment:
final de.dclj.ram.system.environment.Environment environment
= new de.dclj.ram.system.environment.DefaultEnvironment()
. Code can use an environment to report errors:
environment.reportError( "Missing type in " + source + "\n" )
, or pass it to other objects:
htmlGen = new HtmlGen( environment )
. My environment has a ?default output? (which is the
console, when the default environment is used). Here is
(simplified) example code, which changes the default output
during the call of a method.
outputStreamWriter = new java.io.OutputStreamWriter( fileOutputStream, "UTF-8" );
environment.pushOutput( outputStreamWriter );
rendoweb.write( environment );
environment.popOutput();
outputStreamWriter.close();
One can see ?popOutput()? above, which restores the previous
environment.
(Recently, in this newsgroup, there has been a suggestion to
have a property getter for every property setter, so that
the client can save and restore a previous value of a
property. The above push-and-pop solution shows another way
how to achieve this, which also realizes ?Tell, Don't Ask.?
with respect to that property.
Not changing a property at all, but deriving another
temporary environment object would be another means to
realize this, which would even be more threadsave.)