Questions tagged «interfaces»

有关接口相关设计注意事项的问题，例如接口编程。

4
我编写的每个类都应该坚持一个接口吗？
我正在用Typescript编写游戏，并决定继续尝试坚持“ 基于接口的编程 ” 的思想，在该思想中，您基于对象的接口而不是实现来编写代码。 我写了很多接口和实现它们的类，然后退后一步，意识到这些类足够简单，以至于我可能永远不需要更改实现，因为实际上只有一种方法可以完成班级确实做到了（Phaser.Sprite以受限方式移动坦克就像坦克一样）。 然后，我记得几年前读过有关YAGNI的想法，这基本上是您不应过度设计代码以包含您可能永远不会使用的东西。 遵循最佳实践，每个类都应该实现一个接口，还是应该将其限制为您希望将来可能替换掉的类？
12
“如果重新使用某个方法而不进行更改，将该方法放在基类中，否则创建一个接口”是否是一种很好的经验法则？
我的一位同事想出了一个在创建基类或接口之间进行选择的经验法则。 他说： 想象一下您将要实现的每个新方法。对于它们中的每一个，请考虑以下问题：是否可以由多个类以完全相同的形式实现此方法，而无需进行任何更改？如果答案为“是”，则创建一个基类。在其他所有情况下，请创建一个接口。 例如： 考虑类cat和dog，它们扩展了类mammal并具有一个方法pet()。然后我们添加类alligator，该类不会扩展任何内容并且具有一个方法slither()。 现在，我们要eat()为所有这些方法添加一个方法。 如果实施eat()方法将是完全一样的cat，dog而且alligator，我们应该创建一个基类（比方说，animal），它实现了这个方法。 但是，如果它的实现alligator有丝毫不同，我们应该创建一个IEat接口并制作mammal和alligator实现它。 他坚持认为这种方法适用于所有情况，但对我来说似乎过于简化了。 遵循此经验法则是否值得？
5
接口和继承：两全其美？
我“发现”了界面，并开始喜欢它们。接口的优点在于它是一个契约，任何需要履行该契约的对象都可以在需要该接口的任何地方使用。 接口的问题是它不能具有默认实现，这对于平凡的属性是一种痛苦，并且会破坏DRY。这也很好，因为它可以使实现与系统保持分离。一方面，继承会保持更紧密的耦合，并且有可能破坏封装。 案例1（与私有成员的继承，良好的封装，紧密耦合） class Employee { int money_earned; string name; public: void do_work(){money_earned++;}; string get_name(return name;); }; class Nurse : public Employee: { public: void do_work(/*do work. Oops, can't update money_earned. Unaware I have to call superclass' do_work()*/); }; void HireNurse(Nurse *n) { nurse->do_work(); ) 情况2（只是一个接口） class IEmployee { virtual …
2
对许多按钮实施OnClickListener接口的正确方法是什么
我的Android活动包含多个按钮，都需要一个OnClickListener。我已经看到许多不同的方法，例如： 在活动类中实现接口 创建一个单独的类来实现接口 为每个按钮定义一个匿名内部类。 我已经看到了每种方法的许多示例。但是，我不清楚为什么要使用一种方法代替另一种方法。这些方法之间的差异是否在风格上有所不同，还是有理由使一种方法更好？
1
Groovy中的特性，继承和接口，何时使用？
我正在学习groovy，我刚刚了解了2.3中添加的新功能，即Traits的添加。现在对我来说，特质似乎可以让您完成超类和接口可以做的所有事情。 在Groovy中添加特性会否使继承和接口过时？ 如果不是，那么使用这些机制的最佳时间是什么？
1
当对象仅使用部分接口时，如何构造接口？
我有一个项目，其中有两个类都需要更新同一张表的数据库访问对象。框架和项目的约束使得它无法合并这两个类。我在下面创建了一个案例，展示了如何进行设置。A类需要能够更新和读取记录，而B类需要能够更新和删除记录。 如果我按原样使用这些类，则可以正常工作，但是我对每个类都需要不使用它的功能这一事实感到怀疑。例如，为了使用类A，我必须将实现删除功能的dao传递给它，即使它永远不会被调用。同样，我必须将实现read函数的dao传递给B类，但它永远不会被调用。 我考虑过通过继承其他接口（IReadDao，IUpdateDao，IDeleteDao是将要继承的dao）来实现该方法，但是这种方法对于每种功能组合（IUpdateAndRead，IReadAndDelete，IReadAndUpdate ... ） 我想为dao使用接口，因为我不想将应用程序与数据库耦合。有没有一种模式或方法可以实现任何人都知道的我想要的东西？提前致谢。 class IDao { void update(ModelDao model); void delete(String guid); ModelDao read(String guid); } Class A { private IDao dao; public A(IDao dao) { this.dao = dao; } public void doStuff() { ModelDao model = new ModelDao(); ... dao.update(model); } public void readThenDoSomething(String id) { …
3
接口依赖于具体类是否可以？
我在Java中为自定义错误处理程序创建接口。 想要传递一个参数错误对象，但我需要它成为Exception类的子对象。 在接口中使用我定义的类名可以吗？ 就不依赖于任何实现而言，这是否会使它减少接口的数量？ 我尝试做这样的事情： public class CustomException { /* ... Implementation ... */ } public interface Interface { void onError(CustomException ex); }
2
编程到面向数据的接口
我们的代码库的一部分以以下样式编写： // IScheduledTask.cs public interface IScheduledTask { string TaskName { get; set; } int TaskPriority { get; set; } List<IScheduledTask> Subtasks { get; set; } // ... several more properties in this vein } // ScheduledTaskImpl.cs public class ScheduledTaskImpl : IScheduledTask { public string TaskName { get; set; } public …
2
接口隔离原理：如果接口存在大量重叠该怎么办？
摘自敏捷软件开发，原理，模式和实践：Pearson新国际版： 有时，由不同客户端组调用的方法会重叠。如果重叠很小，则组的接口应保持分离。公用功能应在所有重叠的接口中声明。服务器类将从每个接口继承通用功能，但仅实现一次。 鲍伯叔叔，谈论有微小重叠的情况。 如果出现大量重叠该怎么办？ 说我们有 Class UiInterface1; Class UiInterface2; Class UiInterface3; Class UiIterface : public UiInterface1, public UiInterface2, public UiInterface3{}; 如果UiInterface1和之间有大量重叠，该UiInterface2怎么办？
5
用Java“编程到接口”总是有意义吗？
我已经看到了在这个问题上有关如何实例化从接口实现的类的讨论。就我而言，我正在用Java编写一个很小的程序，该程序使用的实例TreeMap，并且根据那里的每个人的看法，应将其实例化为： Map<X> map = new TreeMap<X>(); 在我的程序中，我正在调用函数map.pollFirstEntry()，该函数未在Map接口中声明（并且在Map接口中也存在其他几个声明）。我设法通过将其转换为一个TreeMap<X>我称之为以下方法的地方来做到这一点： someEntry = ((TreeMap<X>) map).pollFirstEntry(); 我了解上述针对大型程序的初始化准则的优点，但是对于很小的程序（该对象不会传递给其他方法），我认为这是不必要的。尽管如此，我还是在工作应用程序中编写此示例代码，但我不希望我的代码看起来很糟也不混乱。什么是最优雅的解决方案？ 编辑：我想指出的是，我对广泛的良好编码实践而不是特定功能的应用更感兴趣TreeMap。正如一些答案已经指出的那样（我已经标记为第一个回答），应该使用更高的抽象级别，而又不会失去功能。
3
将接口用于数据类型是否是反模式？
假设我的模型中有多个实体（使用EF），例如用户，产品，发票和订单。 我正在编写一个用户控件，该控件可以在我的应用程序中打印实体对象的摘要，其中这些实体属于预先确定的集合，在这种情况下，我说可以概括用户和产品的摘要。 这些摘要都只有一个ID和一个描述，因此我为此创建了一个简单的接口： public interface ISummarizableEntity { public string ID { get; } public string Description { get; } } 然后，对于有问题的实体，我创建一个实现此接口的局部类： public partial class User : ISummarizableEntity { public string ID { get{ return UserID.ToString(); } } public string Description { get{ return String.Format("{0} {1} is from {2} and is …
6
拆分大型接口
我正在使用一个带有大约50种方法的大型接口来访问数据库。该界面是由我的一位同事编写的。我们讨论了这一点： 我：50种方法太多了。这是代码气味。 同事：我该怎么办？您需要数据库访问权限-您拥有它。 我：是的，但是目前还不清楚，将来很难维护。 同事：好的，您是对的，不好。界面应该如何？ 我：有5种方法返回的对象各有10种方法怎么样？ 嗯，但这不一样吗？这真的会导致更加清晰吗？值得付出努力吗？ 我时不时地处于需要界面的情况，而想到的第一件事就是一个大型界面。是否有通用的设计模式？ 更新（响应SJuan的评论）： “种类的方法”：它是用于从数据库中获取数据的接口。所有方法都具有形式（伪代码） List<Typename> createTablenameList() 方法和表并不完全是1-1关系，而是更多地关注您总是从数据库中获得某种列表的事实。
3
有关方法参数类型，返回类型和属性类型的具体性的规则
前一段时间，我读到一种关于方法参数类型，返回类型和属性类型的具体性的“经验法则”，但我只是不记得了。 它说了一些有关使返回类型尽可能具体，而参数类型尽可能抽象的事情……反之亦然。 我不知道这实际上是一个好建议还是坏建议，因此，如果您对此有自己的想法，请发表评论。 干杯。
2
是否有“只问您需要”的界面原则？
我已经成长为使用一种设计和使用接口的原理，该原理基本上说：“只问您需要什么”。 例如，如果我有一堆可以删除的类型，我将创建一个Deletable接口： interface Deletable { void delete(); } 然后，我可以编写一个通用类： class Deleter<T extends Deletable> { void delete(T t) { t.delete(); } } 在代码的其他地方，我总是要求最小的责任来满足客户代码的需求。因此，如果我只需要删除一个File，我仍然会要求一个Deletable，而不是一个File。 这个原则是常识并且已经有公认的名称吗？有争议吗？在教科书中讨论过吗？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.