Panel: Objects On Trial

Recorded at:

- just do not make the OO model too complex
- strive for readability, because beauty is in the eye of the next programmer who needs to change your code.
- generics can be hard.
- OO beauty should not get in the way of performance

More one liners that can be taken from this trial? So far Like thumbs up.

Code Reuse is an illusion - Pattern Reuse is more practical

There are several reason OO has not lived up to its promises and none of those are due to the approach. We still teach our CompSci students in a functional manner. They then use object oriented programming languages to do modular programming and not OO systems development. This is the most pervasive approaches out there. Those that succeed in OO develop an analysis model of the problem domain as perceived by the humans working in that domain. You can do this in small pieces or all at once. It does not matter as the whole is a sum of the parts. Then you teach the computer to understand the world the same way the humans understand it to be. “Data” in Startrek understands the world the same way as the humans in each episode – I believe anyway. His world model is gathered in pieces just like the crews’. Thus this approach works perfectly for waterfall or any of the agile approaches. No refactoring - as the world does not change just because you look at small pieces of it, one at a time. The problem that you first encountere when you try to teach the world model to the computer is that the OO languages do NOT support describing such a model. They have no formal relationship construct nor state transition capability (as a start). So you have to start to make these constructs up yourself and this means there are a huge number of ways of doing it leading to you never being able to re-use code from other developers. You can form components by grouping together classes but how big is a component?? This latter question sinks the approach as no two developers agree on the size. As I said above, functional development is the norm today using OO languages. More and more features are added to support this approach – most of which are not needed for OO. Unless training changes OO never will reach its promised level.

The community reuses a ton of libraries daily ('java.*', "org.apache.*') very successfully. In the companies I have worked for we have been quite successful at reuse in our frameworks. The problem is poor designs. Embrace immutability and prefer composition over inheritance. I haven't seen a third party application framework that doesn't encourage the opposite, so write your own -- it doesn't have to be J2EE.