软件应用程序设计

所有成功和高度可维护的软件应用程序都是严格面向对象的,还是严格面向接口的,或者严格面向方面的,或者两者的混合?

有些应用程序是成功的,有些是高度可维护的。我能想到的一个例子是Artisan Studio,一个早期采用的SysML工具,但在我去面试时发现它的可维护性非常低。它的设计是一种组件式OO C++——一个分布式的面向对象数据库,并使用COM来允许将特征添加到组件中,但是他们承认在一个大的遗留代码库上工作有很多麻烦。我怀疑,现在更便宜、更敏捷的企业架构师UML工具有一个SysML产品,成功将受到侵蚀。我没有和EA的设计师谈过,但是EA是建立在SQL数据库后端的,而自动化API显然不是一个纯粹的OO解决方案-例如,您必须使用不同的API更新UML对象相同属性的不同部分(UML包由包对象和元素元素表示,如果您更改一个API中的包的名称必须记住在另一个API中对其进行更改,否则在包树和任何关系图中都会有不同的名称。考虑到向EA中添加特性的速度和应用程序感觉的一般质量,我怀疑它比采用的“更好的OO”模型更灵活,但不容易重构。

我发现可维护性和成功,或者严格的OO和成功之间没有很强的联系。做必要的事情和重构软件的能力可能对成功更重要。还有一个好的市场部。

(重构某物与维护某物相反-在重构中,您正在更改体系结构,但功能集是静态的;维护涉及添加新功能或从现有体系结构中删除错误)

您的问题将软件项目的目标与实现它们的方法混淆了。像这样的事情/流行语 基于接口的设计 或 面向方面编程 可能是非常有益的(不要误会我:我真的很喜欢它们),但如果它们在不合适的地方使用,它们也会导致灾难性的结果。

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

混合,也许一点也没有。

任何基于非OO语言(如C)的东西都很难满足OO定义所规定的标准。

使用函数语言的项目不会遵守上述任何一项。

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