java-如何使用接口和实现处理类依赖

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了java-如何使用接口和实现处理类依赖，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1982字，纯文字阅读大概需要3分钟。

内容图文

我正在将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);

这样的结果是一个类图,其中接口和实现类之间只有依赖关系,而画布对象对纹理没有依赖关系.我不确定这是否更理想.

接口和实现对另一个接口的依赖关系是否是预期的模式,还是使实现与接口的依赖关系“隔离”的典型和/或可能？还是通用方法是理想的解决方案？

解决方法:

您的问题是您正在尝试解决错误的问题.面向对象设计的主要点之一是鲁棒性和灵活性,即您可以在不更改/破坏其他代码的情况下更改某些实现的数量.

您试图询问某种模式是否理想？但是问题是：什么是“理想”？我将引用Scot Meyers的文章How Non-Member Functions Improve Encapsulation: When it comes to encapsulation, sometimes less is more.,该文章与C有关,但是无论语言如何,他尝试进行的概念都适用.

Encapsulation is a means, not an end. There’s nothing inherently desirable about encapsulation. Encapsulation is useful only because it yields other things in our software that we care about. In particular, it yields flexibility and robustness.

您应该问的问题是：

how much code might be broken is to count the functions that might be
affected. That is, if changing one implementation leads to more
potentially broken functions than does changing another
implementation.

关于你的例子,别人告诉你什么是理想的并不是特别容易.您应该公开ITexture接口吗？您是否应该引入一个名为IDrawable的新接口,该接口将扩展Texture？目前的方法还可以.但是我实际上不知道,因为我不知道实现！如果您更改纹理实现,则一切都可能会中断！ **这是一个问题,只有考虑到我上面提到的几点,您才能回答：

>如果更改了ITexture实现,则需要更改多少代码或将中断代码？
>当前实施是否足够健壮.
>您可以用当前的实现扩展系统多少？

内容总结

以上是互联网集市为您收集整理的java-如何使用接口和实现处理类依赖全部内容，希望文章能够帮你解决java-如何使用接口和实现处理类依赖所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端