blocks|key|842717|text|我现在能想到的就是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|842718|优点：|842719|接口和implementation|842720|Reduced单元之间的清晰分离dependencies|unordered-list-item|842721|
|842722|Multiple+inheritance|842723|842724|Reference计数(如果需要，可以禁用)|842725|842726|842727|842728|缺点：|842729|不能混合使用|842730|类和接口引用(至少所有属性都需要引用references|842731|Debugging和setter函数)|842732|引用计数不适用于循环counting)|842733|Getter困难(感谢gabr和Warren指出这一点)|842734|842735|842736|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1B|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1C|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|1D|8|@]|9|@]|A|$]]|$1|M|3|J|5|6|7|1E|8|@]|9|@]|A|$]]|$1|N|3|O|5|H|7|1F|8|@]|9|@]|A|$]]|$1|P|3|-4|5|H|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1J|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1K|8|@]|9|@]|A|$]]|$1|W|3|X|5|H|7|1L|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|H|7|1M|8|@]|9|@]|A|$]]|$1|10|3|11|5|H|7|1N|8|@]|9|@]|A|$]]|$1|12|3|13|5|H|7|1O|8|@]|9|@]|A|$]]|$1|14|3|-4|5|H|7|1P|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]]|17|$]]

All I can think of for now:

Pros:

<ul>
<li>Clear separation between interface and implementation</li>
<li>Reduced unit dependencies</li>
<li>Multiple inheritance</li>
<li>Reference counting (if desired, can be disabled)</li>
</ul>

Cons:

<ul>
<li>Class and interface references cannot be mixed (at least with reference counting)</li>
<li>Getter and setter functions required for all properties </li>
<li>Reference counting does not work with circular references</li>
<li>Debugging difficulties (thanks to gabr and Warren for pointing that out)</li>
</ul>

blocks|key|842877|text|除了答案之外，还有几个优点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|842878|842879|使用接口来表示行为，行为的每个实现都将实现该接口。|ordered-list-item|842880|应用编程接口发布:在发布API时，接口非常适合使用。你可以发布一个接口而不给出实际的实现。因此，您可以自由地进行内部结构更改，而不会给客户端带来任何问题。|842881|842882|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|M|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|N|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|J|$]]

Adding to the answers few more advantages:

<ol>
<li>Use interfaces to represent the behavior and each implementation of a behavior will implement the interface.</li>
<li>API Publishing: Interfaces are great to use when publishing APIs. You can publishing an interface without giving out the actual implementation. So you are free to make internal structural changes without causing any problems to the clients.</li>
</ol>

blocks|key|2911039|text|我要说的是，没有引用计数的接口在我的delphi愿望列表中非常重要！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2911040|-->接口的真正用途是接口的声明。没有引用计数的能力！|2911041|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|$]]

All I say is that interfaces WITHOUT reference counting are VERY HIGH on my wishlist for delphi!!!

--> The real use of interfaces is the declaration of an interface. Not the ability for reference counting!

blocks|key|2911155|text|界面有一些微妙的缺点，我不知道人们在使用它们时是否会考虑这些缺点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2911156|2911157|调试变得更加困难。我在调试器中看到了很多进入接口方法调用的奇怪的困难。Delphi中的|ordered-list-item|2911158|接口带有IUnknown语义，不管你喜欢与否，你都坚持引用计数是一个受支持的接口。因此，对于在Delphi中创建的任何接口，您必须确保正确处理引用计数，如果不正确处理，您将以泄漏告终。当你想要避免引用计数时，你唯一的选择就是覆盖addref/decref，实际上不释放任何东西，但这也有它自身的问题。我发现更严重的接口负载的代码库有一些最难找到的访问冲突和内存泄漏，我认为这是因为很难结合引用计数语义和默认的delphi语义(所有者释放对象，没有其他人这样做，并且大多数对象在使用接口的parents.).|2911159|Badly-done实现的整个生命周期中都存在)可能会造成一些令人讨厌的代码味道。例如，在定义类的初始具体实现的同一单元中定义的接口，添加了所有接口的权重，而没有真正在接口的用户和实现者之间提供适当的分离。我知道这不是接口本身的问题，而是那些编写基于接口的代码的人的吹毛求疵。请将您的接口声明放在只包含这些接口声明的单元中，并避免由于将您的接口声明放入与您的实现者类相同的单元中而导致的单元到单元依赖地狱。|2911160|2911161|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|N|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

There are some SUBTLE downsides to interfaces that I don't know if people consider when using them:

