bit*_*onk 64 oop yagni solid-principles
我听说不遵守面向对象设计中的SOLID原则的最常见论点之一是YAGNI(尽管论证者通常不称之为):
"我可以将功能X和功能Y放在同一个类中.这很简单,为什么要添加一个新类(即复杂性)."
"是的,我可以将我的所有业务逻辑直接放入GUI代码中,它更容易,更快.这将是唯一的GUI,并且不太可能出现重要的新需求."
"如果在新的要求不太可能的情况下,我的代码变得过于混乱,我仍然可以为新要求进行重构.所以你的'如果你以后需要......怎么办？'的论点不算数."
对于这种做法,你最有说服力的论点是什么？我怎么能真正证明这是一种昂贵的做法,特别是对那些没有太多软件开发经验的人来说.
小智 45
设计是权衡的管理和平衡. YAGNI和SOLID没有冲突:前者说何时添加功能,后者说如何,但它们都指导设计过程.我在下面对每个特定报价的回答都使用了YAGNI和SOLID的原则.
- 将可重用组件构建为单次使用组件的难度是其三倍.
- 应该在三个不同的应用程序中尝试可重用的组件,然后才能足够通用以接受重用库.
-罗伯特玻璃的三大标准,软件工程的事实和谬误
重构为可重用组件的关键要素是首先在多个位置找到相同的目的,然后移动它.在这种情况下,YAGNI通过在需要时内联该目的而应用,而不必担心可能的重复,而不是添加通用或可重用的功能(类和函数).
在初始设计中,表明YAGNI不适用的最佳方法是确定具体要求.换句话说,在编写代码之前做一些重构,以证明重复不仅仅是可能的,而且已经存在:这证明了额外的努力.
是的,我可以将所有业务逻辑直接放入GUI代码中,这样更容易,更快捷.这将永远是唯一的GUI,并且不太可能出现重要的新要求.
它真的是唯一的用户界面吗？是否计划了后台批处理模式？会不会有网络界面？
您的测试计划是什么,您是否将在没有GUI的情况下测试后端功能？什么使GUI易于测试,因为您通常不希望测试外部代码(例如平台通用GUI控件),而是专注于您的项目.
我可以将功能X和功能Y放在同一个类中.这很简单,为什么要添加一个新类(即复杂性).
你能指出一个需要避免的常见错误吗？有些事情很简单,例如为一个过于简单的例子找一个数字(x * xvs squared(x)),但是如果你能指出某个人犯的具体错误 - 特别是在你的项目中或你团队中的那些人 - 你可以展示一个共同点类或函数将来会避免这种情况.
如果在新的要求不太可能的情况下,我的代码变得太杂乱,我仍然可以重构新的要求.因此,如果你以后需要......那么你的论点就不算数了.
这里的问题是"不太可能"的假设.你同意这不太可能吗？如果是这样,那么你就同意这个人的意见.如果没有,你对设计的想法与这个人不一致 - 解决这种差异会解决问题,或者至少告诉你下一步该去哪里.:)
我想借用37signals(https://gettingreal.37signals.com/ch05_Half_Not_Half_Assed.php)中的短语来考虑YAGNI的"一半,而不是一半" .这是关于限制你的范围,所以你可以专注于做最重要的事情.这不是一个草率的借口.
GUI中的业务逻辑对我来说是半途而废.除非您的系统是微不足道的,否则如果您的业务逻辑和GUI尚未独立更改几次,我会感到惊讶.因此,您应该遵循SRP(SOLID中的"S")和重构 - YAGNI不适用,因为您已经需要它.
如果您今天正在做额外的工作以适应假设的未来要求,那么关于YAGNI和不必要的复杂性的论点绝对适用.当那些"如果以后我们需要...后果"的情况未能实现时,你会因为现在影响实际变化的抽象而受到更高维护成本的困扰.在这种情况下,我们谈论的是通过限制范围来简化设计 - 做一半,而不是一半.
听起来你正在用砖墙争论.我YAGNI一个大风扇,但与此同时,我也希望我的代码将永远在至少两个地方使用:应用程序,并进行测试.这就是为什么像UI代码中的业务逻辑这样的东西不起作用的原因; 在这种情况下,您无法测试UI代码的业务逻辑.
但是,根据您所描述的回答,听起来这个人对完成更好的工作根本不感兴趣.那时,没有任何原则可以帮助他们; 他们只想尽可能做到最低限度.我甚至可以说,不是YAGNI驾驶他们的行为,而是懒惰,而你一个人不会打败懒惰(几乎没有什么可以,除了威胁的经理或失去工作).