Question

I am running into a design disagreement with a co-worker and would like people’s opinion on object constructor design. In brief, which object construction method would you prefer and why?

    public class myClass     {         Application m_App;          public myClass(ApplicationObject app)          {               m_App = app;         }           public method DoSomething         {           m_App.Method1();          m_App.Object.Method();        }     } 

Or

    public class myClass     {         Object m_someObject;         Object2 m_someOtherObject;          public myClass(Object instance, Object2 instance2)          {               m_someObject = instance;               m_someOtherObject = instance2;         }           public method DoSomething         {           m_someObject.Method();          m_someOtherObject.Method();        }     } 

The back story is that I ran into what appears to be a fundamentally different view on constructing objects today. Currently, objects are constructed using an Application class which contains all of the current settings for the application (Event log destination, database strings, etc…) So the constructor for every object looks like:

public Object(Application) 

Many classes hold the reference to this Application class individually. Inside each class, the values of the application are referenced as needed. E.g.

Application.ConfigurationStrings.String1 or Application.ConfigSettings.EventLog.Destination 

Initially I thought you could use both methods. The problem is that in the bottom of the call stack you call the parameterized constructor then, higher up the stack, when the new object expects a reference to the application object to be there, we ran into a lot of null reference errors and saw the design flaw.

My feeling on using an application object to set every class is that it breaks encapsulation of each object and allows the Application class to become a god class which holds information for everything. I run into problems when thinking of the downsides to this method.

I wanted to change the objects constructor to accept only the arguments it needs so that public object(Application) would change to public object(classmember1, classmember2 etc...). I feel currently that this makes it more testable, isolates change, and doesn’t obfuscate the necessary parameters to pass.

Currently, another programmer does not see the difference and I am having trouble finding examples or good reasons to change the design, and saying it’s my instinct and just goes against the OO principles I know is not a compelling argument. Am I off base in my design thoughts? Does anyone have any points to add in favor of one or the other?

Answer 1

Hell, why not just make one giant class called ‘Do’ and one method on it called ‘It’ and pass the whole universe into the It method?

Do.It(universe) 

Keep things as small as possible. Discrete means easier to debug when things inevitably break.