Instantiating objects with a Configuration class or with Parameters

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

My view is that you give the class the smallest set of "stuff" it needs for it to do its job. The "Application" method is easier upfront but as you've seen already, it will lead to maintainence issues.

Answer 2

I wouldn't go so far as to call the Application object a "god" class; it really seems like a utility class. Is there a reason it isn't a public static class (or, better yet, a set of classes) that the other classes can use at will?

Answer 3

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. Discreet means easier to debug when things inevitably break.

Answer 4

I thing Steve McConnel put it very succintly. He states,

"The difference between the 'convenience' philosophy and the 'intellectual manageability' philosophy boils down to a difference in emphasis between writing programs and reading them. Maximizing scope may indeed make programs easy to write, but a program in which any routine can use any variable at any time is harder to understand than a program that uses well-factored routines. In such a program you can't understand only one routine; you have to understand all the other routines with which that routine shares global data. Such programs are hard to read, hard to debug, and hard to modify." [McConnell 2004]