Questions tagged «interfaces»

我正在阅读《依赖注入原理，实践和模式》一书，并了解了泄漏抽象的概念，该概念在本书中有很好的描述。 这些天来，我正在使用依赖注入重构C＃代码库，以便使用异步调用而不是阻塞调用。这样做时，我正在考虑一些接口，这些接口在我的代码库中表示抽象，并且需要重新设计以便可以使用异步调用。 例如，考虑以下接口，它代表应用程序用户的存储库： public interface IUserRepository { Task<IEnumerable<User>> GetAllAsync(); } 根据书中的定义，泄漏抽象是设计时考虑到特定实现的抽象，因此某些实现详细说明了抽象本身的“泄漏”。 我的问题如下：我们可以考虑以异步方式设计的接口（例如IUserRepository）作为泄漏抽象的示例吗？ 当然，并非所有可能的实现都与异步有关：只有进程外实现（例如SQL实现）才需要同步，但是内存中存储库不需要异步（实际上实现接口的内存中版本可能更多）如果接口公开异步方法很困难，例如，您可能必须在方法实现中返回类似Task.CompletedTask或Task.FromResult（users）之类的东西。 您如何看待？

13 c#  object-oriented  api-design  interfaces  dependency-injection 

我有一类带有一些默认/共享功能的类。我用abstract class它： public interface ITypeNameMapper { string Map(TypeDefinition typeDefinition); } public abstract class TypeNameMapper : ITypeNameMapper { public virtual string Map(TypeDefinition typeDefinition) { if (typeDefinition is ClassDefinition classDefinition) { return Map(classDefinition); } ... throw new ArgumentOutOfRangeException(nameof(typeDefinition)); } protected abstract string Map(ClassDefinition classDefinition); } 如您所见，我也有接口ITypeNameMapper。如果我已经有一个抽象类，TypeNameMapper或者abstract class已经足够，定义这个接口是否有意义？ TypeDefinition 在这个最小的例子中也是抽象的。

12 c#  interfaces  abstract-class 

据我所知，空接口通常被认为是不好的做法-特别是在语言支持的属性之类的地方。 但是，如果某个接口继承自其他接口，是否将其视为“空”？ interface I1 { ... } interface I2 { ... } //unrelated to I1 interface I3 : I1, I2 { // empty body } 任何实现I3将需要实现I1和I2，并从不同的类，这些类继承的对象I3然后可以互换使用（见下文），所以是不是叫I3 空？如果是这样，哪种更好的架构方法呢？ // with I3 interface class A : I3 { ... } class B : I3 { ... } class Test { void foo() …

12 interfaces  inheritance 

通过Java Collections Framework查看，我注意到相当多的接口都带有comment (optional operation)。这些方法允许类只通过UnsupportedOperationException不想实现的方法来实现。 这方面的一个示例是中的addAll方法Set Interface。 现在，如本系列问题所述，接口是使用预期的定义合同。 接口很重要，因为它们将类的工作与工作方式分开。合同规定了客户的期望，使开发人员可以自由选择自己选择的方式实施合同，只要他们遵守合同即可。 和 界面是对对象可以执行的操作的描述……例如，当您打开电灯开关时，电灯就亮了，您不在乎如何做，只是它确实在做。在面向对象的程序设计中，接口是对象成为“ X”所必须具有的所有功能的描述。 和 我认为基于接口的方法要好得多。然后，您可以很好地模拟您的依赖关系，并且基本上所有事物之间的耦合都不太紧密。 接口的意义是什么？ 什么是接口？ 接口+扩展（mixin）与基类 鉴于接口的目的是定义一个契约并使您的依赖关系松散耦合，是否有些方法不能UnsupportedOperationException达到目的？这意味着我不能再通过了Set，只能使用addAll。相反，我必须知道Set我通过了什么实现，所以我可以知道是否可以使用addAll。对我来说，这似乎毫无价值。 那有什么意义UnsupportedOperationException呢？它只是在弥补遗留代码，并且需要清理其接口吗？还是我错过了更有意义的目的？

