Два способа проектирования сложной системы: сверху вниз и снизу вверх - PullRequest
5 голосов
/ 11 февраля 2011

У меня сложная система для проектирования.У меня есть два способа:

  1. Сверху вниз : я разработаю множество интерфейсов и контрактов.После этого я реализую эти интерфейсы и напишу прототип для проверки проекта.

  2. Вверх : я напишу код для запуска системы.После слов я буду извлекать интерфейсы и контракты из твердого кода.Дистиллированные интерфейсы и контракты - мой дизайн.Это правило " заставить его работать, сделать это правильно ".

Что лучше?На мой взгляд, я выберу снизу вверх.Поскольку нисходящий процесс очень сложен, никто не может спроектировать много интерфейсов на высоком абстрактном уровне, по крайней мере, для меня это сложно.Когда я пишу надежную реализацию для проверки первоначального дизайна, есть много неразумных вещей, которые заставляют меня перепроектировать с нуля.Хотя я использую «снизу вверх», я чувствую себя довольно «в безопасности», он может работать как минимум.

Ответы [ 5 ]

6 голосов
/ 11 февраля 2011

Как уже говорили другие, это обычно смесь. На более практическом уровне обычно помогает следующий подход:

  • Начните с оборота сверху вниз. А именно, разбить систему / дизайн на логические компоненты для решения задач. Но не создавайте точные окончательные интерфейсы для этих компонентов. Продолжайте рекурсивно, пока некоторые компоненты, к которым вы прибудете, не будут иметь размер «возможный для реализации» (например, размер одной функции / метода / класса)

  • Затем просмотрите итоговый список компонентов Bottom-Up и начните разработку первого проекта интерфейсов / контрактов.

  • Затем просмотрите список результирующих компонентов Bottom-Up и начните их реализовывать. Это позволит вам:

    • Наличие рабочего и тестируемого кода немедленно (не нужно ждать, пока будут реализованы базовые компоненты для тестирования)

    • Вы можете синтезировать окончательную версию интерфейсов / контрактов для компонентов более высокого уровня на основе потребностей уже завершенных компонентов более низкого уровня.

2 голосов
/ 11 февраля 2011

За исключением большинства тривиальных конструкций ничто так не упрощено . Я считаю, что большинство проектов требуют сочетания обеих методологий для уточнения.

1 голос
/ 11 февраля 2011

На мой взгляд, нисходящий дизайн более естественный, чем восходящий. Например: когда вы проектируете систему, вы в первую очередь определяете ее функциональные возможности (проектируете интерфейсы и контракты), затем вы указываете сущности системы, реализуете отношения между ними и т. Д. Конечно, проектирование сверху вниз сложнее, чем снизу вверх и требует опытных разработчиков.

0 голосов
/ 11 февраля 2011

В реальном мире практически невозможно использовать эти упрощенные методологии для проектирования систем. Обычно вы должны использовать их в нескольких итерациях.

Но это тоже упрощенный ответ.

0 голосов
/ 11 февраля 2011

Лично я предпочитаю «снизу вверх» - во-первых, потому что вы всегда что-то забываете при выполнении сверху вниз, а затем приходится это исправлять, а во-вторых, потому что, по крайней мере, в моем случае я получаю много хороших идей для всей системы при разработке отдельных компонентов снизу.

Привет, Лоренц

...