依赖倒置原则困境 [英] Dependency Inversion Principle Dilemma
问题描述
根据Robert Martin的依赖倒置原则，
http://www.objectmentor.com/resources/articles/dip.pdf ，
当有需要测试对象的类型，切换案例中的
代码。应该放在
的父类中。
但是，我发现这与其他的b $ b原则相冲突 - 对象现在必须知道有关
对象的详细信息。
例如，使用Shape类：
class形状
{
虚拟空洞抽奖（）= 0;
};
班级广场
：公共形状
{
void draw（）;
};
class Triangle
：public Shape
{
void draw（）;
};
以上抽奖方法必须知道关于
外部环境的一些东西才能绘制它们的形状。我认为这与集成分离相冲突
原则以及K.I.S.S. （保持简单（和）
愚蠢）。
那么如何实现（或不违反）依赖性
没有违反封装的反转原理
需要外部接口的详细信息？
可以保持三角形简化，这只是一个
三角类？
否则，每当新的显示设备出现时，必须继续修改基础
Shape类。
{或任何其他需要知道
类型的实体}。
-
Thomas Matthews
C ++新闻组欢迎辞：
http：/ /www.slack.net/~shiva/welcome.txt
C ++常见问题： http://www.parashift.com/c++-faq-lite
C常见问题： http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c ++ faq ：
http：//www.raos.demon .uk / acllc -c ++ / faq.html
其他网站：
http://www.josuttis.com - C ++ STL图书馆书籍
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.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
推荐答案
这将只是一个我也是回答，我很害怕。
Thomas Matthews写道：
This will only be a "me too" answer, I''m afraid.
Thomas Matthews wrote:
据罗伯特·马丁说'依赖倒置原则，
http：// www .objectment.com / resources / articles / dip.pdf ，当需要测试一个对象的类型时，
代码在切换案例中。应该放在
父类中。
然而，我发现这与其他
原则相冲突 - 对象现在必须知道有关
对象的细节在他们自己的封装之外。
例如，使用Shape类：
类Shape
{void void draw（）= 0;
};
班广场
：公共形状
{
无效画（）;
};
班级三角形：public Shape
{
void draw（）;
};
上面的绘图方法必须了解外部环境的某些方面才能绘制出自己的形状。我相信这与整合分离原则以及K.I.S.S相冲突。 （保持简单（和）
愚蠢）。
这正是我遇到的问题。一个三角形不应该知道它可以绘制，或者哪个类负责绘制
三角形。它应该只是三个顶点的容器和
可能包含一些三角形特定的功能（区域，质心或
无论如何）。
那么如何在不违反封装的情况下实现（或不违反）依赖性反转原理需要外部接口的详细信息？
可以保持三角形简化以便它只是一个
三角类？
对不起，我不知道有什么好办法，但我也会对此感兴趣。
否则，必须要每次出现新的显示设备时都要继续修改基础
形状类。
{或任何其他需要知道形状类型的实体}。
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.
2003年12月18日星期四18:32:54 GMT，Thomas Matthews< Th *********** *****************@sbcglobal.net>写道：
On Thu, 18 Dec 2003 18:32:54 GMT, Thomas Matthews <Th****************************@sbcglobal.net> wrote:
class Shape
{void void draw（）= 0;
};
类Square
：public Shape
{
void draw（）;
};
类Triangle
：public Shape
{
void draw（）;
};
上面的绘制方法必须了解外部环境的某些方面才能绘制出自己的形状。我相信这与整合分离原则以及K.I.S.S相冲突。 （保持简单（和）
愚蠢）。
除了以上是无意义的C ++（
''struct''而不是'class''会更好）这个组中的主题。
请尝试改为例如[comp.programming]。
那么如何在不违反封装的情况下实现（或不违反）依赖性反转原理
需要外部接口的详细信息？
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.programming].
So how does one implement (or not violate) the Dependency
Inversion principle without violating the encapsulation
by require details of external interfaces?
使用抽象界面。
struct ICanvas
{
虚拟void setPixel（Point const& pos，Color const& aColor = Color :: black）= 0;
};
struct Shape
{
虚拟空白drawAt（Point const& upperLeft，ICanvas& aCanvas）= 0;
};
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;
};
Thomas Matthews写道：
Thomas Matthews wrote:
根据罗伯特·马丁的依赖倒置原则，
http://www.objectmentor.com/resources/articles/dip.pdf ，
当需要测试对象的类型时，在切换案例里面的代码"应该放入
父类。
这是传统的OO方法。有时它是合适的，但是
通常它不是。
然而，我发现这与其他原则相冲突 - 对象现在必须知道有关其自身封装之外的对象的详细信息。
例如，使用Shape类：
类形状
{
虚拟空白绘制（）= 0;
};
班级广场
：公共形状
{
void draw（）;
};
类三角形
：公共形状
{
void draw（）;
};
上面的绘制形式方法必须了解外部环境的某些方面才能绘制出自己的形状。我相信这与整合分离原则以及K.I.S.S相冲突。 （保持简单（和）
愚蠢）。
那么如何在不违反封装的情况下实现（或不违反）依赖性反转原则
外部接口的细节？
可以保持三角形简化，这只是一个三角形类吗？
否则，人们将不得不继续修改基础
形状每次出现新的显示设备时都会上课。
{或任何其他需要知道
形状类型的实体}。
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}.
/ /使用重载函数。
命名空间形状
{
class Shape {/ * ... * /};
class Square：public Shape {/ * ... * /};
class Triangle：public Shape {/ * ... * /};
}
命名空间显示
{
void draw（Shapes :: Shape const&）{/ * ... *}
void draw（Shapes :: Square const&）{/ * ... *}
void draw（Shapes :: Triangle const&）{/ *。 .. *}
}
// 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::Triangle const& ) { /* ... * }
}
这篇关于依赖倒置原则困境的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
