我个人参与了几个软件项目的编写或扮演了重要角色,但直到最近我才接触到这种设计模式。我很喜欢这个原则,并且真的想开始使用它。我发现Joel在播客中的论点相当薄弱(如果您继续阅读 这里的博客评论,其他人也是这样认为)。 但是,这是否有任何道理呢?
社区有什么看法?
我个人参与了几个软件项目的编写或扮演了重要角色,但直到最近我才接触到这种设计模式。我很喜欢这个原则,并且真的想开始使用它。我发现Joel在播客中的论点相当薄弱(如果您继续阅读 这里的博客评论,其他人也是这样认为)。 但是,这是否有任何道理呢?
社区有什么看法?
我没有阅读或听过Joel的评论,因此无法具体评论。
我认为你必须从目标的角度来看待单一职责原则,而不是严格要求。与软件开发中的许多事情一样,有理想的目标应该努力实现,但除非你的代码没有经济效益或成本,否则你必须在满足客户需求方面具有实用性。
这就是AOP的产生原因。使用它,您无需更改任何内容,只需更改日志记录类即可更改日志记录。
为了明显的原因,追求面向业务的单一职责原则是好的,但对于足够复杂的系统,您永远无法获得真正的OOP单一职责原则。AOP可以,但OOP不行。
我不知道Joel的推理是否如此,但这就是我处理该想法的方式。
我认为SOLID原则有时不符合设计类时通常应用的自然/业务逻辑。Robert C. Martin提出了一个关于矩形和正方形类的例子(正方形不应该是矩形的子类)。
http://www.hanselminutes.com/default.aspx?showID=163
我不确定它是否涉及SRP,但是思想是相同的。SOLID原则可能会导致违反直觉的决策,很难克服这个障碍。
对我来说,“指南”比“原则”更合适的名称。
我认为作为一个遵循SRP的有纪律的OO开发者所获得的最大好处是易于测试和维护,因此我认为SRP是任何需要被测试/维护的系统(基本上除了一些临时系统)的一个良好目标。
我一般同意SOLID原则,但你也得考虑到它们的背景。如果你正在编写一个概念验证(POC),那么SOLID原则的适用性会降低。
另一方面,如果你正在开发一个寿命长达数年的产品,那么你最好仔细研究并应用SOLID原则。否则公司将花费大量资金来提高生产力。
关于Joel和他的评论,他有一个有效的观点。有时候产品需要发布,否则公司就会失败。这就是现实。
作为开发人员,你的工作是发布产品,但紧迫的截止日期并不意味着你要选择一个差劲的架构。例如,你使用数据集还是业务实体的选择是一个简单的决定,两者在实现方面都有类似的付出,但长期来看,两者在新功能开发和维护方面的差异是显著的。
我认为编写一个简单的一行代码作为所有类的主要职责应该是可能的。这个一行代码中的“and”通常不是一个好兆头。然后,单一职责往往归结为选择适当的抽象。
GUI附近的类往往反映了GUI并具有“作为XXXX的GUI”的单一职责。Coward的解决方案..