Pure Object Oriented

The other day I was told that I was too much of a purist. This came as a result of a discussion with one of the head system architects at my company about how design should be done. I had drafted a design with what he considered to be too many objects. He proposed that I perform the reverse of the ReplaceTypeCodeWithClass refactoring. I'm interested in finding out when pure is too pure. Is this possible? I would think that given patterns like the FlyweightPattern we (developers) would be able to use a large amount of objects without worrying too much about performance issues. Now, it must be noted that in the system we were discussing (a LearningManagementSystem?) there is no need for RT or even semi-RT responses from the system. My greatest concern is database access.

When is object-oriented too object-oriented?

An obvious note here is that I am aware of the fact that SmalltalkLanguage does not support functional (read as non-OO) coding and not simply object-oriented. The system we were discussing will be written in JavaLanguage.

I Have seen performance problems in Java when having a lot of objects. Some JVMs can have very poor heap management. I once wrote a fairly simple application in Java that had unacceptable performance (it took about 3 hours to process a 10 MByte file). I re-coded in C++ using a similar design and the run time was reduced to 2 minutes (I then went through and replaced a few, critical, string objects with char*; and the run time was 40 seconds).

I think the important thing is to avoid creating and deleting too many objects. The obvious work-around is to use a factory which pre-fabricates and recycles objects: never deleting, and only creating when its internal pool runs dry. Of course, this approach defeats the advantages of garbage collection, but they are, IMHO, not as great as advertised.

Java Strings are immutable, so when you do any kind of change you end up creating and destroying heaps of them (pardon the pun). Any serious string maniuplation has to be done in StringBuffers or even arrays of Character.

Another thing that gets you, with Java is that it, itself, is not very "pure" (a rather vague term). It lacks closures, its iterators are external, its "if" statement is not a class, its primitive types aren't classes, ... (Oops, sorry, I didn't intend this to be a rant against Java: I have yet to find a language that has everything I want). --DaveWhipp

"[...] too many objects. He proposed that I perform the reverse of the ReplaceTypeCodeWithClass refactoring."

Would there really be notably more objects, or was the problem really about "too many classes"? I've noticed that type codes are used intensively in the same environments as where you find exceedingly large classes (see FearOfAddingClasses).

The problem was too many classes. I think he does have a FearOfAddingClasses.

ExtremeNormalForm is what I consider pure. -- ErikMeade

I tend to have two main phases in my analysis and design. The first phase is expansion - making every distinction explicit using as many classes as I need to represent every fine point. Then the analysis/design undergoes contraction as I try to defend each distinction in terms of its usefulness. For example, in cases of specialization, I ask, "Is there really a behavioral difference here?" It's not always easy to decide. For example, with type code vs. class, it may simplify the class structure, but you can basically guarantee that every type code is going to end up as a case statement somewhere (and probably a lot of somewheres). -- JeffMantei