Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Problem Summary:

Long story short, I inherited a code base and a development team I am not allowed to replace and the use of God Objects is a big issue. Going forward, I want to have us re-factor things but I am getting push-back from the teams who want to do everything with God Objects "because its easier" and this means I would not be allowed to re-factor. I pushed back citing my years of dev experience, that I'm the new boss who was hired to know these things, etc, and so did the third party offshore companies account sales rep, and this is now at the executive level and my meeting is tomorrow and I want to go in with a lot of technical ammo to advocate best practices because I feel it will be cheaper in the long run (And I personally feel that is what the third party is worried about) for the company.

My issue is from a technical level, I know its good long term but I'm having trouble with the ultra short term and 6 months term, and while its something I "know" I cant prove it with references and cited resources outside of one person (Robert C. Martin, aka Uncle Bob), as that is what I am being asked to do as I have been told having data from one person and only one person (Robert C Martin) is not good enough of an argument.

Question:

What are some resources I can cite directly (Title, year published, page number, quote) by well known experts in the field that explicitly say this use of "God" Objects/Classes/Systems is bad (or good, since we are looking for the most technically valid solution)?

Research I have already done:

  1. I have a number of books here and I have searched their indexes for the use of the words "god object" and "god class". I found that oddly its almost never used and the copy of the GoF book I have for example, never uses it (At least according to the index in front of me) but I have found it in 2 books per the below, but I want more I can use.
  2. I checked the Wikipedia page for "God Object" and its currently a stub with little reference links so although I personally agree with that it says, it doesn't have much I can use in an environment where personal experience is not considered valid. The book cited is also considered too old to be valid by the people I am debating these technical points with as the argument they are making is that "it was once thought to be bad but nobody could prove it, and now modern software says "god" objects are good to use". I personally believe that this statement is incorrect, but I want to prove the truth, whatever it is.
  3. In Robert C Martin's "Agile Principles, Patterns, and Practices in C#" (ISBN: 0-13-185725-8, hardcover) where on page 266 it states "Everybody knows that god classes are a bad idea. We don't want to concentrate all the intelligence of a system into a single object or a single function. One of the goals of OOD is the partitioning and distribution of behavior into many classes and many function." -- And then goes on to say sometimes its better to use God Classes anyway sometimes (Citing micro-controllers as an example).
  4. In Robert C Martin's "Clean Code: A Handbook of Agile Software Craftsmanship" page 136 (And only this page) talks about the "God class" and calls it out as a prime example of a violation of the "classes should be small" rule he uses to promote the Single Responsibility Principle" starting on on page 138.

The problem I have is all my references and citations come from the same person (Robert C. Martin), and am from the same single person/source. I am being told that because he is just one guy, my desire to not use "God Classes" is invalid and not accepted as a standard best practice in the software industry. Is this true? Am I doing things wrong from a technical perspective by trying to keep to the teaching of Uncle Bob?

God Objects and Object Oriented Programming and Design:

The more I think of this the more I think this is more something you learn when you study OOP and it's never explicitly called out; Its implicit to good design is my thinking (Feel free to correct me, please, as I want to learn), the problem is I "know" this, but but not everybody does, so in this case its not considered a valid argument because I am effectively calling it out as universal truth when in fact most people are statistically ignorant of it since statistically most people are not programmers.

Conclusion:

I am at a loss on what to search for to get the best additional results to cite, since they are making a technical claim and I want to know the truth and be able to prove it with citations like a real engineer/scientist, even if I am biased against god objects due to my personal experience with code that used them. Any assistance or citations would be deeply appreciated.

share|improve this question
4  
Ask them for documentation of God objects as good practice. –  Don Roby Dec 2 '12 at 19:05
15  
Run away! You don't want to work there. –  Don Roby Dec 2 '12 at 19:25
2  
Please define your understanding of "God Object" and how it relates to your question. You spend 4 paragraphs saying that God Class isn't a standard term in the literature. Then why are you using it? If you use industry standard terms, and can show how those concepts apply to your current project, then you might convince some people of your point. Using made-up words in a business meeting is only going to undermine your argument. Industry standard terms exist - you aren't the first person to ever see an everything-is-global or single-object nightmare, or whatever you are trying to describe. –  GlenPeterson Dec 5 '12 at 2:49
6  
You're missing the term "antipattern". Doing a Google search for "god object antipattern" returns tons of pages on reasons why they're bad. –  Izkata Dec 5 '12 at 3:14
5  
You shouldn't be attacking the god object but the problems it creates. Like: we have very tight coupling between everything and a change in A requires also changes in B,C and D. So, to help against that we're going to extract classes. Or: we want the code to be in a testing framework, and we can't do that, what are we going to do? Also, try avoid using the term "God", people not receptive will think you're using hyperboles. –  Pieter B Dec 5 '12 at 8:14
show 5 more comments

