What should be on a checklist that would help someone develop good OO software?
c#, oop
Solution
Sounds like you want some basic yes/no questions to ask yourself along your way. Everyone has given some great "do this" and "think like that" lists, so here is my crack at some simple yes/no's.
Can I answer yes to all of these?
- Do my classes represent the nouns I am concerned with?
- Do my classes provide methods for actions/verbs that it can perform?
Can I answer no to all of these?
- Do I have global state data that could either be put into a singleton or stored in class implementations that work with it?
- Can I remove any public methods on a class and add them to an interface or make them private/protected to better encapsulate the behavior?
- Should I use an interface to separate a behavior away from other interfaces or the implementing class?
- Do I have code that is repeated between related classes that I can move into a base class for better code reuse and abstraction?
- Am I testing for the type of something to decide what action to do? If so can this behavior be included on the base type or interface that the code in question is using to allow more effect use of the abstraction or should the code in question be refactored to use a better base class or interface?
- Am I repeatedly checking some context data to decided what type to instantiate? If so can this be abstracted out into a factory design pattern for better abstraction of logic and code reuse?
- Is a class very large with multiple focuses of functionality? If so can I divide it up into multiple classes, each with their own single purpose?
- Do I have unrelated classes inheriting from the same base class? If so can I divide the base class into better abstractions or can I use composition to gain access to functionality?
- Has my inheritance hierarchy become fearfully deep? If so can I flatten it or separate things via interfaces or splitting functionality?
- I have worried way too much about my inheritance hierarchy?
- When I explain the design to a rubber ducky do I feel stupid about the design or stupid about talking to a duck?
Just some quick ones off the top of my head. I hope it helps, OOP can get pretty crazy. I didn't include any yes/no's for more advanced stuff that's usually a concern with larger apps, like dependency injection or if you should split something out into different service/logic layers/assemblies....of course I hope you at least separate your UI from your logic.
Problem
I have used OO programming languages and techniques years ago (primarily on C++) but in the intervening time haven't done much with OO. I'm starting to make a small utility in C#. I could simply program it all without using good OO practice, but it would be a good refresher for me to apply OO techniques. Like database normalization levels, I'm looking for a checklist that will remind me of the various rules of thumb for a 'good' object oriented program - a concise yes/no list that I can read through occasionally during design and implementation to prevent me from thinking and working procedurally. Would be even more useful if it contained the proper OO terms and concepts so that any check item is easily searchable for further information. What should be on a checklist that would help someone develop good OO software? Conversely, what 'tests' could be applied that would show software is not OO?