Creational techniques with the DIP

Creational techniques with the DIP

Post by 4Spac » Thu, 10 Jul 2003 23:09:00



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

 
 
 

Creational techniques with the DIP

Post by Cagdas Ozgen » Thu, 10 Jul 2003 23:32:48



> 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.

 
 
 

Creational techniques with the DIP

Post by H. S. Lahma » Fri, 11 Jul 2003 02:20:47


Responding to 4Space...

The homework never ends, does it?

Quote:> 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

Pathfinder Solutions  -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH

 
 
 

Creational techniques with the DIP

Post by John Urber » Fri, 11 Jul 2003 05:16:51



> 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

 
 
 

Creational techniques with the DIP

Post by Robert C. Mart » Fri, 11 Jul 2003 07:15:12



(or about)  Wed, 09 Jul 2003 14:09:00 GMT, :

Quote:>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?

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"                  

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     |

 
 
 

1. Creational techniques with the DIP

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

2. text() in System.Xml.XPath

3. creational control

4. Problems with 5.1.1 on 167

5. Win32 GetTickCount(), vulnerable to power dip/surge?

6. AT&T Being Sued By It's Own Investors

7. Skinny Dip

8. win98 and dvd drive

9. ADT's and DIP

10. Templates and DIP

11. DIP benefitting .NET

12. RCM's dip Inverts Optimal OOD

13. ADT's and DIP