12 java  interfaces  methods 

例如： 说我有课A，B，C。我有两个接口，我们称它们为IAnimal和IDog。IDog继承自IAnimal。A和B是IDogs，虽然C不是，但它是一个IAnimal。 重要的部分是不IDog提供任何附加功能。它仅用于允许A和B，但不C以作为参数传递给某些方法进行传递。 这是不好的做法吗？

12 object-oriented  interfaces 

假设我们正在做一个解析器。一种实现可以是： public sealed class Parser1 { public string Parse(string text) { ... } } 或者我们可以将文本传递给构造函数： public sealed class Parser2 { public Parser2(string text) { this.text = text; } public string Parse() { ... } } 在两种情况下用法都很简单，但是与另一种相比，启用向的参数输入是什么意思Parser1？当他们查看API时，我向同一个程序员发送了什么消息？此外，在某些情况下是否存在任何技术优势/劣势？ 当我意识到接口在第二种实现中将变得毫无意义时，又出现了另一个问题： public interface IParser { string Parse(); } ...第一个接口上的接口至少可以达到某些目的。这是否特别表示某类是“可接口的”？

12 object-oriented  interfaces  methods  construction 

这适用于Java SE和Android，因为合同是相同的。 Java SE的CharSequence文档 适用于Android的CharSequence文档 CharSequence没有定义contains(CharSequence)方法。我似乎找不到原因，并且包括它非常有用，可以防止需要调用CharSequence#toString()以检查字符序列。 例如，在Android中，用户被迫致电Editable#toString()查看它是否包含字符序列（尽管是Editable实现）CharSequence，但如果CharSequence定义可以避免contains(CharSequence)。 这种设计选择背后的想法是什么？是潜在的监督，还是有设计原因？

11 java  design  interfaces  android 

