Questions tagged «interfaces»

我有一个模块，例如“ M”，其中有一些客户端，例如“ C1”，“ C2”，“ C3”。我想将模块M的名称空间（即，其公开的API和数据的声明）分配给头文件，使得- 对于任何客户端，仅可见其所需的数据和API；模块的其余名称空间对客户端是隐藏的，即遵守接口隔离原则。 在多个头文件中不重复声明，即不违反DRY。 模块M与其客户端没有任何依赖关系。 客户端不受模块M未被其使用的部分中所做的更改的影响。 现有客户端不受添加或删除更多客户端的影响。 目前，我通过根据模块客户端的需求划分模块的命名空间来解决此问题。例如，在下面的图像中，显示了其3个客户端所需的模块名称空间的不同部分。客户要求有重叠。模块的名称空间分为4个单独的头文件-'a'，'1'，'2'和'3'。 但是，这违反了上述某些要求，即R3和R5。违反了要求3，因为这种划分取决于客户端的性质；在添加新客户端时，该分区也会更改并违反要求5。如上图右侧所示，在添加新客户端后，模块的命名空间现在分为7个头文件-'a ”，“ b”，“ c”，“ 1”，“ 2 *”，“ 3 *”和“ 4”。用于2个旧客户端的头文件发生更改，从而触发了其重建。 有没有办法以非人为方式在C中实现接口隔离？ 如果是，您将如何处理上述示例？ 我想象的是一个虚幻的假设解决方案- 该模块有1个胖头文件覆盖了整个名称空间。该头文件分为可寻址的部分和子部分，如Wikipedia页面。然后，每个客户端都有一个为其量身定制的特定头文件。特定于客户机的头文件只是指向胖头文件的节/子节的超链接的列表。如果构建模块指向模块头文件中的任何部分，则构建系统必须将特定于客户端的头文件识别为“已修改”。

15 c  interfaces  solid 

上下文：我正在使用C＃ 我设计了一个类，为了隔离它并使单元测试更容易，我传入了它的所有依赖关系。它在内部没有对象实例化。但是，不是引用接口来获取所需的数据，而是让它引用通用的Funcs返回所需的数据/行为。当注入其依赖项时，我可以使用lambda表达式来实现。 对我来说，这似乎是一种更好的方法，因为在单元测试期间我不必做任何繁琐的模拟。另外，如果周围的实现有根本变化，则只需要更改工厂类即可；无需更改包含逻辑的类。 但是，我之前从未见过IoC这样做，这使我认为我可能会缺少一些潜在的陷阱。我唯一想到的是与未定义Func的C＃早期版本的轻微不兼容，在我看来，这不是问题。 使用泛型委托/高阶函数（例如Func for IoC），而不是使用更具体的接口时，是否存在任何问题？

15 architecture  interfaces  inversion-of-control  delegates 

从Java 8开始，default方法被引入接口。有效地，这意味着并非in中的所有方法interface都是abstract。 从Java 9（也许）开始，private将允许使用方法。这意味着并非in中的所有方法interface都是public abstract。 问题“在Java接口中的方法是否应使用publicaccess修饰符声明？” 在/programming/161633/should-methods-in-a-java-interface-be-declared-with-or-without-a-public-access-m的堆栈溢出中被询问 那里，大多数答案都认为public abstract不应使用，因为中的任何方法都interface不能是public abstract。这已不再是这种情况。 因此，鉴于接口的这些新功能，是否应该public abstract在Java接口方法声明中使用关键字？ 在我的特定环境中，我们将有一些经验丰富的软件工程师，但没有Java经验的人会不时读取Java代码。我觉得，public abstract对于那些不熟悉接口如何具有使用这些关键字的不同规则的历史的人来说，现在将关键字排除在外会造成更多的困惑。

14 java  coding-style  interfaces  coding-standards  keywords 

我正在设计一个具有两个相关方法的接口，类似于此方法： public interface ThingComputer { default Thing computeFirstThing() { return computeAllThings().get(0); } default List<Thing> computeAllThings() { return ImmutableList.of(computeFirstThing()); } } 大约一半的实现只会计算一件事，而另一半可能会计算更多。 这在广泛使用的Java 8代码中是否有先例？我知道Haskell在某些类型类中做类似的事情（Eq例如）。 好处是，与拥有两个抽象类（SingleThingComputer和MultipleThingComputer）相比，我必须编写更少的代码。 不利的一面是，一个空的实现可以编译，但是在运行时会用炸掉StackOverflowError。可以使用a来检测相互递归ThreadLocal并给出更好的错误，但这会增加非Buggy代码的开销。

