Interface 软件应用程序设计

在软件应用程序开发中，是否需要严格的面向对象/基于接口的设计/面向方面的设计

或者，为了便于编码，是否需要混合所有这些功能

所有成功且高度可维护的软件应用程序都是严格面向对象的，还是严格面向接口的，还是严格面向方面的，还是它们的混合

如果它们如此严格，我应该遵循哪种方法来避免分析瘫痪，同时在这三种情况下实现极其强大的设计

如果你认为，基于接口的编程和AOP只是OOP的扩展，那么你可以这样想，在基于接口的编程和AOP的概念出现之前，软件是如何设计的

---

而且AOP可能还需要一个AOP容器。

一个混合，也许根本就没有

任何基于非OO语言（例如C）的东西都很难满足OO定义规定的标准

函数式语言中的项目不会遵守上述任何一项

---

所有这些“面向对象”的设计方法就是这样。方向。您应该能够认识到每种方法的优缺点，并根据适当性、复杂性、预算、时间尺度、可维护性等，学会在需要时进行混合和匹配。

您的问题将软件项目的目标与实现目标的方法混淆了。诸如基于接口的设计或AOP之类的东西/流行语可能非常有益（别误会：我真的很喜欢它们），但如果它们被用在不合适的地方，也可能导致灾难性的结果

如果你有钉子，那就用锤子。如果你有螺丝，那就用螺丝刀。如果没有它们，那么这两个工具都不会有用

所有成功且高度可维护的软件应用程序都是严格面向对象的，还是严格面向接口的，还是严格面向方面的，还是它们的混合

有些应用程序是成功的，有些是高度可维护的。我能想到的一个例子是Artisan Studio，一个早期采用SysML工具的公司，但在我接受采访时，它的可维护性非常低。它的设计是一种组件式OO C++——一个分布式的面向对象数据库，并使用COM来允许添加组件作为组件；但他们承认在处理大型遗留代码库时遇到了很多困难。我怀疑现在更便宜、更敏捷的企业架构师UML工具有一个SysML产品，它的成功将受到侵蚀。我没有和EA的设计师谈过，但是EA是建立在SQL数据库后端上的，自动化API显然不是一个纯粹的OO解决方案——例如，您必须使用不同的API更新UML对象的相同属性的不同部分（一个UML包由一个包对象和一个元素表示，如果您在一个API中更改了包的名称，您必须记住在另一个API中更改它，否则它在包树和任何图表中都会有不同的名称）.考虑到EA中添加功能的速度，以及应用程序的总体感觉质量，我怀疑它比Artisan采用的“更好的OO”模型更灵活，但无法轻松重构

我没有发现可维护性和成功，或者严格的OO和成功之间有很强的联系。做需要做的事情和重构软件的能力可能对成功更重要。这和一个好的营销部门

---

（重构某物与维护某物相反——在重构过程中，您正在更改体系结构，但功能集是静态的；维护涉及添加新功能或从现有体系结构中删除bug）

这非常令人困惑，因为接口和AOP设计通常被视为面向对象设计的变体。您能否解释一下“严格”和“混合”的含义来澄清您的问题？AOP容器？这样的东西是不存在的-我想你听说过一种叫做“IoC容器”的东西。请不要只是为了它而到处乱说流行语-这会让你的编程比忽略它们更糟糕。