此用例的设计模式

Question

我有多个形状要画，如矩形，正方形，圆形等，这些形状的数量可以增加到20个或更多。我是否必须为所有这些形状创建不同的类并实现形状。这个方法会给我很多我不喜欢的类。

有没有什么设计模式可以更好地处理这种情况？

我们有像这样的形状，每个形状里面有不同的对象。Diagram

Answer 1

子类化和参数的混合似乎适合这个问题。

指导原则将是:什么帮助开发人员使用形状集合，以及什么帮助形状实现者有效地提供操作(针对各种形状)。

最好的答案可能只有在实验之后才能得到。从一个不同类型的形状的小集合开始，使用对形状执行预期操作的测试应用程序，并找出哪些形状类工作得最好。

参数化形状的方法有很多种，例如，圆、椭圆、抛物线和双曲线就是圆锥曲线的例子。正方形是具有相等边长的矩形，但也是规则多边形，而规则多边形又是闭合多边形。您可能会发现，仔细选择参数和形状类型将提供许多常见的形状。

Answer 2

您不必创建Circle、Square和Rectangle类，这些通常只是示例。有无数种方法可以实现绘制任何形状-为每个单独的形状创建一个类只是其中之一。

拥有Shape接口的主要好处是，它允许您的客户端代码不耦合到您当前实现形状的方式，而只是耦合到形状的概念。

然而，Shape不一定是实现一个特定形状的对象，比如正方形或三角形。您的Shape可能有一个render()方法，这取决于各个实现如何进行渲染。

例如，您可以有一个Bitmap implements Shape，它保留file属性并通过显示图像来实现render()，同时还有一个Polygon implements Shape，它保存Point对象的列表，并通过在这些点之间绘制线条来实现render()。

不过，只要这是最简单的解决方案，那么从矩形和圆形开始(或您碰巧从哪个形状开始)可能仍然有意义。这样想一下:如果你只需要一个圆形和一个矩形，而不需要更多的形状，那该怎么办？如果是这样的话，你花了五个月的时间在一个可以完美呈现最巧妙的形状的解决方案上，那么你就浪费了五个月。如果它确实证明了形状的多样性随着时间的推移而急剧增加，您将很高兴看到您的所有客户端代码只依赖于Shape的概念:您只需传递Polygon或Bitmap而不是Rectangle或Square，客户端代码就会继续工作。