无用的接口

Hub*_*ert 22 design-patterns interface

如果你只想实现一个接口,为什么还要使用接口呢?

Bil*_*ard 28

如果我知道只有一个实现,我就不会创建一个接口.这属于YAGNI,IMO.

(当然,我很少了解事实的未来......)

  • 我同意,如果您将API与实现分开定义,它可以简化操作.当你只有一个实现时,好处很小,但是当你有很多(甚至只有两个)时,它们真的会增加.它可能只是我的编码实践(一种非常严格的TDD形式)的工件,但我更喜欢先创建一个完全实现的类,然后使用重构来取消它的API. (10认同)
  • 如果您没有考虑多个实现,那么您可能无论如何都会出现问题.我记得一个论点,即接口的3个替代实现是一个很好的近似数字,以确保您的界面非常准确. (6认同)
  • @jjnguy为什么不计划在*之后添加*,然后计划*删除*? (2认同)
  • "除非通过开发使用抽象的几个具体实现和API来测试抽象,否则不要提供抽象.如果你在实际场景中没有测试抽象,那么你很可能会错过很难或无法修复的设计问题.未来版本中的兼容性问题." http://msdn.microsoft.com/en-us/library/ms229019.aspx (2认同)

Mat*_*ttK 22

将API与实现分开,这通常是一种很好的编程习惯.如果没有别的话,它将有助于提高可读性.它还允许将来使用您的代码的人提供接口的替代实现,如果他们愿意的话.

  • 个人认为它会损害可读性,尤其是在IDE中,当你继续关注对象并最终进入ZE INTERFACE时! (16认同)
  • 这不是公共和私人(和受保护)的用途吗? (5认同)
  • public/private帮助您分隔要在特定类中公开的内容; 它们不能帮助您提供替代实现,或适配器/装饰器等 (2认同)

jjn*_*guy 10

设置interface一个规范来编写你的代码是非常好的做法class.

如果您确定了自己interface拥有的公共方法/功能,则可以将其锁定到位.然后,class当您有一个清晰的功能时,它会变得更容易编码.

我认为让编写好的代码比保持代码库清洁更为重要.

  • 当您在团队中进行编码时,这将非常有用,否则其他人会在编译之前等待您. (11认同)
  • -1 基于上述问题(接口的单一实现)。如果您想放置脚手架,只需在对实现进行编码之前将所有方法标头写入您的类。相同的效果,没有代码异味。 (3认同)
  • 然后你的代码中有一些"脚手架",它只是在构建应用程序时才有意义. (2认同)
  • @jjnguy"一个额外的界面"?每个班级可以加一个. (2认同)

Dav*_*ley 8

因为他们错过了C++头文件?