【问题标题】:Where in the object-oriented design process is an architecture pattern chosen?在面向对象的设计过程中,架构模式是在哪里选择的?
【发布时间】:2015-03-31 05:55:45
【问题描述】:

大多数面向对象的分析和设计书籍和资源都描述了分析阶段之后是识别类的过程。我知道经验通常会让您了解应该应用哪种架构(如果有的话),但是在面向对象的设计阶段是否存在应该发生这种情况的特定点?我即将开始一个大型个人项目,我想确保我选择的架构不会忽视分析阶段的某些内容。

【问题讨论】:

  • 就我而言,分析先于设计,而架构在设计中是第一位的(尽管并非所有设计模式都是架构的)。但不要过分依赖这些食谱方法。整个过程是迭代和相互依赖的,除非项目很大,否则无论如何你都会使用 PRINCE 之类的东西。
  • 具体来说,我想知道在尝试识别任何类之前是否应该始终确定整体架构。基于我见过的 OOAD 流程,候选对象是从需求和用例中提取出来的,这些需求和用例会导致实际的类。如果是这种情况,我是尝试根据最初建模的类来决定架构,还是应该在对域进行任何建模之前决定架构。
  • 这被称为“瀑布模型”:一个理想的、无反馈的、单向的设计和实施过程。早在 1960 年代,它就已名誉扫地。

标签: oop design-patterns architecture object-oriented-analysis


【解决方案1】:

这个问题意味着架构模式是一次性选择的。在一个理想的世界中(需求不会改变,并且开发人员可以读懂客户/利益相关者的想法),可能会预先提出一个巨大的设计并坚持下去。那永远不会发生。想出既实用又设计良好的软件的唯一方法是随着需求变得更加清晰而不断地重构。在重构的每个阶段,子系统都可能需要不同的架构模式。

当然,进入一个带有某种“攻击计划”的项目很重要。但是不要指望设计阶段一旦完成就结束了。没有人事先了解所有要求(即使您是自己的客户)。事情总会改变的。

简而言之,如果您没有在整个开发过程中选择架构模式,那么您要么是读心者,要么是在积累技术债务。

【讨论】:

    猜你喜欢
    • 2014-03-16
    • 2011-04-16
    • 2014-11-30
    • 1970-01-01
    • 2019-03-27
    • 2012-10-29
    • 1970-01-01
    • 2013-04-02
    • 1970-01-01
    相关资源
    最近更新 更多