我正在使用ObjectAid和Eclipse为我的最新Java项目生成UML类图，我目前有a handful of situations like this，其中我有两个接口之间的依赖关系，以及其中一个的实现接口。这里，foo是我正在使用的图形库。
在上一个示例中，FooCanvas将ITexture个对象绘制到屏幕上，FooCanvas及其界面ICanvas将ITexture个对象作为参数他们的方法。
导致此依赖关系的canvas类中的方法如下：
void drawTexture(ITexture texture, float x, float y);
此外，我使用Java的泛型尝试了方法签名的变体：
<T extends ITexture> void drawTexture(T texture, float x, float y);
这样做的结果是一个类图，其中只有接口和实现类之间的依赖关系，而且没有画布对象对纹理的依赖关系。我不确定这是否更理想。
接口和实现在另一个接口上的依赖关系是预期的模式，还是典型的和/或可能使实现与其接口依赖关系保持“隔离”？或者通用方法是理想的解决方案吗？
答案 0 :(得分：3)
您的问题是您正在尝试解决错误的问题。面向对象设计的一个主要方面是健壮性和灵活性，在不改变/破坏其他代码的情况下，您可以更改某些实现的程度。
您正试图询问某种模式是否理想？但问题是：什么是“理想”？我将引用Scot Meyers的文章How Non-Member Functions Improve Encapsulation: When it comes to encapsulation, sometimes less is more.这篇文章是关于C ++的，但他试图进行的概念适用于任何语言。
封装是一种手段，而不是目的。封装没有任何内在的可取性。封装是有用的只是因为它在我们关心的软件中产生了其他东西。特别是，它产生了灵活性和稳健性。
你应该问的问题是：
可能会破坏多少代码来计算可能的函数 影响。也就是说，如果改变一个实现导致更多 可能破坏的功能比改变另一个功能 实施
关于你的例子，别人告诉你什么是理想的并不是特别容易。你应该公开ITexture接口吗？你应该引入一个名为IDrawable的新接口，它可以扩展纹理吗？目前的做法还可以。但我实际上并不知道，因为我不知道实施！如果改变纹理实现，也许一切都会破裂！ **这是一个只有你能够回答的问题，同时考虑到我上面提到的要点：