Dependency Inversion Principle Dilemma

[Thomas Matthews]

Hi,

According to Robert Martin's Dependency Inversion Principle,
http://www.objectmentor.com/resources/articles/dip.pdf,
when there is a need to test the type of an object, the
code inside the "switch cases" should be placed into the
parent class.

However, I am finding that this conflicts with the other
principles -- the objects now must know details about
objects outside their own encapsulation.

For example, using the Shape class:
class Shape
{
virtual void draw() = 0;
};

class Square
: public Shape
{
void draw();
};

class Triangle
: public Shape
{
void draw();
};

The above "draw" methods must know something about the
external environment in order to draw their shape. I
believe this conflicts with the Integration Separation
Principle as well as the K.I.S.S. (Keep It Simple (and)
Stupid).

So how does one implement (or not violate) the Dependency
Inversion principle without violating the encapsulation
by require details of external interfaces?
Can one keep a Triangle simplified so it is just a
Triangle class?

Otherwise, one would have to keep modifying the base
Shape class everytime a new display device comes up.
{Or any other entity that would need to know the
type of shape}.
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Rolf Magnus]

This will only be a "me too" answer, I'm afraid.

Thomas Matthews wrote:

Hi,

According to Robert Martin's Dependency Inversion Principle,
http://www.objectmentor.com/resources/articles/dip.pdf,
when there is a need to test the type of an object, the
code inside the "switch cases" should be placed into the
parent class.

However, I am finding that this conflicts with the other
principles -- the objects now must know details about
objects outside their own encapsulation.

For example, using the Shape class:
class Shape
{
virtual void draw() = 0;
};

class Square
: public Shape
{
void draw();
};

class Triangle
: public Shape
{
void draw();
};

The above "draw" methods must know something about the
external environment in order to draw their shape. I
believe this conflicts with the Integration Separation
Principle as well as the K.I.S.S. (Keep It Simple (and)
Stupid).
That's exactly the problem that I have with this. A triangle should not
know that it can be drawn, or what class is responsible for drawing
triangles. It should only be a container for the three vertices and
maybe contain some triangle specific functions (area, center of mass or
whatever).
So how does one implement (or not violate) the Dependency
Inversion principle without violating the encapsulation
by require details of external interfaces?
Can one keep a Triangle simplified so it is just a
Triangle class?
Sorry, I don't know any good way, but I'd be interested in it, too.
Otherwise, one would have to keep modifying the base
Shape class everytime a new display device comes up.
{Or any other entity that would need to know the
type of shape}.

Not only the base class, but also every derived one. And if you want to
reuse your class hierarchy e.g. for writing a file conversion tool
can't draw at all, you'd either have to make a dummy renderer or edit
all the classes to remove the draw function.

[Alf P. Steinbach]

On Thu, 18 Dec 2003 18:32:54 GMT, Thomas Matthews <Th************ *************** *@sbcglobal.net > wrote:

class Shape
{
virtual void draw() = 0;
};

class Square
: public Shape
{
void draw();
};

class Triangle
: public Shape
{
void draw();
};

The above "draw" methods must know something about the
external environment in order to draw their shape. I
believe this conflicts with the Integration Separation
Principle as well as the K.I.S.S. (Keep It Simple (and)
Stupid).
Apart from the above being nonsense C++ (it would be better with
'struct' instead of 'class') this is off-topic in this group.

Try instead e.g. [comp.programmin g].

So how does one implement (or not violate) the Dependency
Inversion principle without violating the encapsulation
by require details of external interfaces?

Use an abstract interface.
struct ICanvas
{
virtual void setPixel( Point const& pos, Color const& aColor = Color::black ) = 0;
};
struct Shape
{
virtual void drawAt( Point const& upperLeft, ICanvas& aCanvas ) = 0;
};

[Jeffrey Schwab]

Thomas Matthews wrote:

Hi,

According to Robert Martin's Dependency Inversion Principle,
http://www.objectmentor.com/resources/articles/dip.pdf,
when there is a need to test the type of an object, the
code inside the "switch cases" should be placed into the
parent class.
That's the traditional OO approach. Sometimes it's appropriate, but
often it's not.
However, I am finding that this conflicts with the other
principles -- the objects now must know details about
objects outside their own encapsulation.

For example, using the Shape class:
class Shape
{
virtual void draw() = 0;
};

class Square
: public Shape
{
void draw();
};

class Triangle
: public Shape
{
void draw();
};

The above "draw" methods must know something about the
external environment in order to draw their shape. I
believe this conflicts with the Integration Separation
Principle as well as the K.I.S.S. (Keep It Simple (and)
Stupid).

