Creating objects with a configuration class or with parameters

I ran into constructive disagreement with a colleague and would like to hear people's opinions on the construction of an object constructor. In short, which method of constructing an object 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 story backwards is that I was confronted with what appears to be a fundamentally different view of object construction today. Currently, objects are created using the Application class, which contains all the current settings for the application (event log destination, database strings, etc.). Therefore, the constructor for each object looks like this:

public Object(Application)

      

        
        
        
      

    

Many classes contain a link to this application class separately. Within each class, application values ​​are specified as needed. For example.

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

      

        
        
        
      

    

At first I thought that you can use both methods. The problem is that at the bottom of the call stack, you call the parameterized constructor, and then at the top of the stack, when a new object is waiting for an application object reference, we encountered a lot of null reference errors and saw a design flaw.

My feeling when using an application object to set each class is that it breaks the encapsulation of each object and allows the Application class to become a god class that contains all the information. I run into problems when I think about the disadvantages of this method.

I wanted to change the constructor of the objects to only accept the arguments it needs, so that it public object(Application)

changed to public object(classmember1, classmember2 etc...)

. Currently I feel it makes it more testable, isolates changes, and doesn't obfuscate the required parameters to pass.

Currently, another programmer cannot see the difference and I am having trouble finding examples or good reasons to change the design and say this by my instinct and is simply contrary to OO principles, which I know are not a valid argument. Am I not at the heart of my design thoughts? Does anyone have any points to add in favor of one or the other?