Gno*_*upi 4 java performance interface
标题很难理解,但我不确定如何总结另一种方式.欢迎任何编辑澄清.
我被告知,并建议使用接口来提高性能,即使在没有特别要求常规"接口"角色的情况下也是如此.在这种情况下,对象是大型模型(在MVC意义上),具有许多方法和字段.
推荐给我的"好用"是创建一个具有独特实现的界面.当然,没有任何其他类实现此接口.我被告知这样做会更好,因为它"暴露更少"(或接近)将使用此类中的方法的其他类,因为这些对象是从其接口引用的对象(所有公共方法)从在界面中重现的实现).
这对我来说似乎很奇怪,因为它对我来说似乎是一个C++使用(带有头文件).在那里,我看到了重点,但在Java？
为这种独特的实现制作接口真的有意义吗？我真的很感激对这个主题的一些澄清,所以我可以证明不遵循这种行为,以及它通过复制所有声明而产生的麻烦.
编辑:感谢大家的答案,这真的很有帮助和有启发性(大多数,不仅是"接受"的).
显然没有性能上的优势,除了界面的通常OO角色之外,我现在有更大的兴趣范围(取决于具体情况).
Pét*_*rök 12
使用接口与性能无关(除了开发团队的性能,即开发速度).它更多的是控制依赖关系,并分离程序的不相关部分.
如果您在代码中直接依赖于具体的C类,则该代码更难以进行单元测试.如果您依赖于接口,则可以在单元测试中创建模拟实现.
当然,您可能不需要将类的所有方法都提取到父接口中.实际上,您可能不需要一个单一父接口.分析该类的用法(特别是对于像你这样的大类)的机会是,你找到两个甚至更多不同的方法组,由不同的客户端使用(例如,一组客户端只查询对象状态,而另一组更新它).这使得可以创建两个或更多个不同的接口,每个接口都更简单和更清洁.
这种分析甚至可以得出结论,你的班级正在尝试做太多的事情(而不是单一的责任),你最好把它的一些内容提取到一个单独的类中!换句话说,一旦你开始考虑 - 并编程到 - 接口,你就会开始在不同的层面上看到设计,这可能会带来更好的设计解决方案.
所有这些都说明了,如果经过上面的分析,你仍然看不到你的模型类的接口,请记下它.再说一遍,比如半年.然后,如果你仍觉得它没有为自己买单,那就把它丢弃吧.接口 - 就像程序中的任何其他元素一样 - 应该始终有明确的目的和存在的理由(并且比"我的同事告诉我创建它"更好).他们不是灵丹妙药.如果你巧妙地使用它们,你可以使代码更好.如果你愚蠢地使用它们,你会使你的代码变得更糟.您在此处发布此问题的事实意味着您想要学习如何巧妙地使用它们,这很好:-)