Every description I have read about god classes considers them to be an anti-pattern and a bad practice. Most descriptions I have read about mixins considers them to be acceptable in some cases. If the functionality of a god class is broken up into several mixins, each mixin can be separately unit tested and separation of concerns is still maintained, at least to some degree. When it comes down to it, I'd still like to encapsulate all of the functionality into one object. I'd like to get opinions on this design. Is this design a bad practice?
8
-
5Why do you want one object?– JimmyJamesCommented Nov 20, 2017 at 17:17
-
To encapsulate all of the functionality. That being said, the functionality can be broken up into very distinctive and logically separated modules. If it helps, the name of the god class is 'project'. Given a project object, I'd like to call func1 and func2 on that object, where func1 and func2 belong to different mixins because they are logically very different.– J. DarnellCommented Nov 20, 2017 at 17:23
-
6@J.Darnell: If they are logically very different why do you want them on the same object? What are you trying to achieve by this?– JacquesBCommented Nov 20, 2017 at 17:54
-
2Or to pose @JacquesB 's question from a slightly different angle, why would you not want different functionality split out into different classes? What issues are you concerned about with regards to splitting your application into logically separate components?– Ben CottrellCommented Nov 20, 2017 at 18:03
-
3@J.Darnell: You don't give any reason why you can't just use composition, so I will go ahead and say your use of a God class is bad practice. Let the logically separate components be properties of the project object.– JacquesBCommented Nov 20, 2017 at 18:35
|
Show 3 more comments
2 Answers
Sorry to be the bearer of bad news:
Yes.
The larger your application gets, the more trouble this will cause. What happens when you try to name a method do_thing, import it into your god class, and find that it already has a method named do_thing? Now you have to worry about namespace collisions in your god class: what a pain!
Another (small) one: if everything goes here, and multiple people are working on different modules, but everyone has to "register" things in your god class, then you will be dealing with lots of unnecessary merge conflicts for that class in your code repository. If separate things were always separate, then you have less to worry about from people stepping on eachother's toes.
These are just a few things that come to mind. Really though, you are approaching it from the wrong perspective: why would you want to do this? If you have everything nicely separated and organized, why would you want to undo all of that and throw it all into a single class? Doing this might save you a few import statements at the top of your code, or a few less dependencies that need to be injected, but none of that is substantially improving your code base, and it comes at a real cost. It's a simple formula: cost + no benefit = bad idea. You're already doing the "hard" part of dividing your application nicely. Don't mess that up on the home stretch.
-
As a result, instead of using god_object.some_func(), it might look like
obj = god_object.get_some_object()thenobj.some_func(). This is less preferable to me but would fix the namespace conflict issue. I still call it god_object because I want to encapsulate all of the functionality into one object. There are a number of things you can do with a project and I would like them all to be available given a project object. Commented Nov 20, 2017 at 18:19 -
If the project class did not exist, I believe the existing mixins would just become normal classes on their own. I would then have to come up with a way to identify what project each mixin class is supposed to be associated with. I think this complicates things. Commented Nov 20, 2017 at 18:21
-
2You are describing the process of design. After design, things will be much less complicated. Trust me. Commented Nov 20, 2017 at 18:23
-
1@J.Darnell I think the issue is that you have some higher-level organization concerns to work through, which probably won't be possible in this one question. Having managed large applications (hundreds of thousands of lines of code), I've never had reason to fall back on God classes of any sort. Once things get that large, you just can't: you either figure out how to organize your application or it becomes very painful. Commented Nov 20, 2017 at 18:24
-
@BobDalgleish Okay, there is a consensus that my design is not great. What is the right design then? I understand that is probably not answerable with the limited details I have given here. I have explained some of the behavior that I would like though. Commented Nov 20, 2017 at 18:25
From your comments, it sounds like you might want to approach this from the perspective of an IoC Container. If your application has a set of functionality available within it, and you need to have pieces, determined at run time, use that functionality, the best approach is likely a an inversion-of-control container with dependency injection.
- Your application consists of a set of libraries, likely individual objects that are tied together into larger functionality.
- The functional groupings conform to the mixins that your described earlier.
- Individual "project" classes will be added to the application for specific command-control-reporting functions, and as those projects are added in, their dependencies on those interfaces will be bound, using dependency injection.
- Each project class will run in the environment as if it has access to the various different interfaces. Control will pass back and forth between the main application and project class.
This is sometimes called an application framework.
answered Nov 20, 2017 at 18:42
-
I still make project classes then? I imagine the methods of that class would do nothing but wrap the functionality of the libraries underneath. From my brief study of IoC, it appears to be more abstraction than necessary for my application but I may be wrong. Commented Nov 20, 2017 at 18:54
-
Since I don't know what your project classes do, I cannot comment further. However, the IoC container approach avoids the god-class abomination. Commented Nov 20, 2017 at 19:01
-
The point isn't simply to wrap a libraries functionality. It's to clearly express that all you need from this messy library are these 2 or 3 little things and you don't really care which library does that for you. That way when the boss says we can't get licenses for this anymore you don't have to reinvent the whole library. Look up the interface segregation principle. As for mixins: if you've mastered a hammer beware of screws. Commented Nov 20, 2017 at 21:31