Тоp-Down – це низхідний підхід, який полягає у розробці рішення проблеми, починаючи з концептуального її рішення і вже потім заглиблюючись у деталі реалізації. Цей підхід дозволяє дуже вдало напрямляти залежності, роблячи код більш стабільним і таким, що вимагає мінімуму змін, які добре локалізовані. Також Top-Down дозволяє швидко розробити прототип без будь-якої конкретики, наприклад, щодо способу зберігання данних та навіть їх структури, проте вимагає великої кількості самописного коду, який має постійно покращуватися.
Bottom-Up – це висхідний підхід, який полягає у побудові чогось складного із наявних компонентів, мов із кубиків LEGO. Цей підхід дозволяє писати мінімум власного коду, використовуючи переважно готові рішення, які, щоправда, менш ефективні, за більш спеціалізовані (власні). Крім того, bottom-up розробка має значно нижчий вхідний поріг.
Навіщо?
Я думаю, що ті, хто мене читає, у своїй більшості також схиляються до низхідної розробки через те, що отриманий результат більш стабільний і вимагає лише добре локалізованих змін. Проте, у багатьох випадках створювати увесь стек самостійно – буде досить дорогою інвестицією, яка зовсім не скоро відіб’ється. У переважній більшості випадків ми будемо мати справу не з чистим Top-Down, а з певним балансом між Top-Down та Bottom-Up (принаймні, протоколи інтернету, драйвери, firmware, hardware СУБД, файлові та операційні системи, або хоча б гіпервізори та unikernel’и).
Як?
Найголовніше, ми не маємо відмовлятися від концепції ідеального інтерфейсу. Це головна вимога до того, як обидва підходи мають бути поєднані, бо в інакшому випадку ми їх не поєднуємо, а просто відмовляємося від Top-Down.
Аби одночасно мати ідеальний інтерфейс та використовувати готові, не спеціалізовані рішення від третьої сторони, ми маємо додати т.з. “Anti-Corruption Layer” – прошарок, між користувачем (caller) та рішенням від третьої сторони. Такий прошарок ще можна назвати застосуванням GoF патерну Adapter (wrapper, decorator, delegation, facade).
Залишити відповідь