我一直在进行一些代码的重构，我想我可能已经迈出了第一步。我正在用Java编写示例，但我想它可能是不可知的。 我有一个Foo定义为的接口 public interface Foo { int getX(); int getY(); int getZ(); } 和一个实现 public final class DefaultFoo implements Foo { public DefaultFoo(int x, int y, int z) { this.x = x; this.y = y; this.z = z; } public int getX() { return x; } public int getY() { …

11 java  design-patterns  interfaces  inheritance 

我有两个代表“酒吧/俱乐部”（您喝酒/社交的地方）的对象。 在一种情况下，我需要栏名称，地址，距离，标语 在另一种情况下，我需要栏名称，地址，网站网址，徽标 因此，我有两个对象代表相同的事物，但具有不同的字段。 我喜欢使用不可变的对象，因此所有字段都是从构造函数设置的。 一种选择是拥有两个构造函数，而其他字段为空，即： class Bar { private final String name; private final Distance distance; private final Url url; public Bar(String name, Distance distance){ this.name = name; this.distance = distance; this.url = null; } public Bar(String name, Url url){ this.name = name; this.distance = null; this.url = url; …

11 java  design-patterns  object-oriented  interfaces  inheritance 

Java对class和进行了明确区分interface。（我相信C＃也可以，但是我没有经验）。但是，在编写C ++时，类和接口之间没有语言强制的区分。 因此，我一直将接口视为解决Java中缺乏多重继承的一种解决方法。在C ++中做出这样的区分是任意的，毫无意义的。 我一直倾向于使用“以最明显的方式编写东西”的方法，因此，如果在C ++中，我得到了Java中所谓的接口，例如： class Foo { public: virtual void doStuff() = 0; ~Foo() = 0; }; 然后，我决定大多数的实现者Foo都想共享一些我可能会写的通用功能： class Foo { public: virtual void doStuff() = 0; ~Foo() {} protected: // If it needs this to do its thing: int internalHelperThing(int); // Or if it doesn't need the …

11 c++  design  terminology  interfaces 

给定存在类型 T = ∃X.{op₁:X, op₂:X→boolean} 这个通用的Java接口： interface T<X> { X op₁(); boolean op₂(X something); } 存在类型和Java接口之间的根本区别是什么？ 显然，在语法上存在差异，并且Java的面向对象（还包括诸如隐藏this参数等详细信息）。我对这些方面的兴趣不大，对概念和语义上的区别不那么感兴趣-尽管如果有人想阐明一些更好的观点（例如Tvs 之间的符号差异T<X>），也将不胜感激。

11 java  interfaces  type-systems 

我已经从事Windows的C＃和ASP.net MVC开发工作了一段时间。但是我在一些方面仍然不清楚。我试图了解使用和互换相似种类的通用集合接口之间的基本区别和性能问题。 之间有什么根本区别IEnumerable<T>，ICollection<T>，List<T>(Class)？ 我似乎在使用和交换它们时在我的应用程序中没有发现任何问题。另外，还有其他类似的通用集合可以与这三个集合互换吗？

11 c#  generics  interfaces 

我最近开始研究设计模式，除了一点点不同之外，我正在编写的一件事将完全适合于战略模式。 本质上，我的某些（但不是全部）算法需要一个或两个额外的参数传递给它们。 所以我要么需要 当我调用他们的calculate方法时，给他们传递一个额外的参数 要么 将它们存储为ConcreteAlgorithm类中的变量，并能够在调用算法之前对其进行更新。 有满足这种需求的设计模式吗？在坚持策略模式的同时如何实现？ 我考虑过将客户端对象传递给所有算法，并将变量存储在其中，然后仅在特定算法需要时才使用该对象。但是，我认为这既笨拙，又打败了战略模式的意义。 为了清楚起见，我正在用Java实现，因此没有太多的可选参数（可以很好地解决此问题）。

11 java  design-patterns  interfaces  strategy 

在对C＃的复杂性进行的一项研究中，我遇到了有关显式接口实现的有趣文章。 While this syntax is quite helpful when you need to resolve name clashes, you can use explicit interface implementation simply to hide more "advanced" members from the object level. 对我没有经验的眼睛来说，允许使用object.method()或要求强制转换之间的区别((Interface)object).method()似乎是卑鄙的迷惑。文中指出，这将隐藏智能感知对象级别的方法，但为什么你会想这样做，如果没有必要，以避免名称冲突？

11 c#  design  interfaces 

背景 我有一个项目，该项目取决于某种类型的硬件设备的使用情况，但是只要该硬件设备执行我需要的操作，则由谁来制造该硬件设备并不重要。话虽这么说，即使两个本来应该做同样事情的设备，如果不是由同一家制造商生产的，它们也会有差异。因此，我正在考虑使用一个接口将应用程序与所涉及设备的特定制造商/型号分离开，而使该接口仅涵盖最高级别的功能。这就是我在想我的体系结构的外观： 在一个C＃项目中定义一个接口IDevice。 在另一个C＃项目中定义的库中有一个具体的东西，它将用来表示设备。 有具体的设备实现IDevice接口。 该IDevice接口可能具有类似GetMeasurement或的方法SetRange。 使应用程序了解具体的知识，并将具体的知识传递给利用（而非实现）IDevice设备的应用程序代码。 我非常确定这是正确的做法，因为这样我就可以在不影响应用程序的情况下更改正在使用的设备（这似乎有时会发生）。换句话说，具体的实现方式GetMeasurement或SetRange实际操作方式并不重要（设备制造商之间可能会有所不同）。 我唯一的疑问是，现在应用程序和设备的具体类都依赖于包含IDevice接口的库。但是，这是一件坏事吗？ 我也看不到应用程序不需要知道设备的方式，除非设备与设备IDevice位于相同的名称空间中。 题 这似乎是实现接口以解耦应用程序与所使用设备之间的依赖关系的正确方法吗？

10 c#  design-patterns  object-oriented  interfaces  dependency-management