<ol>
<li>Debugging becomes more difficult. I have seen a lot of strange difficulties stepping into interfaced method calls, in the debugger. </li>
<li>Interfaces in Delphi come with IUnknown semantics, if you like it or not, you'r stuck with reference counting being a supported interface. And, thus, with any interfaces created in Delphi's world, you have to be sure you handle reference counting correctly, and if you don't, you'll end up with leaks. When you want to avoid reference counting, your only choice is to override addref/decref and don't actually free anything, but this is not without its own problems. I find that the more heavily interface-laden codebases have some of the hardest-to-find access violations, and memory leaks, and this is, I think because it is very difficult to combine the refcount semantics, and the default delphi semantics (owner frees objects, and nobody else does, and most objects live for the entire life of their parents.).</li>
<li>Badly-done implementations using Interfaces can contribute some nasty code-smells. For example, Interfaces defined in the same unit that defines the initial concrete implementation of a class, add all the weight of interfaces, without really providing proper separation between the users of the interfaces and the implementors. I know this isn't a problem with interfaces themselves, but more of a quibble with those who write interface-based code. Please put your interface declarations in units that only have those interface declarations in them, and avoid unit-to-unit dependency hell caused by glomming your interface declarations into the same units as your implementor classes.</li>
</ol>

blocks|key|4510266|text|当我希望具有不同祖先的对象提供公共服务时，我主要使用接口。根据我自己的经验，我能想到的最好的例子是一个名为IClipboard的接口|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4510267|IClipboard+=+interface
++function+CopyAvailable:+Boolean;
++function+PasteAvailable(const+Value:+string):+Boolean;
++function+CutAvailable:+Boolean;
++function+SelectAllAvailable:+Boolean;
++procedure+Copy;
++procedure+Paste(const+Value:+string);
++procedure+Cut;
++procedure+SelectAll;
end;|code-block|syntax|javascript|4510268|我有一堆从标准VCL控件派生的自定义控件。它们各自实现了这个接口。当剪贴板操作到达我的一个窗体时，它会查看活动控件是否支持此接口，如果支持，则调度适当的方法。|4510269|对于一个非常简单的接口，您可以使用of+object事件处理程序来实现这一点，但是一旦它变得足够复杂，接口就可以很好地工作。事实上，我认为这是一个非常好的类比。使用一个接口，在这个接口中，单个of+object事件不适合该功能。|4510270|entityMap^0|1H|A|0|0|0|H|9|2O|9|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|P|$]]

I mostly use interfaces when I want objects with different ancestry to offer a common service. The best example I can think of from my own experience is an interface called <code>IClipboard</code>:

<pre><code>IClipboard = interface
 function CopyAvailable: Boolean;
 function PasteAvailable(const Value: string): Boolean;
 function CutAvailable: Boolean;
 function SelectAllAvailable: Boolean;
 procedure Copy;
 procedure Paste(const Value: string);
 procedure Cut;
 procedure SelectAll;
end;
</code></pre>

I have a bunch of custom controls derived from standard VCL controls. They each implement this interface. When a clipboard operation reaches one of my forms it looks to see if the active control supports this interface and, if so, dispatches the appropriate method.

For a very simple interface you can do this with an <code>of object</code> event handler, but once it gets sufficiently complex an interface works well. In fact I think that is a very good analogue. Use an interface where you a single <code>of object</code> event won't fit the functionality.

blocks|key|1771126|text|接口解决了某些类型的问题。它的主要功能是...好的，...define接口。来区分定义和实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1771127|当你想指定或者检查一个类是否支持一组方法时--使用接口。|1771128|您不能以任何其他方式做到这一点。|1771129|(如果所有类都继承自同一基类，则抽象类将定义接口。但是，当您处理不同的类层次结构时，您需要接口来定义您拥有的共同的方法...)|1771130|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Interfaces solves a certain kind of issues. The primary function is to... well, ...define interfaces. To distinguish between definition and implementation.

When you want to specify or check if a class supports a set of methods - use interfaces.

You cannot do that in any other way.

(If all classes inherits from the same base class, then an abstract class will define the interface. But when you are dealing with different class hierarchies, you need interfaces to define the methods thy have in common...)

blocks|key|843061|text|关于缺点的额外说明:性能|type|unstyled|depth|inlineStyleRanges|entityRanges|data|843062|我认为很多人过于轻率地忽视了接口的性能损失。(并不是我不喜欢和使用接口，而是你应该意识到你进入了什么境地)。接口的代价可能很高，不仅是因为_AddRef+/+_Release命中(即使只是返回-1)，而且还因为属性需要有一个Get方法。根据我的经验，类中的大多数属性都可以直接访问读访问器(例如，propery+Prop1:+Integer+read+FProp1+write+SetProp1)。改变这一点，对函数调用的无惩罚访问可能会显著影响您的速度(特别是当您开始在循环中添加10个属性调用时。|843063|例如，一个使用类的简单循环|843064|for+i+:=+0+to+99+do
begin
++j+:=+(MyClass.Prop1+%2B+MyClass.Prop2+%2B+MyClass.Prop3)+/+MyClass.Prop4;
++MyClass.Update;
++//+do+something+with+j
end;|code-block|syntax|javascript|843065|当类成为接口时，从0个函数调用变为400个函数调用。在该循环中添加更多的属性，很快就会变得更糟。|843066|你可以通过一些技巧来改善_AddRef+/+_Release的损失(我相信还有其他的技巧。这是我想不到的)：|843067|843068|与temp变量一起使用或赋值给temp变量，以仅导致每个代码块一个_AddRef+/+_Release的惩罚|unordered-list-item|843069|始终将使用const关键字的接口传递到函数中(否则，每次调用该函数时都会发生额外的_AddRef+/+_Release。|843070|843071|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|10|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|11|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|12|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|14|8|@]|9|@]|A|$]]|$1|S|3|T|5|R|7|15|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|W|$]]