migrated from stackoverflow.com Dec 5 '12 at 1:53

This question came from our site for professional and enthusiast programmers.

5 Answers

You could always ask Uncle Bob himself.

The thing is, it's so obvious to people with any sense that once it's spelled out, it doesn't need to be re-referenced by a multitude of authors. There need only be one source.

Other terms you might want to start with when looking for sources are:

  • SOLID
  • Law of Demeter
  • Big Ball of Mud

All of these express related concepts that might yield viable reference sources, even though they don't actually name it as such.

Ultimately though, you're the boss. The reason for doing it is because you say so, and although to be considered a good manager you really should be prepared to justify your decisions; you've done that, and if there is still resistance, the correct course of action is for your team to do as they're told.

share|improve this answer
    
"if there is still resistance, the correct course of action is for your team to do as they're told" Maybe the correct course of action is to quit rather than making your team miserable..? –  Tom Dec 2 '12 at 20:11
    
The manager's decision has been adequately justified, and if the team don't agree, then the problem is with the team. The OP was hired for his expertise and not being allowed to use it to benefit the business because colleagues won't behave reasonably isn't acceptable. Let's turn your assertion on its head - why shouldn't the resistant team members quit if their view of the job is incompatible with that of the business? –  Tom W Dec 2 '12 at 20:21
2  
Fair point. It depends how you want to run the team. But in my experience forcing people to do things against their will just leads to misery. I would rather see God Objects throughout the code base than a miserable development team. Maybe the answer is to send them on a training course. Everybody loves a training course. Win-win. –  Tom Dec 2 '12 at 20:55
    
The lead developer/manager/whatever should absolutely take all reasonable measures to ensure that the team retain a good working relationship with one another. If additional training is helpful, then by all means consider it as an option - but this seems to be like a case of wilful ignorance, and telling someone they need to be trained to understand your idea when what they think they've done is disagree, rather than not understand, could backfire. I have a hard time imagining ways of dealing with people who don't want to learn. –  Tom W Dec 4 '12 at 14:17
add comment

The case for any change of practice is made by identifying the pain points created by the existing design. Specifically, you need to identify what is harder than it should be because of the existing design, what is fragile, what is breaking now, what behaviors can't be implemented in a simple manner as a direct (or even somewhat indirect) result of the current implementation, or, in some cases, how performance suffers, how much time it takes to bring a new team member up to speed, etc.

Second, working code trumps any arguments about theory or good design. This is true even for bad code, unfortunately. So you're going to have to provide a better alternative, which means you, as the advocate for better patterns and practices, will need to refactor to tease out a better design. Find a narrow, tracer-bullet style plane through the existing design, and implement a solution that, perhaps, for iteration one, keeps the god object implementation working, but defers actual implementation to the new design. Then write some code that takes advantage of this new design, and show off what you win because of this change, whether it's performance, maintainability, features, correction of bugs or race conditions, or reduction of cognitive load for the developer.

It's often a challenge to find a small enough surface area to attack in poorly architected systems, it may take longer than you'd like to deliver some initial value, and the initial payoff may not be that impressive to everybody, but you can also work on finding some advocates of your new approach if you pair on it with team members that are at least slightly sympathetic.

Lamenting the God Object only works when you're preaching to the choir. It's a tool for naming a problem, and only works for solving it when you've got a receptive audience that's senior and motivated enough to do something about it. Fixing the God object wins the argument.

Now that I have more than 5 minutes to write, I'm editing my answer to add: Since your immediate concern appears to be executive buy-in, I think you're best off making a case that replacing this code needs to be a strategic goal and tie those to the business objectives that you're responsible for. I think you can make a case that you can provide some technical direction by first working on a technical spike on what you think should be done to replace it, preferably involving resources from one or two technical people that have reservations about the current design.

I think you've found enough resources to justify your argument; people in such meetings will only pay attention to summary of your research, and they'll stop listening after you mention two or three corroborating sources. Your focus initially should be in getting buy-off to work the problem you see, not necessarily proving someone else wrong or yourself right. This is a social problem, not a logical one.

