对于以下模型,您更喜欢继承还是组合：

>我想在画布上绘制对象,每个对象代表一个数据对象

>将其视为状态机图：椭圆表示状态,线表示它们之间的连接/转换.对象表示本身永远不会改变,即状态将始终由椭圆显示.但是绘制椭圆的方式应该不同,例如,对于选择,它应该具有不同的颜色,而拖动它应该具有alpha通道等.

从设计的角度来看,椭圆不是状态,而线不是过渡.无论如何,将两个对象组合起来以便能够在List< Shape>中收集它们是合适的.并在每个对象上执行shape.draw().

现在有2个设计模型是可能的,而我认为2个类总是相同的：

interface Shape {

void draw();

}

abstract class Figure implements Shape {

//basic vars like start and end coordinates

int x0, y0, x1, y1;

}

遗产：

abstract class State extends Figure {

String name;

}

class Rectangle extends State {

@Override void draw();

}

class Line extends Figure;

class Transition extends Line

虽然从设计的角度来看,矩形不是状态,而状态不是图形,但是关于绘图上下文,这可能是可行的.因为我可以继承处理形状,绘图等所需的大部分东西.

或组成：

abstract class State {

String name;

}

class Rectangle extends Figure {

private State state;

@Override void draw();

}

class Line extends Figure {

private Transition transition;

@Override void draw();

}

所以Rectangle Line将是我的对象的包装器.

Rectangle和Line应该扩展State和Transition,还是包含它？

或者,也许还有一个我没有看到的第三个设计选项.期待您的想法.

最佳答案 所以,这是我的想法,但对于大多数设计问题,很少有一个“正确”的答案.

就像你说的,状态不是矩形,转换不是直线.我们可以画一条线和/或一个矩形,并且可能有一些优势来对待它们.所以我可以将这些语句翻译成一个简单的设计：

public interface Drawable

{

public void draw();

public Position getPos();

}

public class Rectangle implements Drawable ...

public class Line implements Drawable ...

现在,State’s和Transition’s可以用这些Drawables来表示.你听说过单一责任原则吗？它基本上就是它听起来的样子,一个Object应该负责做一件“事情”.矩形和直线知道如何绘制自己.状态和转换可能在您的系统中还有其他工作要做.

public interface Figure

{

public Drawable getDrawable();

}

public class State implements Figure

{

private Rectangle rect;

public Drawable getDrawable() { return rect; }

//... State's real "work" below

}

public class Transition implements Figure

{

private Line line;

// you get the idea

}

在一个小/简单的系统上,SRP的优点可能会丢失,但我们的想法是我们将渲染与其他系统逻辑分开.我们分离的功能越多,变更时间到来时系统就越不易碎.