(在.NET的背景下,它的价值)
我倾向于不使用继承,很少使用接口.我遇到了一个认为接口是自吐以来最好的东西的人.他到处使用它们.我不明白这一点,因此接下来的问题.我只想检查一下我对接口的理解.
如果您在任何地方使用接口,我假设您可以预测未来,您的应用程序要求已经确定,并且应用程序中的任何内容都不会发生变化.对我来说,特别是在早期开发过程中,界面变得拖累.该应用程序在其生命中非常有活力.如果你需要减去或添加成员到界面,很多东西都会破坏.上面的人说他创建了另一个界面来处理新成员.什么都没有打破.
那不是那个构图吗？为什么不使用没有接口的组合？更灵活.
他如何处理必须从界面中减去成员的情况？基本上他没有.事情刚刚破裂,这很好,因为现在你可以看到所有受影响的区域并修复它们.我们应该通过暴力破解掉部分类,而不是更优雅地找出所有相关代码路径的位置？
我认为软件应用程序是一个图形.完整的图表是最坏的情况,具有n(n-1)/ 2.这意味着每个班级都与每个班级交谈.令人困惑的蜘蛛网.n-1是最好的,它们是严格的沟通等级.添加另一个接口只是为了补偿一个新的需要成员,为图形添加一个vertici,这意味着更多的边缘和更强的n(n-1)/ 2方程的实现.没有接口的组合更像是mixins.只有选择类使用特定方法.使用接口,所有类都被迫使用成员,即使他们不需要它们.组合/混合方法不会添加新的不需要的边.
接口不强制类使用方法.他们强制实现类来实现所有方法,但这是另一回事.
我喜欢接口将API与实现分开的方式.不可否认,这也是通过访问修饰符完成的,但接口使其更清晰.更重要的是,接口也使得模拟更容易 - 这意味着您甚至可以在实现之前对依赖于接口的类进行单元测试.
是的,这意味着我经常会得到一个只有一个生产实现的界面.在我看来,这不是问题,因为我已经获得了可测试性.
另一方面,我没有为每个类编写接口.我喜欢编写一个对象基本上提供服务的接口 - 身份验证,数据访问等.简单数据对象(即使具有重要行为)在接口IME方面也不那么有用.
根据维基百科,
工业中多态性的主要用法(面向对象编程理论)是属于不同类型的对象响应同名的方法,字段或属性调用的能力,每个调用根据适当的类型特定行为.程序员(和程序)不必事先知道对象的确切类型,因此确切的行为是在运行时确定的(这称为后期绑定或动态绑定).
这就是使接口如此有用的原因.
"上面的人说他创建了另一个界面来处理新成员.没有什么能打破."
我只是在这里猜测,但听起来这个家伙来自旧学校的COM背景(当然,我可能是错的!).让我感到畏缩,想到我曾经在我看过这样的事情的所有代码:
IWidgetManager
IWidgetManager2
IWidgetManager3
这不是使用接口的好方法.根据我的经验,我已经看到了两个极端:害怕将接口更改为每当添加新成员时创建新接口的点,或者根本不使用接口并且产品具有高度耦合性.你需要找到一个很好的平衡点.改变界面并不总是世界末日.
您正在进行的项目规模是多少？如果它是一个规模相对较小的项目,很难看到接口的好处.另一方面,如果它是一个包含数十万行代码并且由许多模块组成的项目,那么其好处就会变得更加明显.
接口有许多有用的情况.当您需要向可以在各种类中找到的类添加特定行为时,这是接口的最佳时间.一个很好的例子就是IDisposable界面 - 你有一些资源,当你完成后,需要及时消失.它是数据库连接吗？它是一些窗口处理？无所谓.
另一个例子是当你真的不知道应该如何实现它时,例如一个尚不存在的对象的接口.也许该对象应该由您的库的客户提供,或者必须由不受您控制的完全不同的模块实现.您基本上可以为类中可用的方法设计合同.
也就是说,我只在需要的地方使用它们.如果我可以使用常规类,或者如果它是特定对象固有的东西,我将使它成为一个类.正如其他人所说的那样,为每个类使用接口有一些优点,但这是一个额外的开销,我没有看到它有不错的净收益.大多数时候,我设计了我的类结构,使它们平坦而宽阔,并且尽可能少地依赖.
总结:如果您需要的通用功能有很大不同,那么接口就是您所需要的.
京公网安备 11010802040832号 | 京ICP备19059560号-6 