I have a question regarding composite pattern.
Does the base class "Component" act like a pointer to point leaf object in "Composite" class?
Edit:
Let me ask my question in following words.
"What is the relation between Composite and Component class?"
Here is the uml class diagram of the pattern.
Relation between composite and component:
1) Leaf and Composite usually implement one interface or one abstract class. In your diagram they extend Component. So, the relation on your diagram is inheritance.
2) Composite contains instances of Component. Component, as it occasionally can be Composite, can also contain instances of Component. This is called recursive composition. In general, the relation is called aggregation.
Component
is the abstraction for all components, including composite ones
declares the interface for objects in the composition
(optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate
Leaf
represents leaf objects in the composition
implements all Component methods
Composite
represents a composite Component (component having children)
implements methods to manipulate children
implements all Component methods, generally by delegating them to its children
http://en.wikipedia.org/wiki/Composite_pattern
All container and containee classes declare an “is a” relationship to the interface(Component).
All container classes declare a one-to-many “has a” relationship to the interface.
More here
Related
The following was provided by Inheritance Mapping - Doctrine and was only modified to pertain to both STI and CTI.
There is a general performance consideration with Single or Class
Table Inheritance (STI or CTI): If the target-entity of a many-to-one
or one-to-one association is a STI or CTI entity, it is preferable for
performance reasons that it be a leaf entity in the inheritance
hierarchy, (ie. have no subclasses). Otherwise Doctrine CANNOT create
proxy instances of this entity and will ALWAYS load the entity
eagerly.
In addition to the Doctrine docs, What is a leaf entity? provides a similar description, however, I still don't have a clear enough understanding, and would like to see examples.
Let's say I have entities V8Engine, V6Engine, and Straight4Engine which all extend AbstractEngine, and another entity Automobile where many automobiles have one engine (sorry for my fictional example and change if you think necessary). Please describe what leaf entities are and provide an example of both where the target-entity is and is not a leaf entity.
I think you're asking two questions:
What are leaf entities?
What if I use an entity with (Single or Class) Table Inheritance as a target entity?
1. What are leaf entities?
Let say you've got these classes:
abstract class AbstractEngine {}
final class V6Engine extends AbstractEngine {}
class V8Engine extends AbstractEngine {}
class AudiV8Engine extends V8Engine {}
AbstractEngine is an abstract entity and is therefore not a leaf.
V6Engine is a final class. It can't have subclasses and is a leaf.
V8Engine is not final and has a subclass (AudiV8Engine) and is not a leaf.
AudiV8Engine is not final, but has no subclasses and is also a leaf.
Note that Doctrine entities can't be final so that might be a reason that they're not mentioning the word final.
2. What if I use (Single or Class) Table Inheritance as a target entity?
According to the docs, Doctrine cannot create proxy instances if you have a relationship with non-leaf entity. This may cause a performance penalty, but it depends on your situation how big this issue is.
In one of my projects I'm using Table Inheritance (Organisation as a base class with subclasses Customer and Supplier). In most cases the target-entity is either Customer or Supplier, but in some cases the target-entity is Organisation. It's one of the most important entities in my project and I haven't experienced performance issues.
So based on the documentation and my own experience: you can use Table Inheritance as a target entity, but if performance is very important, reconsider the usage of STI/CTI.
I read some posts about "composition over inheritance","where to use composition/inheritance" , "Is-a relationship..." or "Liskov substitution principle" for some time, but I am not sure if I get the right idea about "composition over inheritance".
Alternatively, In my experience, "composition over inheritance" seems just mean "If parent class is never be used except by child class, it should be composition", for example:
public class Parent{
}
public class Child1 extends Parent{
}
public class Child2 extends Parent{
}
If class "Parent" is never appeared at my code other than in Child1 and Child2, then Child1 and Child2 should not be the child class of Parent.
Is that right?
Composition-over-inheritance means that instead of structuring your class hierarchy using a parent class and extending child classes, you should do something like this:
class Foo {
protected bar;
protected baz;
public function Foo(Bar _bar, Baz _baz) {
bar = _bar;
baz = _baz;
}
}
In other words, instead of inheriting a bunch of functionality from a base parent class, you get this same functionality from independent objects instead which you preferably dependency inject into your class.
Why? Because it provides more flexibility. In the case of Foo extends Bar, Bar provides some base functionality which is useful for a bunch of inheriting classes. Now, who says this functionality isn't also useful for a bunch of other, unrelated classes? Should all your classes inherit from Bar? Should all common functionality be stuffed into Bar because all classes inherit from it? Please no, that just leads to fat, monolithic, unmaintainable base classes.
Instead, implement any collection of useful common methods in their own independent class. Group only functionality which is closely related, separate into different classes as makes sense. Then inject those objects into other objects to compose a new object which can use all that shared functionality without inheriting monolithic base classes or defining an abstract strict class hierarchy.
You should only inherit a class if they share the same "business logic" hierarchy. E.g., Cat extends Pet extends Animal makes perfectly logical sense. Cat extends BaseConnectionManager less so.
If you're using class hierarchies for type hinting, interfaces can serve this purpose much better and more flexibly too.
I generally find that when re-use is the goal, inheritance is attractive. However, in this situation, composition always turns out to be the better solution. For me, inheritance is best used for its polymorphism.
Inheritance is a specific tool. Composition is a general tool. Both are useful, but in different contexts.
Inheritance is useful when you want to ensure that all objects of type Foo are also, in every respect, objects of type Bar. This means more than just implementing the same methods. It means Foo objects must perfectly emulate Bar objects in every outwardly-visible respect. If they do not, then the Liskov Substitution Principle is violated, and inheritance is a poor choice for the situation at hand.
Composition is much more general. It is used to divide responsibilities among multiple classes while still allowing for properly abstracted and defined interactions between them. It does not require the specific, Liskov-like relationship I just described.
"Composition over inheritance" is just the observation that composition is a more general technique than inheritance. Because of this, composition should be the tool we reach for first in most situations, rather than inheritance. This does not mean that every use of inheritance is wrong, or even that inheritance is inherently bad. It's a way of thinking, not a coding standard.
Im trying to understand the various definitions, other students do not quite agree with me.
My definitions, please correct them if wrong:
Base class is the top most class in the hierarchy.
Super and Ancestor class, any class higher up in the hierarchy (including the base class)
Parent class, the next class up in the hierarchy.
Yes. Parent Classes are the direct superclasses (up to one level in the hierarchy) of your class. Depending on your programming language, a class can have multiple parents.
While an ancestor class, is any superclass of your class (a parent class, a parent of a parent class and so on).
According to the wikipedia definition a base class is any class from which another class inherits one or more properties or methods. If you accept this definition, it means that super, ancestor, parent and base class are all synonymous with each other in terms of describing the relationship of a class with a particular sub-class.
Example: I have an Entity called Car which is abstract. Then there are two child entities Cabriolet and Pickup.
Now I have an Entity called Driver which has a Relationship called currentCar 1..1 to the Entity Car. So I can assign either a Cabriolet or a Pickup to any driver's currentCar property. Then I would need to introspect the object to find out at runtime if I have a Cabriolet or Pickup when I get the currentCar from the driver. Is this a valid design in Core Data?
I don't see why this wouldn't work on a technical level, but it does violates OOP polymorphism.
Why do you need to know if the type of car? Would you be able to define the methods on the abstract superclass (Car) and override them as appropriate in the the subclasses (Cabriolet and Pickup)? Could you refactor the car hierarchy so that the attributes of the subclasses become more general and move them to attributes of Car, thus removing the need for the subclasses?
I had trouble with NSFetchResultsController when fetching objects derived from a common superclass. (The returned objects can only be sorted/grouped by an attribute of the entity. The class type is not an attribute so cannot be used to sort/group the entities. My solution/hack was to a type attribute to the superclass - ugly, but it worked.)
I recently encountered a situation in some code I am working on that doesn't make sense to me. A set of classes are inheriting from a base class purely to share some methods in the base class. There is no method overriding, just child classes calling methods from the parent class.
It seems to me that this would be better modeled by having the child classes reference the parent class rather than inheriting from it, which I think would reduce unnecessary complexity. Is this reasonable, or am I missing some benefit of using inheritance like this?
If the parent class methods are there purely as 'utilties' then yes, I agree.
The question (for me at least), would be if the parent class could be modified in the future to have benefit. Meaning, what is the current relationship logically? If it's an "is a" between child and parent then leave it. If the parent is just a collection of methods, refactor to a utility class or use delegation.
You are correct. Unfortunately inheritance is used a lot when it is not actually needed.
If there isn't is-a relationship between the child and parent class then inheritance should not be used.
Inheritance can be used (and abused!) in different ways. Here are the three big categories.
Conceptual hierarchy:
conceptually related classes can be
organized into a specialization
hierarchy :
people, employees, managers
geometric objects ...
Polymorphism:
Objects of distinct, but related
classes may be uniformly treated by
clients
array of geometric objects
Software reuse:
Related classes may share interfaces,
data structures or behaviour.
geometric objects ...
For a complete study of the different forms of inheritance, read On the notion of inheritance.
The case that you mention, is software reuse. There is no is-a relationship, at most a has-a relationship. The goal is mostly to reuse the same code.
As you suggest, this can be refactored with delegation, or even into a utility class if the methods are essentially static.
I can suppose that the inheritance you can observe is just a result of refactoring.