Object slicing is defined as the conversion of an object into something with less information (typically a superclass). In C++ it occurs when an object is passed by value and copying the parameter value results in an upcast and it is considered a bad thing, as it may result in very subtle bugs. Object slicing throws away information. But in some situations this may be exactly what we want.
This article discusses how Object slicing can help with component design. It uses examples to get the message across.
Read Object Slicing and Component Design with Java
The UML diagrams are essential for understanding, and they are not showing up yet...
Well, it showed up for me, and I liked it very much.
Inner classes deserve more attention as a way to cleanly separate an object's responsibilities, and this article explained a particular example of that idea very well.
As much as I understand, the motivation behind object slicing is to decouple the persistence logic from the domain logic. This is useful for EJB architecture. But for Hibernate based applications, I can't see any need for object slicing. Because the persistent objects are unaware of the hibernate framework, when there is a DAO layer available.
Am I right? Or is there some other benefits too?
If the persistence (or any other kind of enhancement) methods are not in a subclass of the domain object, then there is no benefit. As a user of a persistence framework like Hibernate you are not concerned with the implementation details of the enahncing methods.
The technique does not apply to persistence only. It allows you to "stop the inheritance" if you need to. In C# this is the default (you redefine a method unless you use the override keyword) and upcasting may result in an object slicing. It's interesting that the C# designers chose as default the less common situation.
As nice as separating business logic from "persistence logic" may be:
It just doesn't work out in real life.
Your code can ignore some aspects of persistence by using a clever
framework like JDO or hibernate, still you have to deal with, for example:
Removing objects - removing assocications between objects always bears
the question if one object also needs to be physically deleted.
(Aggregation vs. Association is such a case).
You may abstract away the specific technical details of persistence,
but your business logic has to deal with it one way or another.
Thus a seperation is IHMO artifical and serves no purpose.
This article states that:
"Object slicing is defined as the conversion of an object into something with less information (typically a superclass)."
"In C++ it [object slicing] occurs when an object is passed by value and copying the parameter value results in an upcast and it is considered a bad thing, as it may result in very subtle bugs."
IMO "object slicing" is a vague street term, not a well-defined technical one. Too many web pages use the term incorrectly to describe simple assignment-by-value to a superclass instance from a subclass instance.
In any object oriented language, if a superclass object is initialized or assigned from a subclass object, it is expected and unavoidable that member variables defined in the subclass will not be copied to the superclass, for the simple reason that the superclass does not provide a place to store them.
That is not "object slicing" and is not an error or a problem -- it is exactly what one would expect. For example, a Shape object (superclass) might define Area and Color properties, while a Circle object (subclass) might additionally define a Radius property. A Shape object initialized from a Circle object will describe the Area and Color of the Circle, but not its Radius.
IMO, "object slicing" refers to the cases where the language unexpectedly copies only the superclass member variables to a subclass instance, as in the following C++ example:
Shape &s = circ;
s = circ2; // circ2.Radius not copied to circ.Radius
This is quite a different case.