Object-Oriented Design – Managing Complexity with Too Many Objects

abstractionapicomplexityobject-oriented-designteamwork

I know that this will be a difficult question to answer without context, but hopefully there are at least some good guidelines to share on this. The questions are at the bottom if you want to skip the details. Most are about OOP in general.

Begin context. I am a jr dev on a PHP application, and in general the devs I work with consider themselves to use many more OO concepts than most PHP devs. Still, in my research on clean code I have read about so many ways of using OO features to make code flexible, powerful, expressive, testable, etc. that is just plain not in use here.

The current strongly OO API that I've proposed is being called too complex, even though it is trivial to implement. The problem I'm solving is that our permission checks are done via a message object (my API, they wanted to use arrays of constants) and the message object does not hold the validation object accountable for checking all provided data. Metaphorically, if your perm containing 'allowable' and 'rare but disallowed' is sent into a validator, the validator may not know to look for 'rare but disallowed', but approve 'allowable', which will actually approve the whole perm check. We have like 11 validators, too many to easily track at such minute detail.

So I proposed an AtomicPermission class. To fix the previous example, the perm would instead contain two atomic permissions, one wrapping 'allowable' and the other wrapping 'rare but disallowed'. Where previously the validator would say 'the check is OK because it contains allowable,' now it would instead say '"allowable" is ok', at which point the check ends…and the check fails, because 'rare but disallowed' was not specifically okay-ed.

The implementation is just 4 trivial objects, and rewriting a 10 line function into a 15 line function.

abstract class PermissionAtom {
public function allow(); // maybe deny() as well
public function wasAllowed();
}

class PermissionField extends PermissionAtom {
public function getName();
public function getValue();
}

class PermissionIdentifier extends PermissionAtom {
public function getIdentifier();
}

class PermissionAction extends PermissionAtom {
public function getType();
}

They say that this is 'not going to get us anything important' and it is 'too complex' and 'will be difficult for new developers to pick up.' I respectfully disagree, and there I end my context to begin the broader questions.

So the question is about my OOP, are there any guidelines I should know:

  1. is this too complicated/too much OOP? Not that I expect to get more than 'it depends, I'd have to see if…'
  2. when is OO abstraction too much?
  3. when is OO abstraction too little?
  4. how can I determine when I am overthinking a problem vs fixing one?
  5. how can I determine when I am adding bad code to a bad project?
  6. how can I pitch these APIs? I feel the other devs would just rather say 'its too complicated' than ask 'can you explain it?' whenever I suggest a new class.

Best Answer

I quite like this question, but I don't think it is really about OO or APIs. It's about being a junior or a new member of a team and having input (either ideas or past experience) that the other team members aren't agreeing with.

I'll answer your questions:

  1. Doesn't appear to be
  2. When the problem doesn't warrant any more abstraction
  3. When the problem does warrant more abstraction
  4. Experience
  5. Experience
  6. Explain it, demonstrate it, describe the risks and benefits of it.

That is all very deliberately vague. Abstractions add complexity and remove complexity at the same time - just different types of complexity. The correct application depends on your business, product, team, and so on.

Your teammates may not support your idea for a number of reasons:

  • the idea won't work, is incorrect or bad practice, or is just rubbish (your competence)
  • there are business or system reasons why the idea won't work (your experience)
  • they don't see the benefits of the idea or the risks of not adopting the idea (their experience)
  • they refuse to or cannot understand the idea (their competence)
  • they are asserting their seniority or position (political)

A political or competence problem falls outside the scope of any technical discussion of the idea, is a management issue, and I hope that's not the problem. It's very likely that this is an experience issue. This doesn't mean that you don't have enough experience, or they don't have enough experience, but there's a disconnect somewhere which causes you to see this as a good idea but others to see it as a bad idea.

What do you do in this situation? You discuss the idea. If they aren't willing to discuss the idea with you (and you should give them the opportunity to dissect it, destroy it for you so you can learn from them) then see above (political or competence reasons). Have a frank and open discussion about the alternatives, particularly with respect to implementation difficulty and future flexibility. It's not your idea vs their idea; there are two approaches on the table and the team must decide between them.

Related Topic