Creational techniques with the DIP

[4Space]

I can prevent my high level components from having a dependency on lower
level components, by publishing a series abstractions, and depending solely
on those. The lower level components of course then implement these
abstractions.

What creational techniques should I consider to avoid thwarting this? i.e.
My high level package is now bereft of any dependency on the lower level
component, but how do I instanciate the concretions without giving my higher
level component knowledge of the lower level one?

Cheers,

4Space

[Cagdas Ozgenc]

4Space wrote: I can prevent my high level components from having a dependency on lower level components, by publishing a series abstractions, and depending solely on those. The lower level components of course then implement these abstractions. What creational techniques should I consider to avoid thwarting this? i.e. My high level package is now bereft of any dependency on the lower level component, but how do I instanciate the concretions without giving my higher level component knowledge of the lower level one?

What is the criteria to assign the conrete realizations? Is it going to be
random, probably not. After finding the answer to that question you may have
an abstract factory that constructs objects of lower level for the higher
levels. Your only worry as I understand is that the higher levels know the
class names of concrete realization and contains it within its code for
instantiation. A factory, or even a simple function that creates instances
for higher levels would solve your problem. This way you centralize the
creation procedure and may tweak it afterwards without affecting the rest of
the code.

[H. S. Lahman]

Responding to 4Space...

The homework never ends, does it?
I can prevent my high level components from having a dependency on lower level components, by publishing a series abstractions, and depending solely on those. The lower level components of course then implement these abstractions. What creational techniques should I consider to avoid thwarting this? i.e. My high level package is now bereft of any dependency on the lower level component, but how do I instanciate the concretions without giving my higher level component knowledge of the lower level one?

It depends upon the problem context. There will be some suite of rules
and policies in the problem space that determine which concrete
implementations are required and when they are created. A related suite
of rules and policies will determine which concrete implementation
should be related to a particular context instance. Whoever would
logically understand those rules and policies should do the instance
creation and relationship instantiation. Note that the GoF Factory and
related patterns are typical holders of such logical responsibilities.
(If complex, the rules and policies may be allocated responsibilities
among different objects.)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH

[John Urberg]

"4Space" wrote: I can prevent my high level components from having a dependency on lower level components, by publishing a series abstractions, and depending
solely on those. The lower level components of course then implement these abstractions. What creational techniques should I consider to avoid thwarting this?
i.e. My high level package is now bereft of any dependency on the lower level component, but how do I instanciate the concretions without giving my
higher level component knowledge of the lower level one?

Here's what I've done in Java:

1) Create mapping files that contains a mapping of implementation classes
names to interface class names.

2) Create a Factory class that loads the mapping from all mapping files on
the class path (if you want to get real fancy, you can look for mapping
files in jar files on the class path also)

3) Create a Factory.getImplementation method:

public Object getImplementation(Class interfaceClass) {
String implClass = (String) map.get(interfaceClass.getName());
return Class.forName(implClass).newInstance();
}

4) When you need an implementation, write:

MyInterface i = (MyInterface)
Factory.getImplementation(MyInterface.class);

5) make sure the implemenation classes and mapping files are on the class
path when the program is run (I jar them up together to make it easier to
deploy)

This way the high level classes never know about implementations and I can
substitute different implementations by just including a different jar on
the class path.

Regards,
John Urberg

[Uncle Bob (Robert C. Martin)]

"4Space" <4Space@NoSpam.com> might (or might not) have written this on
(or about) Wed, 09 Jul 2003 14:09:00 GMT, :
I can prevent my high level components from having a dependency on lowerlevel components, by publishing a series abstractions, and depending solelyon those. The lower level components of course then implement theseabstractions.What creational techniques should I consider to avoid thwarting this? i.e.My high level package is now bereft of any dependency on the lower levelcomponent, but how do I instanciate the concretions without giving my higherlevel component knowledge of the lower level one?

The traditional response is to use an AbstractFactory to create the
objects. Frankly, this is often a giant pain. Another approach is to
create a Cloneable prototype.

Shape squarePrototype = new Square();
Shape circlePrototype = new Circle();

--------

Shape s = squarePrototype.clone();

This can work OK in languages like C++, but Java may force you to
group all the prototypes into a single class, thus creating coupling
problems.

Another possibility is to have a bunch of static functions that create
objects:

Shape* makeSquare();
Shape* makeCircle();

Again, in C++ this works fine, but in Java you have to place the
static functions into a class, and that can cause coupling woes.

In the end, it's sometimes just better to create the classes directly
than it is to hunt for some obtuse form of indirection. I suggest you
wait until you feel pain before you use a Factory, or one of the other
indirections.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |