Too complex/too many objects?
- by Mike Fairhurst
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:
is this too complicated/too much OOP? Not that I expect to get more than 'it depends, I'd have to see if...'
when is OO abstraction too much?
when is OO abstraction too little?
how can I determine when I am overthinking a problem vs fixing one?
how can I determine when I am adding bad code to a bad project?
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.
