Dan Zambonini, in "What would you put in the ultimate Base Class?," brings up an interesting theoretical exercise: what methods or attributes would you put into the ultimate base class? (Note that Mr. Zambonini is thinking of PHP4 here, so for Java programmers the exercise is merely theoretical.)

Mr. Zambonini suggests the following as a start:

• A save or persist method, which could record the current object data to a configurable location: database, disk, memory (e.g. memCache), or session (cookie). This would also require a set of methods that define the mapping of properties to database tables/fields, and relations between classes (e.g. compositions).
• Conversely, a load method, based on a unique identifier or condition.
• A getAsXml() method that returns an XML representation of the object (either as a string, or appended to a provided DOM Node). Actually, maybe this should just be an ultra-flexible export or getRepresentation type method, that can also return the object as HTML, CSV and other formats.

Considering the problems Java has had with those same ideas, it's slightly amusing that someone suggests PHP go down the same paths. What do you think?

Instead of doing all this in the base class, maybe you should consider that *rendering* an object into various formats (XML, CSV, etc) is not the job of the object itself... same with being able to load/store itself in a DB.

The idea of an "ultimate base class" is why you end up with overly-complex frameworks that don't really do a good job of anything.

IMHO the ultimate base class should be flexible enough to allow derived classes to choose their implementation but at the same time it can guide the steps of a processing as well.
eg.. The base class can have Save method which will call few abstract methods like isDataValid(), BuildData(), PerformPostSaveOperation etc.

Let the derived classes worry about the validation rules, how to build the data to save and what do they want to do after the save is done etc.

My 2.2 Cents (including GST)

I'd put nothing in my ultimate base class .... inheritance is for whimps ...

As other posters pointed out, it's easy to end up with a grab back of stuff, most of which might be useful sometimes, but almost all of which is not used most of the time.

Take for example the thread notification and "toString()" methods in Java's Object. Yes, sometimes these methods are very useful. The rest of the time they are baggage. Even when you need them, it would be nice if you could substitute (or pick) different implementations (like an XML string format...). But most important is the fact that these methods have no relationship to the application logic (except in special cases).

Features like these are "cross-cutting concerns", in aspect-oriented programming (AOP) terminology. They are best implemented on demand and removed when not needed.

That isn't always easy to do with current AOP technology, but imagine a day when you can tell your IDE that you need a text dump of an object tree and you can select from a range of possible formats (or add your own). It then inserts aspects to provide the feature. For this to work, we certainly need rich aspect libraries (the aspect-equivalent of the JDK, Apache, etc.) and we probably need more aspect-aware languages.

In fact, a lot of the facilities to support this already exist in Java and especially in languages like Ruby, Smalltalk, Lisp, etc. However, formalizing an aspect "veneer" around these features will be necessary to make them widely accessible and efficient to use, in the same way that objects encapsulate lower-level facilities in a convenience way.

So, I would leave almost everything out of the "ultimate base class" but make it composable with aspects.

First off, I won't comment on the bullshit that PHP guy said. The idea of a "toXML()" method in a base class is actually quite revealing of the "usual PHP way to do things" : how can a software architect even think about such a crappy stuff ???
The guy probably learned "computer science" through HTML and scripting languages, and obviously he understands nothing about OO concepts.

The discussion about aspects is far more interesting -:)

Take for example the thread notification and "toString()" methods in Java's Object. Yes, sometimes these methods are very useful. The rest of the time they are baggage.

They're always useful, I've never seen a program that does not use either toString() or threads, either directly or indirectly !
* Being able to "stringify" itself is a pretty good feature that every oject should have IMHO. toString() allows this. Try doing the equivalent in C++ and you'll end by redefining your own base class !!!
* Java Threads are unified, and part of the runtime, unlike in C++ once again. Try threads in C++ and you'll thank god for the threads in Java, and the methods you have in Object. I don't see any problem in having thread-related methods in Object when you have chosen a language that deals easily with threads !

 Even when you need them, it would be nice if you could substitute (or pick) different implementations (like an XML string format...).

Well override toString() then, but I would use interfaces instead in this specific case :

public interface XMLizable {
  public String toXML();
}

But most important is the fact that these methods have no relationship to the application logic (except in special cases).Features like these are "cross-cutting concerns", in aspect-oriented programming (AOP) terminology.

Well that's quite a discussion : how can you use aspects to serialize an instance to XML without breaking encapsulation in 99% of the situations (private/protected stuff) ?

Also, converting an object to a specific data format (XML or else) *is* precisely application logic to me ! This is part of the object's behavior to be able to do such thing !!! It should be clear in the object's *contract*, that's why the use of interfaces is the best way to do this IMHO.

So, I would leave almost everything out of the "ultimate base class" but make it composable with aspects.

