【发布时间】:2015-03-31 05:55:45
【问题描述】:
大多数面向对象的分析和设计书籍和资源都描述了分析阶段之后是识别类的过程。我知道经验通常会让您了解应该应用哪种架构(如果有的话),但是在面向对象的设计阶段是否存在应该发生这种情况的特定点?我即将开始一个大型个人项目,我想确保我选择的架构不会忽视分析阶段的某些内容。
【问题讨论】:
-
就我而言,分析先于设计,而架构在设计中是第一位的(尽管并非所有设计模式都是架构的)。但不要过分依赖这些食谱方法。整个过程是迭代和相互依赖的,除非项目很大,否则无论如何你都会使用 PRINCE 之类的东西。
-
具体来说,我想知道在尝试识别任何类之前是否应该始终确定整体架构。基于我见过的 OOAD 流程,候选对象是从需求和用例中提取出来的,这些需求和用例会导致实际的类。如果是这种情况,我是尝试根据最初建模的类来决定架构,还是应该在对域进行任何建模之前决定架构。
-
这被称为“瀑布模型”:一个理想的、无反馈的、单向的设计和实施过程。早在 1960 年代,它就已名誉扫地。
标签: oop design-patterns architecture object-oriented-analysis