So how does one implement (or not violate) the Dependency
Inversion principle without violating the encapsulation
by require details of external interfaces?
Can one keep a Triangle simplified so it is just a
Triangle class?

Otherwise, one would have to keep modifying the base
Shape class everytime a new display device comes up.
{Or any other entity that would need to know the
type of shape}.

// Use overloaded functions.

namespace Shapes
{
class Shape { /* ... */ };
class Square: public Shape { /* ... */ };
class Triangle: public Shape { /* ... */ };
}

namespace Display
{
void draw( Shapes::Shape const& ) { /* ... * }
void draw( Shapes::Square const& ) { /* ... * }
void draw( Shapes::Triangl e const& ) { /* ... * }
}

[Thomas Matthews]

Alf P. Steinbach wrote:

On Thu, 18 Dec 2003 18:32:54 GMT, Thomas Matthews <Th************ *************** *@sbcglobal.net > wrote:

class Shape
{
virtual void draw() = 0;
};

class Square
: public Shape
{
void draw();
};

class Triangle
: public Shape
{
void draw();
};

The above "draw" methods must know something about the
external environment in order to draw their shape. I
believe this conflicts with the Integration Separation
Principle as well as the K.I.S.S. (Keep It Simple (and)
Stupid).

Apart from the above being nonsense C++ (it would be better with
'struct' instead of 'class') this is off-topic in this group.

Try instead e.g. [comp.programmin g].

I believe that technically you are correct that is is not so
much a language issue as an OO one.

The classes are nonsense but are the typical example used
by many authors and instructors. I thought this would
be more familiar to readers than my current implementation.

So how does one implement (or not violate) the Dependency
Inversion principle without violating the encapsulation
by require details of external interfaces?

Use an abstract interface.
struct ICanvas
{
virtual void setPixel( Point const& pos, Color const& aColor = Color::black ) = 0;
};
struct Shape
{
virtual void drawAt( Point const& upperLeft, ICanvas& aCanvas ) = 0;
};

In your example, the Shape class still has a drawAt method.
If I want to store shapes into a database, then I would have
to change the Shape class and add a method for database
access:
enum Action_Type(DB_ STORE, DB_RETRIEVE, DB_SEARCH};

struct Shape /* or class */
{
virtual void draw(); // or drawAt
virtual void database(Action _Type);
};

In my application, a Reference Database System, references can
be created by Text_Stream, User_Interface and Database. In a
simple situation, the Text_Stream creates a reference subobject
(like book, magazine, newspaper, etc.) and returns a pointer
to the base class, "Reference" . The next step is to display
the object via the User_Interface. This is where the dilemma
begins. I would like to have each reference stored in a
different "view" (i.e. page, listbox, panel, etc.) based on
its kind (type). For example, all of the books would be
displayed together as will all the magazines.

The D.I.P. states that the objects should have a "display"
method. However, in order for the object to display its
data, it must know some details about the User_Interface.
Thus the violation of the Integration Separation Principle (ISP).

Although one idea is to create an interface class for
references with interactions with the User_Interface:
struct Reference
{
};

struct Reference_with_ UI
: public Reference
{
virtual void display(/*???*/);
};

struct Book
// : public Reference /* original inheritance */
: public Reference_with_ UI
{
virtual void display(/* ??? */);
}

The above implementation takes the interface out of the
base class, but the child classes still have to know
details about the User_Interface (such as which view
to display in).

Perhaps, as you suggested, I should move this over to
news:comp.progr amming or news:comp.objec t.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Thomas Matthews]

Jeffrey Schwab wrote:

Thomas Matthews wrote:

Hi,

According to Robert Martin's Dependency Inversion Principle,
http://www.objectmentor.com/resources/articles/dip.pdf,
when there is a need to test the type of an object, the
code inside the "switch cases" should be placed into the
parent class.

That's the traditional OO approach. Sometimes it's appropriate, but
often it's not.

Agreed. Sometimes pure OO is dificult.

However, I am finding that this conflicts with the other
principles -- the objects now must know details about
objects outside their own encapsulation.

For example, using the Shape class:
class Shape
{
virtual void draw() = 0;
};

class Square
: public Shape
{
void draw();
};

class Triangle
: public Shape
{
void draw();
};

The above "draw" methods must know something about the
external environment in order to draw their shape. I
believe this conflicts with the Integration Separation
Principle as well as the K.I.S.S. (Keep It Simple (and)
Stupid).

So how does one implement (or not violate) the Dependency
Inversion principle without violating the encapsulation
by require details of external interfaces?
Can one keep a Triangle simplified so it is just a
Triangle class?

Otherwise, one would have to keep modifying the base
Shape class everytime a new display device comes up.
{Or any other entity that would need to know the
type of shape}.

// Use overloaded functions.

namespace Shapes
{
class Shape { /* ... */ };
class Square: public Shape { /* ... */ };
class Triangle: public Shape { /* ... */ };
}

namespace Display
{
void draw( Shapes::Shape const& ) { /* ... * }
void draw( Shapes::Square const& ) { /* ... * }
void draw( Shapes::Triangl e const& ) { /* ... * }
}

Now the dilemma moves to the draw() function. The draw()
function needs to get the data from the Shape. Although
I do like this version better.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Programmer Dude]

Thomas Matthews wrote:

The D.I.P. states that the objects should have a "display"
method. However, in order for the object to display its
data, it must know some details about the User_Interface.
Thus the violation of the Integration Separation Principle (ISP).

Not necessarily. By definition a "shape" is a displayable thing,
so it can certainly possess *some* knowledge about that. Ideally,
that knowledge should be very abstract and designed to work with
varying types of displays.

I think a good technique--which you've touched on already--is that
your draw methods take a parameter that is an interface to the
"canvas". By deriving from the "canvas" class, you can allow your
shapes to drawn on anything.

--
|_ CJSonnack <Ch***@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|

[Jeffrey Schwab]

Thomas Matthews wrote:

Jeffrey Schwab wrote:

Thomas Matthews wrote:

Hi,

According to Robert Martin's Dependency Inversion Principle,
http://www.objectmentor.com/resources/articles/dip.pdf,
when there is a need to test the type of an object, the
code inside the "switch cases" should be placed into the
parent class.

That's the traditional OO approach. Sometimes it's appropriate, but
often it's not.

Agreed. Sometimes pure OO is dificult.

However, I am finding that this conflicts with the other
principles -- the objects now must know details about
objects outside their own encapsulation.

For example, using the Shape class:
class Shape
{
virtual void draw() = 0;
};

class Square
: public Shape
{
void draw();
};

class Triangle
: public Shape
{
void draw();
};

The above "draw" methods must know something about the
external environment in order to draw their shape. I
believe this conflicts with the Integration Separation
Principle as well as the K.I.S.S. (Keep It Simple (and)
Stupid).

So how does one implement (or not violate) the Dependency
Inversion principle without violating the encapsulation
by require details of external interfaces?
Can one keep a Triangle simplified so it is just a
Triangle class?

Otherwise, one would have to keep modifying the base
Shape class everytime a new display device comes up.
{Or any other entity that would need to know the
type of shape}.

// Use overloaded functions.

namespace Shapes
{
class Shape { /* ... */ };
class Square: public Shape { /* ... */ };
class Triangle: public Shape { /* ... */ };
}

namespace Display
{
void draw( Shapes::Shape const& ) { /* ... * }
void draw( Shapes::Square const& ) { /* ... * }
void draw( Shapes::Triangl e const& ) { /* ... * }
}

Now the dilemma moves to the draw() function. The draw()
function needs to get the data from the Shape. Although
I do like this version better.

The information needed by the display can be provided by accessors in
the Shape classes. If the information needed to display the objects
really should not be public, but is an implementation detail, then so is
the act of displaying. In that case, draw *should* be a member of the
original Shape classes.

-Jeff

[EventHelix.com]

> The above "draw" methods must know something about the

external environment in order to draw their shape. I
believe this conflicts with the Integration Separation
Principle as well as the K.I.S.S. (Keep It Simple (and)
Stupid).

The solution is that the draw method should draw to an
abstract device context. Thus you will not need to modify
any of the shape family of classes when a new display device
is introduced.

BTW, Here is another article on the Dependency Inversion Principle:
http://www.eventhelix.com/RealtimeMa..._principle.htm

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Generate Sequence Diagrams and Use Case Diagrams in
PDF

[Jeff Schwab]

EventHelix.com wrote:

The above "draw" methods must know something about the
external environment in order to draw their shape. I
believe this conflicts with the Integration Separation
Principle as well as the K.I.S.S. (Keep It Simple (and)
Stupid).
The solution

/A/ solution. ;)
is that the draw method should draw to an
abstract device context. Thus you will not need to modify
any of the shape family of classes when a new display device
is introduced.

BTW, Here is another article on the Dependency Inversion Principle:
http://www.eventhelix.com/RealtimeMa..._principle.htm

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Generate Sequence Diagrams and Use Case Diagrams in
PDF