I have been working on refactoring old code and found a lot of instances of the

Question

I have been working on refactoring old code and found a lot of instances of the following type of situation: There is a master object which we call "Application" and there is only one of these. The Application will create other objects called "Features" inside it depending on user input etc. The Feature object may have some methods that take void parameters but actually operate on or use some variables in the scope of Application. This is because the functions defined in class Feature are defined in the same project and include the header from Application (this is C++). Here is a rudimentary attempt to show a simple example pseudocode:

int main()
{
    Application theApp = new Application()

    the.App.someSetting = foo;
    the.App.someVariable = bar;

    the.App.RunSomeFeature();
}
// RunSomeFeature function def in class Application
void Application::RunSomeFeature()
{
    // create object of type feature
     Feature feature = new Feature();

    feature.SomeFunction(void)
}
// SomeFunction def in class Feature
void Feature::SomeFunction(void)
{
    // global variable from Application "creeping in"
    someLocalVariable = theApp.someSetting;
    otherLocalVariable = theApp.someVariable;
}
I hope this illustrates somewhat what I mean. My goal is essentially to move the class "Feature" to some location outside the namespace of "Application" (to a dll for example) and I can not include Application header (since that would defeat the purpose of the separation). But since there are these types of globals everywhere in the old code this task is rather complicated. This may be a C++ thing for all I know that it is easy (or posible) to make this coding mistake but I am not sure.

This made me think of a few questions regarding OOP design. Well designed OOP code would only have completely autonomous classes and functions with all outside variables explicitly passed in? Even if one object will be created inside another? I can see that way the entire code would be much easier to internally "reshuffle". But sometimes there may be a lot of parameters to be passed and since "Feature" is created by "Application" anyway I see why my situation might arise. But code written as in the example implicitly joins class Application and Feature to the same overall "block" or scope and it takes line by line work sometime to separate them.

However the other extreme would be that each class is essentially almost an autonomous application in its own right (and this may go somewhat against the idea of inheritance). When I read about OOP design principles, I usually don't find this particular nuance talked about much or I just get the idea that everything should be basically autonomous but I find that in practice this is rarely truly so.

I see that this may be a bit open ended but any rules of thumb about at what level would we "completely encapsulate" in order to have pieces of code we can reshuffle easily? Or any design philosophy anyone would share about this type of situation?

Explanation / Answer

What you are after is not very specific for OOP, and has absolutely nothing to do with inheritance. You are after proper modularization. Each of your features should be a component, that means either a single class, or a group of classes, with a well defined interface, and not directly dependent on the Application object.

In the current situation each feature depends on Application, and Application depends on each feature, so every feature depends essentially on every other feature, which makes it impossible to test single features in isolation. Eliminating the direct dependencies of the features from the Application object and passing data in and out through the components interfaces will change that situation. If you do this right, you will end up with lots of independent components, where you can change and test each of it independently from each other, with a much lower risk of breaking your program when you are going to change something.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.