Just thinking wild ...
Can we call interface as a super-type of types (classes) that, in turn refers to behavior (objects)?
Actually, this makes understanding patterns a little simpler, probably.
For example, Abstract Factory becomes, two interfaces, AbstractFactory and AbstractProduct.
AbstractFactory = {ConcreteFactory1, ConcreteFactory2, ...,ConcreteFactoryM}
AbstractProduct = {ConcreteProduct1, ConcreteProduct2,....,ConcreteProductN}
The matrix of objects it can create would be M x N, whereas the implementation classes would be only M + N. This makes sense only when M + N > 3 though (both M, N are natural numbers).
I guess, this way, we can explain some of the GoF descriptions of AF pattern.
Any comment?
- P Das
Can we call interface as a super-type of types (classes) that, in turn refers to behavior (objects)?
Actually, this makes understanding patterns a little simpler, probably.
For example, Abstract Factory becomes, two interfaces, AbstractFactory and AbstractProduct.
AbstractFactory = {ConcreteFactory1, ConcreteFactory2, ...,ConcreteFactoryM}
AbstractProduct = {ConcreteProduct1, ConcreteProduct2,....,ConcreteProductN}
The matrix of objects it can create would be M x N, whereas the implementation classes would be only M + N. This makes sense only when M + N > 3 though (both M, N are natural numbers).
I guess, this way, we can explain some of the GoF descriptions of AF pattern.
Any comment?
- P Das