Extra note on 
Cons: Performance

I think many people are too blithely dismissing the performance penalty of interfaces. (Not that I don't like and use interfaces but you should be aware of what you are getting into). Interfaces can be expensive not just for the _AddRef / _Release hit (even if you are just returning -1) but also that properties are REQUIRED to have a Get method. In my experience, most properties in a class have direct access for the read accessor (e.g., propery Prop1: Integer read FProp1 write SetProp1). Changing that direct, no penalty access to a function call can be significant hit on your speed (especially when you start adding 10s of property calls inside a loop.

For example, a simple loop using a class

<pre><code>for i := 0 to 99 do
begin
 j := (MyClass.Prop1 + MyClass.Prop2 + MyClass.Prop3) / MyClass.Prop4;
 MyClass.Update;
 // do something with j
end;
</code></pre>

goes from 0 function calls to 400 function calls when the class becomes an interface. Add more properties in that loop and it quickly gets worse.

The _AddRef / _Release penalty you can ameliorate with some tips (I am sure there are other tips. This is off the top of my head):

<ul>
<li>Use WITH or assign to a temp variable to only incur the penalty of one _AddRef / _Release per code block</li>
<li>Always pass interfaces using const keyword into a function (otherwise, you get an extra _AddRef / _Release occurs every time that function is called.</li>
</ul>

blocks|key|2910754|text|当我们不得不使用接口(除了COM/ActiveX+)时，唯一的情况是我们需要多重继承，而接口是获得它的唯一方法。在其他几种情况下，当我们尝试使用接口时，我们遇到了各种各样的问题，主要是引用计数(当对象既作为类实例访问又通过接口访问时)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2910755|因此，我的建议是，只有在你知道你需要它们的时候才使用它们，而不是当你认为它可以在某些方面让你的生活更容易的时候。|2910756|更新:正如David提醒的那样，对于接口，您只能获得接口的多重继承，而不是实现的多重继承。但这对我们的需求来说已经很好了。|2910757|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|$]]

The only case when we had to use interfaces (besides COM/ActiveX stuff) was when we needed multiple inheritance and interfaces were the only way to get it. In several other cases when we attempted to use interfaces, we had various kinds of problems, mainly with reference counting (when the object was accessed both as a class instance and via interface). 

So my advice would be to use them only when you know that you need them, not when you think that it can make your life easier in some aspect.

Update: As David reminded, with interfaces you get multiple inheritance of interfaces only, not of implementation. But that was fine for our needs.

blocks|key|842957|text|除了其他人已经列出的东西之外，接口的一个很大的优势是聚合它们的能力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|842958|我之前写了一篇关于这个主题的博客文章，可以在这里找到：http://www.nexusdb.com/support/index.php?q=intf-aggregation+(tl;dr:你可以有多个对象，每个对象实现一个接口，然后将它们组装成一个聚合，在外界看来就像一个实现所有这些接口的单个对象)|offset|length|842959|你可能还想看看“接口基础”和“高级接口用法和模式”的帖子。|842960|entityMap|0|LINK|mutability|MUTABLE|url|http://www.nexusdb.com/support/index.php?q=intf-aggregation^0|0|R|1N|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Beyond what others already listed, a big pro of interfaces is the ability of aggregating them.

I wrote a blog post on that topic a while ago which can be found here: <a href="http://www.nexusdb.com/support/index.php?q=intf-aggregation" rel="nofollow">http://www.nexusdb.com/support/index.php?q=intf-aggregation</a> (tl;dr: you can have multiple objects each implementing an interface and then assemble them into an aggregate which to the outside world looks like a single object implementing all these interfaces)

You might also want to have a look at the "Interface Fundamentals" and "Advanced Interface Usage and Patterns" posts linked there.

I have used Delphi classes for a while now but never really got into using interfaces. I already have read a bit about them but want to learn more. 

I would like to hear which pros and cons you have encountered when using interfaces in Delphi regarding coding, performance, maintainability, code clearness, layer separation and generally speaking any regard you can think of.

Thanks and best regards

What are the pros and cons of using interfaces in Delphi?

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我使用Delphi类已经有一段时间了，但从来没有真正开始使用接口。我已经读过一些关于它们的文章，但还想了解更多。我想听听你在Delphi中使用接口时，在编码、性能、可维护性、代码清晰度、层分离以及你能想到的任何方面都遇到了哪些利弊。感谢并致以最良好的问候

问在Delphi中使用接口的优缺点是什么？
EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Delphi中使用接口的优缺点是什么？EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Delphi中使用接口的优缺点是什么？
EN