Aspects are good for certain domains (e.g. transactions or transversal security), but they don't send all OO concepts to trash.
What about equals & hashCode ? These ones are freakin' great when you have to deal with collections (once again, make a parallel with C++ and STL's collections if you have experienced it, it's a self explanatory exercise :-) ) and I don't think AOP can do anything for you here :-/
Well, would you say "I don't need to compare for object equality in every object so forget about equals()" ???
Or "I don't always need collections so don't bother with equals() / hashCode()" ???

I personnally think the guys @Sun made it quite right with java.lang.Object, and I'm glad there were no PHP "architects" in the consortium then :-P

Have fun,

Remi

Remi,

I'm not trying to question the value of "toString()", etc. I love 'em too and I agree that Sun made the correct decision to include them in Object. My point is that in an "aspect nirvana" (which is not where we are yet), you don't have to commit to adding these things to your object hierarchy. You have the ability to "weave them in" when needed. You can also add other stuff this way. I think if you look at the successful way that JBoss AOP, Spring AOP, and AspectJ are used to add facilities to POJO's, then generalize to the entire object model, you can do a lot (at least when the tools catch up...).

I also agree with you that it should be interface based.

When I said that stringification, etc. aren't part of the application logic, I'm drawing the distinction between the "business" purpose of the classes and the implementation issues. A bank cusomter doesn't think about "stringifying" his/her BankAccount object or its hash code, etc. He/she thinks about the balance and so forth. As a developer, on the other hand, I do worry about the hash code, string representations, etc.

Finally, you bring up a good point about breaking encapsulation with aspects. This is a topic of spirited discussion in the community. IMHO, encapsulation rules should be obeyed by aspects. In this particular example, a "stringify" aspect could be considered part of the package or analogous to a subclass, with greater access to internals. Most other aspects should only access the public interface.

Hiya Dean,

Sorry for the late reply, been very busy these last weeks...

 My point is that in an "aspect nirvana" (which is not where we are yet), you don't have to commit to adding these things to your object hierarchy. You have the ability to "weave them in" when needed. You can also add other stuff this way. I think if you look at the successful way that JBoss AOP, Spring AOP, and AspectJ are used to add facilities to POJO's, then generalize to the entire object model, you can do a lot (at least when the tools catch up...).

Well, JBoss or whatever else AOP thing has mostly been used for plumbing purposes yet AFAIK. I mean, analysts don't know anything about aspects : it's only a way to *implement* things in a different (and far more efficient, I'm with you there, and addicted to interceptors etc since even we did not know the words AOP !) manner.
Simple example : hard-wire transactions or weave 'em in when needed. Or use aspects to implement security & access control mechanisms.
But I don't see yet the interpenetration of aspects in the *design* phase... where you should just care about interfaces.
This also applies to java.lang.Object's methods : they are also implementation stuff, they're not tied to business logic (no, unfortunately you can't book your dentist yet using out-of-the-box Object :-) ).

Just plumbing. And you said it : you're glad you did not have to implement that yourself...

When I said that stringification, etc. aren't part of the application logic, I'm drawing the distinction between the "business" purpose of the classes and the implementation issues.

That's it :-)

Finally, you bring up a good point about breaking encapsulation with aspects. This is a topic of spirited discussion in the community. IMHO, encapsulation rules should be obeyed by aspects.

As you said we're far from the nirvana there... I can't figure out how they'll handle this (I have no doubt they will overcome that issue and propose an ideal mix of OOP & AOP in the end).
This reminds me a few years ago an AOP guru in a conference was talking about how to implement logging through aspects instead of coding them into the object itself. He was more or less able to trace the whole execution flow, object creation etc. But that's not everything about logging unfortunately ! When I asked him "how can I log the value of a variable declared inside a method and used in a loop in this method" ? He had to think for about 30 seconds to answer me that I still have access to the call stack !!!
Man, OOP back to stone age ! Just to log a simple thing...
Well finally I find it rather simpler, even if it has disadvantages, to use e.g. log4j the regular way :-)

 In this particular example, a "stringify" aspect could be considered part of the package or analogous to a subclass, with greater access to internals. Most other aspects should only access the public interface.

Well once again I can't see a real advantage in AOP there. I mean, interfaces are OK for this, and they can also be used for plumbing (they are, all over the JDK once again).
Defining contracts and having instances implementing them looks pretty simple, clean and straightforward to me, I don't see how aspects can do this better !
But don't hesitate to convince me ;)

Have fun,

Remi

I wish java.lang.Object contained the methods:

giveLandingPermissionToFlight(String flight)
createAppointment(String name, Date date)

Would certainly make building air traffic control software OR
dentist reservation systems easier.

:-)

I would keep the base class simple (with nothing in it). Let's get back to work guys!