在软件应用程序开发的情况下，是否需要严格的基于OOD /接口的设计/面向方面设计？
或者，为了便于编码，是否需要将所有这些混合起来？
所有成功且高度可维护的软件应用程序是否严格面向对象，或严格面向接口，或严格的面向方面，或它们的混合？
如果它们如此严格，我应遵循哪种方法来避免分析瘫痪，同时在这三种情况下实现极其强大的设计？
如果你认为，基于接口的编程和AOP只是OOP的扩展，那么就这样思考，在基于接口的编程和AOP的概念到来之前，软件是如何设计的？
AOP也可能需要一个AOP容器。
答案 0 :(得分：1)
您的问题会将软件项目的目标与实现这些目标的方法混为一谈。像基于界面的设计或 AOP 这样的事物/流行语可能非常有益（不要误解我：我真的很喜欢它们），但它们也会导致灾难性的后果，如果他们被用在他们不合适的地方。
如果你有指甲，那就用锤子。如果您有螺丝，请使用螺丝刀。如果没有，那么这两个工具都不会有用......
答案 1 :(得分：1)
所有成功且高度可维护的软件应用程序是否严格面向对象，或严格面向接口，或严格的面向方面，或它们的混合？
有些应用程序是成功的，有些是高度可维护的。我能想到的一个例子是早期采用的SysML工具Artisan Studio，但在我接受采访时遇到的可维护性非常低。它的设计是组件样式OO C ++ - 一个分布式OO数据库，并使用COM来允许将功能添加为组件;但他们承认在处理大型遗留代码库时遇到了很多麻烦。我怀疑现在更便宜，更灵活的Enterprise Architect UML工具有一个SysML产品，成功将会受到侵蚀。我没有和EA的设计人员谈过，但EA建立在SQL数据库后端，而自动化API显然不是纯粹的OO解决方案 - 例如，你必须更新UML的相同属性的不同部分使用不同API的对象（UML包由Package对象和Element元素表示，如果您在一个API中更改包的名称，则必须记住在另一个API中更改它，否则它将具有不同的名称在包树和任何图表上）。考虑到EA添加功能的速度，以及应用程序感觉的总体质量，我怀疑它比Artisan采用的“更好的OO”模型更敏捷，但不能轻易重构。
我没有发现可维护性与成功之间，或严格的OO与成功之间存在紧密联系。做所需要的事情以及重构软件的能力可能对成功更为重要。那是一个很好的营销部门。
（重构某些东西与维护某些东西相反 - 在重构中你正在改变架构，但功能集是静态的;维护涉及添加新功能或从现有架构中删除错误）
答案 2 :(得分：0)
混合，也许根本没有。
基于非OO语言（例如C）的任何内容都将难以满足OO定义所强加的标准。
功能语言的项目不会遵守上述任何一项。
所有这些“导向”的设计方法就是这样。 取向。您应该能够认识到每种方法的优缺点，并根据适当性，复杂性，预算，时间尺度，可维护性等，学习根据需要进行混合和匹配。