14 java  design  interfaces  java8 

我知道如何在C＃中使用接口和显式接口实现，但是我想知道隐藏某些不经常使用的成员是否被认为是不好的形式。例如： public interface IMyInterface { int SomeValue { get; set; } int AnotherValue { get; set; } bool SomeFlag { get; set; } event EventHandler SomeValueChanged; event EventHandler AnotherValueChanged; event EventHandler SomeFlagChanged; } 我事先知道这些事件虽然有用，但很少使用。因此，我认为通过显式实现将它们隐藏在实现类之外以避免IntelliSense混乱是有意义的。

14 c#  interfaces  implementations 

最近，我一直在研究更多的“有组织的”编程，并且我一直在学习应该对接口而不是对实现进行编程。考虑到这一点，在可能的情况下为项目编写实现之前，最好在接口中“略过”项目吗？ 如果是这种情况，那么在使用第三方库（即Lidgren）的情况下，我是否也应该将它们包装在接口中并通过IOC容器进行解析，还是可以将它们公开给接口？

14 c#  design  interfaces  third-party-libraries  inversion-of-control 

两者之间有区别吗 public class A extends AbstractB implements C {...} 与... public class A extends AbstractB {...} abstract class AbstractB implements C {...} 我知道在两种情况下，类A最终都将符合该接口。在第二种情况下，AbstractB可以在中提供接口方法的实现C。那是唯一的区别吗？ 如果我不想提供任何的接口方法的实现 AbstractB，我应该使用哪种风格？使用一个或另一个具有隐藏的“文档”目的吗？

14 java  interfaces  abstract-class 

在OOP中进行开发时，有时接口/协定是由您不能更改的库提供的。我们将此接口称为J。 现在，您有了一个类A的对象，该对象使用实现此接口的对象。内部仅需要接口定义的一小部分。我在项目期间创建了一些对象类（让我们称其中一个类型为D），因此在接口J内实现所有操作都会产生开销。 我想在接口J中实现功能的一个子集，但是到目前为止，我的解决方案并不令我满意： 实现J的各个方面，然后抛出“ notImplementedExceptions”会误告知用户我的对象：看来我类型D的对象确实符合接口J，但它们与我的对象的其他使用者（接受实现接口的对象） J）不能依靠我对象的完整性。 尽管接口J与我自己的接口完全兼容，但是实现新定义的接口会禁止我使用仅实现接口J的对象。 让我的自定义对象实现接口J会产生很大的开销，因为它们不需要所有这些功能。 当我能够更改接口J时，我将创建一个具有接口J功能子集的“超级接口” K，并使接口J从接口K继承。但是我不能更改接口J。 什么是此问题的面向对象的解决方案？最好的解决方案是否仍在实现“ Just”接口J？还是有OOP方式可以在不更改接口的情况下“超类化”接口？

14 object-oriented  interfaces 

几十年来，它一直是接口那样的话只 只（只）指定的方法签名。我们被告知这是“正确的做事方式™”。 然后Java 8出来并说： 好吧，嗯，现在您可以定义默认方法了。再见，再见。 我对有经验的Java开发人员和最近（过去几年）开始开发它的人如何消化它感到好奇。我也想知道这如何适合Java正统和实践。 我正在构建一些实验代码，并且在进行一些重构时，最终得到了一个接口，该接口简单地扩展了标准接口（Iterable）并添加了两个默认方法。老实说，我对此感到非常好。 我知道这有点开放，但是现在Java 8已在实际项目中使用了一段时间，围绕默认方法的使用是否存在正统观念？在讨论它们时，我最常看到的是关于如何在不破坏现有使用者的情况下向接口添加新方法。但是像我上面给出的示例一样从一开始就使用它。是否有人在其界面中提供实现时遇到任何问题？

13 java  interfaces  default-method 

我正在设计自己的小OOP程序来模拟吸血鬼，狼，人类和卡车，并试图实现自己对接口的有限理解。 （我在这里仍然是抽象的，还没有代码实现，所以这是一个OOP设计的问题……我想！） 我在这些类之间寻找“共同行为”并将其实现为接口是否正确？ 例如，吸血鬼和狼咬人……那么我应该有一个咬人界面吗？ public class Vampire : Villain, IBite, IMove, IAttack 同样对于卡车... public class Truck : Vehicle, IMove 对于人类... public class Man : Human, IMove, IDead 我的想法在这里吗？（感谢您的帮助）

