我正在努力理解如何将单一职责原则与 OOP 结合使用。
如果我们要完全遵循这一原则，那么我们是否会留下许多类，其中许多类可能每个都只有一个方法？
如果我们不严格遵循这个原则，那么这个原则还有什么意义呢？
我喜欢这样陈述单一职责原则：“你编写的每件事——每个模块、类、接口或方法，都应该具有one工作。它应该做whole工作和only那份工作。
请注意，您编写的有些东西很大（模块），有些很小（方法），有些介于两者之间（类），有些大东西是由较小的东西组成的。
这不是问题，因为工作或职责也有不同的规模，并且可以分层分解。例如，警察部队的工作是“保护和服务”——一项工作可以分解为“巡逻街道”、“解决犯罪”等，每个工作都可以由不同的单位处理。这就产生了协调的需要（不同的工作），每个单位的工作又分解为各个官员的工作等。
对于每一项大工作，都有很多方法可以将其分解为更小的工作，并且每一项都可以通过遵守 SRP 和其他 SOLID 原则的软件设计来建模。决定如何分解问题是软件设计艺术的重要组成部分。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