In a technology leadership role, you need to tie any of your initiatives to business goals, so the most important thing for making your case to executives is what the work will do for those objectives. Because you're also considered the "new guy," you can't just expect people to throw away their work or expect to rapidly fall in line; you need to build some trust by proving that you can deliver. As a long term concern, ia leadership role, you also need to learn to become focused on results, but not necessarily be attached to the specifics of the outcome. You're now there to provide strategic direction, remove tactical obstacles from progress by your team, and offer your team mentorship, not win battles of credibility with your own team members.

Making a top-down decision will rarely be credible unless you have some skin in the game; if you are in a similar situation all over again, you should focus more on consensus building within your organization rather than escalating once you feel the situation is out of control.

But considering where you are now, I'd say your best bet is to argue that your approach will bring measurable long-term benefits based on your experience and that it's in line with the work by well-known practitioners like uncle Bob and co., and that you'd like to spend a few days/weeks leading by example on a narrow refactoring of the highest bang-for-buck aspect, to demonstrate what your view of good design should look like. You'll need to align whatever your case is to specific business goals beyond your personal preferences, however.

share|improve this answer
2  
Good point about it being a social problem. Must be why there is so much bad written code and poorly designed applications out there. –  Yanick Rochon Dec 5 '12 at 11:57
2  
+1 for tying it in with 'business speak' as such; aim to make it as relevant to your audience as you can. If you're talking to executives then do talk about how the standard of code has a direct link with maintenance and performance, and do discuss how this ties in with overall project finances, long-term stability and so on. It sound like you've been hired because of your knowledge; remember this. (Just don't become a jerk-off manager who thinks he always knows best - but in this instance you're 100% correct.) –  Fergus Morrow Dec 6 '12 at 16:55
1  
+1 for "working code trumps any arguments about theory or good design." Something we often forget in our quest for perfect code. –  bjarkef Feb 10 '13 at 11:18
add comment

First, you need to present that any measurable organisation need to adopt industry best practices. Saying that "it just works for us!" cannot be measured, neither in time or in resource as it is simply unpredictable. Software engineering is a science as much as any other fields of science, and these concepts have been studied, researched, tested, and documented.

  1. the God Object is an anti-pattern which states that

    In software engineering, an anti-pattern (or antipattern) is a pattern used in social or business operations or software engineering that may be commonly used but is ineffective and/or counterproductive in practice.

  2. In the Google IO conference of 2009, this subject was partially explained when the MVP pattern was explained. It may not be relevant to the God Object, but may give you some ammo.

  3. Also, using this anti-pattern violates the single responsibility principle in object-oriented designs, which states that :

    every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

  4. The Decaying Code blog also talks about this and about it's solution.

  5. We cannot talk about the single responsibility principle without talking about object coupling.

    [...] coupling or dependency is the degree to which each program module relies on each one of the other modules.

    Where having a tightly coupled system may cause assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. A higher level of object couping means less cohesion, and vice versa. God objects are a good example of tight coupling as they know more than they should, thus overloads them with responsibility, thus limit greatly code reusability.

  6. When designing a complex application, simplicity must come to mind. Big problems must be decomposed into smaller ones, which are easier to manage, test, and document. This is especially true in an object-oriented paradigm.

    With this argument, we do loop back to the anti-pattern argument, but this paradigm is all about patterns, real world object representation and, ultimatly, data encapsulation.

  7. You are part right when you say that these "good practices" are more existent in classrooms. However, I do have teaching experiences in college (and some university) and I only saw these principles being taught in universities, especially in engineering faculties. Which is sad. But like any good practice, those who strive to better themselves usually learn some basic design patterns, and eventually understand how to jungle between coupling and cohesion.

    What I usually teach to students is that, it may seem to require more efforts to adopt good programming standards, but it always pay off in the long run. A good example would be someone asking a programmer to write a sorting function. The programmer has two choices; 1) write a quick bubble sort function (less than 5 minutes) that will not be sustainable as the list of elements grow, or 2) write a more complex (aka optimized) sorting algorithm (quick sort, etc.) that will scale better with bigger lists.

share|improve this answer
add comment

You could cite some of the most basic OOP principals such as loose coupling and high cohesion. A "God object" sounds like it couples unrelated classes and has low cohesion.

share|improve this answer
add comment

You may want to see guru of the week #84. It's all about god objects (monoliths) and how they are bad.

Extract: (Major) It isolates potentially independent functionality inside a class [...] (Minor) It can discourage extending the class with new functionality [...]

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.