13 object-oriented  interfaces 

我正在尝试为纸牌游戏建模，其中纸牌具有两项重要功能： 首先是效果。这些是您玩纸牌时对游戏状态所做的更改。效果界面如下： boolean isPlayable(Player p, GameState gs); void play(Player p, GameState gs); 而且，当且仅当您能够支付费用且其所有效果均是可玩的时，您才可以考虑使用该卡。像这样： // in Card class boolean isPlayable(Player p, GameState gs) { if(p.resource < this.cost) return false; for(Effect e : this.effects) { if(!e.isPlayable(p,gs)) return false; } return true; } 好的，到目前为止，非常简单。 卡上的另一组功能是异能。这些功能是对游戏状态的更改，您可以随意激活它们。当提出这些接口时，我意识到他们需要一种确定是否可以将其激活的方法，以及一种用于实现激活的方法。最终被 boolean isActivatable(Player p, GameState gs); void activate(Player p, …

13 interfaces 

尽管这是一个普遍的问题，但它也特定于我当前遇到的问题。我目前在解决方案中指定了一个接口，称为 public interface IContextProvider { IDataContext { get; set; } IAreaContext { get; set; } } 该接口经常在整个程序中使用，因此我可以轻松访问所需的对象。但是，在程序一部分的较低级别，我需要访问另一个将使用IAreaContext并对其执行一些操作的类。因此，我创建了另一个工厂接口来执行此创建操作： public interface IEventContextFactory { IEventContext CreateEventContext(int eventId); } 我有一个实现IContextProvider的类，并使用NinJect注入。我遇到的问题是，我需要使用此IEventContextFactory的区域只能访问IContextProvider，并且本身使用另一个需要该新接口的类。我不想在低级实例化IEventContextFactory的此实现，而是希望始终使用IEventContextFactory接口。但是我也不想只通过构造函数注入另一个参数，而只是将其传递给需要它的类，即 // example of problem public class MyClass { public MyClass(IContextProvider context, IEventContextFactory event) { _context = context; _event = event; } public void DoSomething() …

13 c#  design  interfaces 

根据Herb Sutter的说法，应该更喜欢抽象接口（所有纯虚函数）而不是C ++中的抽象类，以尽可能地实现分离。虽然我个人认为该规则非常有用，但是最近我加入了一个由许多Java程序员组成的团队，并且在Java代码中似乎没有该准则。函数及其实现通常位于抽象类中。因此，即使对于C ++，我也将Herb Sutter弄错了吗？还是与Java相比，C ++中抽象函数的用法是否存在一般差异？在Java中，带有实现代码的抽象类比在C ++中更明智吗？如果是，为什么呢？

13 java  c++  interfaces  abstract-class 

例如，如果我编写一个名为Random的类，其目的和方法签名与Microsoft的.Net System.Random类完全相同，是否会侵犯版权？使用哪种语言会有所不同吗？在这种情况下，我想编写一个在ActionScript中使用的Random类，该类缺少内置的种子PRNG类。 如果有人拥有良好的链接或参考建议以了解软件的哪些方面受到保护，那也很好。是的，我知道这不是“真正的”法律建议的地方。如果有人去法院指责公共留言板是最重要的事情，那就可耻了。

13 interfaces  copyright 

我试图自学软件工程，遇到一些使我感到困惑的冲突信息。 我一直在学习OOP，以及什么是抽象类/接口以及如何使用它们，但是随后我读到，应该“偏重于继承而不是继承”。我知道组合是指一个类组成/创建另一个类的对象以利用/与该新对象的功能交互。 所以我的问题是...我应该不使用抽象类和接口吗？是否不创建抽象类并在具体类中扩展/继承该抽象类的功能，而是仅编写新对象以使用其他类的功能？ 或者，我应该使用组合并从抽象类继承吗？两者结合使用？如果是这样，您能否提供一些示例，说明其工作方式及其好处？ 因为我最熟悉PHP，所以在继续使用其他语言并转移我新获得的SE技能之前，我正在使用它来提高OOP / SE技能，因此，使用PHP的示例非常受赞赏。

13 object-oriented  php  interfaces  inheritance  composition