Comments on: Top 5 object programming commandments

By: Nat

Nat — Mon, 17 May 2010 21:02:35 +0000

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

By: Kevin Wright

Kevin Wright — Mon, 17 May 2010 20:18:33 +0000

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?

By: Nat

Nat — Mon, 17 May 2010 17:16:35 +0000

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!).

By: Danny

Danny — Mon, 17 May 2010 16:49:59 +0000

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.