blocks|key|569208|text|这总是取决于情况。如果您知道将有另一个类使用该接口，那么是的，创建该接口类以节省稍后的时间。然而，如果你不确定(大多数时候你不确定)，那就等到你需要它的时候。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|569209|现在，这并不意味着忽略接口的可能性-考虑对象的公共方法等，并着眼于稍后创建一个接口，但不要在您的代码库中塞满您实际上不需要的东西。|569210|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It always depends on the situation. If you KNOW there is going to be another class using the interface, then yes, create the interface class to save time later. However, if you are not sure (and most of the time you aren't) then wait till you need it.

Now that doesn't mean to ignore the possibility of the interface - think about the object's public methods and such with an eye toward making an interface later, but don't clutter your codebase with anything that you don't actually NEED.

blocks|key|4634387|text|我想说的是，这更多地取决于你将在多少地方使用这个类，而不是多少个类可能实现这个接口。如果你只在一个或两个地方使用文件夹，那么我建议你在实现和重构之前，等到真正需要这个接口时再使用它。然而，如果文件夹要在100个不同的地方使用，那么你可以通过预先编程到一个界面来节省一些时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4634388|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I would say it depends more on how many places you're going to use the class, and less on how many classes might possibly implement the interface. If you're only using Folder in one or two places then I would say wait until there's an actual need for the interface before you implement it and refactor. However, if Folder is going to be used in 100 different places, then you can save some time by programming to an interface up front.

blocks|key|1151416|text|总会有一个测试使用它，对吧(你做单元测试，不是吗？)这意味着总是有N%2B1个类在使用它，其中N是在应用程序中使用您的类的类的数量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1151417|除了依赖注入之外，接口的另一个目的是分离关注点，以便您的类可以实际实现多个接口。|1151418|请记住所有这些，但是如果在开始时没有实现，那么您可以在以后通过重构引入接口。|1151419|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There will be always a test that use it, right (you do unit tests, don't you?). Which means it's always N + 1 classes that use it, where N is number of classes that use your class in application. 

Another purpose of interface besides dependency injection is separation of concern so that your class may actually implement multiple interfaces.

Keep all of that in mind but you can always have interface(s) introduced later via refactoring if not implemented in the beginning.

blocks|key|1151447|text|一般来说，如果只有一个类要实现一个接口，你就不应该费心去创建它，即使你期望它有一个可能的类，因为可能会出现实现问题，直到在场景中实际测试了类，在这种情况下，过早创建的接口可能有太多的成员，或者可能缺少一个成员。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1151448|例如，.NET框架基础类库团队承认在ICollection包含SyncRoot属性时过早地设计了它。对于后来的通用ICollection<T>，他们决定将其删除(http://blogs.msdn.com/bclteam/archive/2005/03/15/396399.aspx)。|offset|length|style|CODE|1151449|如果您要创建一个实现相同接口的模拟对象，那么这将被视为第二个实现，从而证明创建接口是合理的。然而，并不是所有的单元测试都需要模拟风格的接口。|1151450|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/bclteam/archive/2005/03/15/396399.aspx^0|0|I|B|V|8|1L|E|29|1O|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@$D|T|E|U|F|G]|$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Generally, you shouldn't bother with creating an interface if only one class is going to implement it, even if you anticipate a possible class for it since there may be implementation issues that won't come up until the class is actually tested in a scenario, in which case a prematurely created interface may have too many memebrs or may be missing a member. 

For example, the .NET Framework Bas Class Library team has admitted to prematurely designing <code>ICollection</code> when it included a <code>SyncRoot</code> property. For the later generic <code>ICollection&lt;T&gt;</code> they decided to remove it (<a href="http://blogs.msdn.com/bclteam/archive/2005/03/15/396399.aspx" rel="nofollow noreferrer">http://blogs.msdn.com/bclteam/archive/2005/03/15/396399.aspx</a>).

If you are going to create a mock object implementing the same interface then that would count as a second implementation that justifies creating the inteface. Not all unit tests warrant a mock-style interface, though.

blocks|key|1151476|text|可以将接口看作是定义语义或概念的契约。这是一种通用的方法，并不是真正特定于语言。在面向对象的上下文中，如果您使用的是单一继承模型，那么在定义对象模型时，最好使用接口而不是类，因为单个超类路径非常宝贵，并且您希望将其保存到比定义在对象或方法上公开的属性更“重要”的东西上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1151477|让IContainer语义(契约)在你的文件夹之外创建一个接口是一个相当糟糕的理由；最好让你的文件夹(如果它正在做任何重要的逻辑)在你的语言的核心框架中‘实现’(可能已经存在)+IContainer或ICollection接口。|1151478|一如既往，更好的选择完全取决于具体的问题。如果您的配方也是文件夹(?!)您可能在考虑父子关系或组合关系--一种可以(也应该)使用接口表达的语义，前提是您的系统中的其他元素将对使用这种语义组合的事物进行“操作”。|1151479|接口有一些开销(编程方面的)，如果您发现自己只使用了一组Woof和IWoof类和接口，那么您就会知道您可能不需要用接口来表达您的问题--简单的类就足够了。|1151480|通常，对于任何I，都应该至少有两个具体的类(除了IImpl或之外，还有更有意义的名称)。|1151481|希望这能有所帮助。|1151482|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Think of an interface as a contract to define semantics, or a concept. That's a general approach and not really language specific. In context of OO, if you are working in a single inheritance model, there is an excellent case to be made for preferring interfaces over classes for defining your object model, since that single super class pathway is fairly precious and you want to save it for something more 'substantial' than defining properties that are exposed on an object, or methods.

To have IContainer semantics (contract) is a fairly poor reason to make an interface out of your folder; better to have your folder (if it is doing any non-trivial logic) 'implement' the (likely already existing) IContainer or ICollection interface in your language's core frameworks.

As always, the better choice is fairly dependent on the specific problem. In case of your recipes that are also folders (?!) you are probably thinking of a parent-child, or composition, relationship -- a semantic that can (and should) be expressed using interfaces if you will have other elements in your system 'operate' on things that are composed using that sort of semantics.

There is a bit of overhead (programming wise) with interfaces, and, if you find yourself when you are done with nothing more than a set of Woof and IWoof classes and interfaces, then you'll know you probably didn't need to express your problem in terms of interfaces -- simple classes would have been sufficient. 

As a rule, for any I, you should have at least a couple of concrete classes (with more meaningful names other than IImpl, or ).

Hope that helps.

blocks|key|3790519|text|很多人已经概述了非常合理的建议。我想补充的一件事是，如果您希望避免对具体类的直接硬依赖，那么接口将通过提供松散耦合来帮助您。如果您正在创建一个基于插件的体系结构，那么接口绝对是最佳选择。此外，如果您计划并排或稍后编写单元测试，您可能会注意到，调用您的文件夹类的代码必须携带一个具体的实现才能使调用代码可测试。如果您的folder类的具体实现依次与DB或服务对话，那么您也需要将其带入测试，这很快就会变得非常笨拙。就我的两分钱。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3790520|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

A lot of the people have already outlined very sound advice. 
One thing I'd like to add is that if you are looking to avoid direct hard dependencies on concrete classes then interfaces will help by providing loose coupling. 
If you are creating a plug-in based architecture then interfaces are definitely the way to go. Also, if you are planning to write unit tests either side by side or later down the line, you will probably notice that code which calls into your folder class(es) will have to carry around a concrete implementation for the calling code to be testable. 
If your concrete implementation of the folder class(es) is in turn talking to a DB or a service then you will need to have that carried over into your tests as well which will get unwieldy very quickly. 
Just my 2 cents.

Should you always create an interface if there's a possibility that there might be something else that could use it, or wait until there's an actual need for it then refactor to use an interface?

Programming to an interface generally seems like sound advice, but then there's YAGNI...

I guess maybe it depends on the situation. Right now I have an object representing a folder that can contain recipes or other folders. Instead of using Folder directly, should I worry about implementing something like IContainer? In case in the future I want to have a recipe that refers to other sub recipes (say an apple pie recipe that is also a container for a pie crust recipe)

Should you create an interface when there (currently) is only going to be one class that implements it?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

你是不是应该总是创建一个接口，如果可能有其他东西可以使用它，或者等到实际需要它，然后重构来使用一个接口？对接口进行编程通常看起来像是合理的建议，但还有YAGNI...我想这可能要视情况而定。现在，我有一个表示文件夹的对象，该文件夹可以包含食谱或其他文件夹。与其直接使用文件夹，我是否应该担心实现像IContainer这样...

问当(目前)只有一个实现接口的类时，你应该创建一个接口吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当(目前)只有一个实现接口的类时，你应该创建一个接口吗？EN