This is my list of coding & design principles I remind myself of whenever I feel coding my app is getting too complicated. Essentially, this list helps me apply the principle of orthogonality.
1. Stop repeating yourself – reorganise your object(s) so that you don’t find yourself copying/pasting chunks of code.
2. What does your method do? If it does 2 things, it should be 2 methods.
3. Private is good – you wouldn’t show your underwear to anybody in the street, don’t show your variables and methods unless you have to.
4. Isolate your constraints – keep them all in a method called “initialise()”, which you can call from your constructor (or from onCreate() if you’re programming from Android).
5. Isolate your input & output methods – do not add any logical app code to them, only input/output processing code specific to the input/output media you have chosen. This way, you can easily add that “save to file” functionality later on.
I think you took “private is good” too far. Private variables in the context of data encapsulation is a positive. However, there is a tendency, especially among libraries, for all non-”vital” methods to be made private. This is often a real barrier to extensibility. Perhaps the entire class does what I want but one of the ‘helper functions’ incorrectly assumes that it should be reading configuration from /path/a.properties. Like any good open-source user, I file a bug with the project, but this leaves me no ability to fix the problem short of subclassing, overwriting the *calling* method so that it calls *my* fixed method instead — this requires a full copy-paste of the original function just I can’t fix a private method via subclassing. If it were ‘protected’, I could subclass it and revert my changes once the bug is fixed in the next version.
Comment by Danny — May 17, 2010 @ 5:49 pm
Danny – point taken about libraries but may I say that if a library doesn’t let you change the input/output source, it is actually poor design.
I think methods should be divided in two categories – methods that return a value of some kind and methods that operate on the variables. Methods that return a value should not operate on variables at the same time (they should call another method to do it) and should therefore be public. Methods that operate on variables should be private, because objects should operate on themselves and not on other objects. It might seem like a strict viewpoint but let it slide and you’ll be confronted with a system where several objects modify another object via calling that kind of method and it will be a mess (I know, I’ve done it several times!).
Comment by Nat — May 17, 2010 @ 6:16 pm
1 & 2 – fair enough, this is just plain common sense
5 – Likewise, but the example quoted is just a single case of the larger “separation of concerns” best practice
3 – Looks like a smell. It harms both extensibility and testability. If an object has both public and private behaviour then (in most cases) it usually indicates that the private stuff should be broken out into a second “helper” object, which should itself have public methods
4 – Is actually an anti-pattern. By initialising member variables in the constructor you can make them final, and therefore make the object immutable, which is a very good practice to get into. If the object is so large as to make this cumbersome then it probably does too much and should be refactored. Alternatively you’re probably ready to look at languages with less boilerplate.
Finally. This obviously isn’t about “programming”, it’s about “JAVA programming”. Try applying any of these commandments to Lisp, or F#, or Haskell – do such languages not also count?
Comment by Kevin Wright — May 17, 2010 @ 9:18 pm
Kevin – of course, other languages count but as I am a Java programmer, it isn’t surprising that my views reflect my language of choice
Comment by Nat — May 17, 2010 @ 10:02 pm