Java - 接口太多了吗？

Question

我已经编程了几年了。接口似乎一直是我难以理解的话题。将尽可能多的功能抽象到接口中是一种好习惯吗？我从来没有完全理解他们的好处。我一直认为“为什么不正常编写方法”。它们只是方法。然后我开始学习依赖注入，以及它如何真正简化代码，让构造函数成为类与外界的主要联系点。但是，最近，我再次开始思考接口以及如何将它们像类型一样扔掉，而不仅仅是一种标记方法的可爱方式。所以在我第一次在 Java 中使用接口的真实实验中，我做了这个例子，我想知道的是：对于了解接口强大功能的 Java 开发人员，我写的这段小代码说明了一个好的模式还是好的思路？到目前为止，基本上这是好的代码吗？我只想知道我是否走在正确的道路上。我明天有第二次面试，我想在面试中提出这一认识，如果且仅当我走在正确的道路上。这是代码：interface Fightable{void kick(Fightable enemy);void punch(Fightable enemy);void takeDamage(Fightable enemy, String typeOfStrike);void strikeEnemy(Fightable enemy, String typeOfStrike);}interface CanEat{void chew();void swallow();}interface MotherShip{int motherShipBoost = 50;String getColony();void sendHelp(int[] location);String buildMoreShips(int amount);void flyToNewSystem(String newSystem);int[] beamDownRandomly();}interface Animatable{void animateChew(CanEat eater);void animateSwallow(CanEat eater);void animateMove(Moveable mover);void animateRevive(CanEat eater);void animateStrike(Fightable striker, Fightable receiver, String typeOfStrike);}interface Moveable{void setNewLocation(int []newLocation);int[] getLocation();void move();}public class GameCharacter implements Fightable, CanEat, Moveable{private int health;private String name;private int[] location;private String stamina;private String origin;private String colony;private Animatable animator;private MotherShip motherShip;private boolean isRecruited;public GameCharacter(MotherShip motherShip, String name, Animatable animator){    this.motherShip = motherShip;    this.animator = animator;    this.name = name;    this.location=this.motherShip.beamDownRandomly();    this.colony = this.motherShip.getColony();}@Overridepublic void kick(Fightable enemy) {    strikeEnemy(enemy, "KICK");}@Overridepublic void punch(Fightable enemy) {    strikeEnemy(enemy, "PUNCH");}看起来我的想法是对的吗？

Answer 1

首先，接口的存在是为了实现其中描述的所有非默认方法。这可以很容易地被抽象类取代。但是，为了以更简单的方式进行清理，已经实现了接口。

只要它看起来合乎逻辑并且对您来说更容易使用界面，就没有太多界面这样的东西。但是，一旦您或您的同事为获取图片而头疼，那就太多了。

使用接口作为一种额外的方式来简化清理和结构化流程。

此外，java 不支持类的多重继承。因此，通过使用接口，您可以像在示例中那样进行多重继承。

真的很好，祝你面试好运！

Answer 2

我会尽力不可知地回答你的问题。

1.

将尽可能多的功能抽象到接口中是一种好习惯吗？让我们从基础开始 a) 记住接口只不过是“合同”，实现接口的参与者基本上承诺兑现和交付合同条款和条件的承诺。b) 接口在代码中充当优秀的设计工具，本质上允许生产者和参与者专注于他们的高级交互，而不用担心实现细节。

在 CS 基础外行人的术语中，接口承诺一致性，本质上是 3 件事。1. 承诺所述功能/操作/功能/方法可用 2. 此功能接受所述约定输入 3.（如果实施）此功能将产生所述结果。

因此，当一项服务（类/soap 消息等）提供实现接口的意图时，它公开同意“合同”的这 3 个条款，任何偏离它们的行为都违反了合同。

2.

是的，你是绝对正确的，当谈到SOLID 设计原则中的 Ioc（控制反转）时，接口确实展示了它们的力量，它允许 IoC 容器解决（提供）并服务于遵守合同的合适参与者（实现），通常在运行时，因此使系统开发人员不必担心实现细节。

但也许 Ioc 的好处通常只有在实现服务定位器模式时才能实现，因此，“开发人员或团队如何从使用接口作为设计工具中受益？” 成为一个重要的问题。

单一开发者 举个例子，我正忙着写一个新的软件系统，白天，我全神贯注于我想为我的用户提供的那种功能，也许能够在一般意义上管理他们的待办事项列表，这需要能够“创建”新的待办事项、“清除”现有项目以及从待办集合中“删除”项目。现在有几种方法可以实现这些功能中的每一个，我变得懒惰了，我宁愿在下周只交付其中一个功能，但我可能会忘记我最初的想法并最终实现我自己基于的功能随着时间的推移对我的影响，自律并坚持我最初的想法，我宁愿在没有实际实现的情况下预先起草这个功能的合同，这将允许我模拟这些功能而不是实际实现它们。因此，通过使用接口，我已经为接下来几周需要实现的目标奠定了基础，并且我可以每隔一天回到它并完成我的功能而不会违背我的承诺......这将我们带到下一个主题我现在不会深入研究Open Close 原则（SOLID 中的 O）基本上说我的设计对外部变化是封闭的，但对内部变化是开放的，也许是对扩展（添加）开放的事件。所以我可以在不破坏现有合同的情况下向我的 todo 服务添加新功能，我可以更改它们的实现行为但不能更改现有功能的形状。

在一个团队中 我与 Lindile 和 Selebalo 合作实施虚拟卡系统，由于工作量太大，我们决定我将专注于核心银行系统（余额分类账），Lindile 将专注于 VC 的存款，而 Selebalo 专注于VC的存款。在我们的初始设计会议中，我们从核心银行开始从内到外进行设计，并描述哪些操作可用于更新客户的账户，经过几个小时的讨论，我们决定核心银行系统将提供两种功能，一种用于添加将钱存入一个帐户，称为“贷方”，接受金额，“借方”，扣除或减少也接受金额的客户帐户。但是因为核心必须处理很多其他事情（客户信用档案、反洗钱、

public interface ICoreBankingServices{

Balance Debit(decimal amount,Currency c);

Balance Credit(decimal amount, Currency c);

}

现在 Lindile 和 Selebalo 可以假设我将履行合同并选择模拟或模拟借方和贷方的结果，直到我们都准备好集成和测试，因此我的功能不依赖于他们的工作和这是一件积极的事情。

我希望这些示例描绘了使用接口、设计工具和依赖解耦机制的一些基本好处。

我不是 Java 的期望，但如果游戏角色必须战斗、吃饭和移动，那么你就在正确的轨道上。您只需要注意您所做的解耦级别（与规范化相同），但会增加复杂性，但没有任何指导方针，只要事情不会变得太复杂，您可以用在逻辑上尽可能多的接口......只是在多重实现继承方面不要应用相同的想法，但这是个人意见:)

您最终将不得不缴纳税款并更多地了解设计模式以及它们试图解决或简化的问题，以便加深对设计更好系统的理解。