Як два програміста хліб пекли
Я працюю програмістом вже багато років, протягом яких, як це не дивно, я все обличчя. менеджер (якщо у вашій всесвіту клас Product, від нього він успадковує клас різниця мінімальна. Проектний менеджер, трохи глибше розібравшись (це йому так тільки здається, так) в потребах замовника, приходить вдруге і каже: - виділення абстракції », а так ж реалізував впровадження залежності через сетер!
вимога замовника, це його власна ініціатива. Але ж про це ніхто не дізнається, чи не так? - Нам потрібно, щоб хліб, пиріжки і торти випікалися за різними рецептами.
«Хм», - вимовляє Борис і згадує про шаблон «будівельник» (разом з «вільним інтерфейсом». Звичайно ж). Він створює клас Recipe, а до нього - будівельник RecipeBuilder. Рецепт він впроваджує (РАПТОМ!) В грубку за допомогою сетера setRecipe (recipe: Recipe).
А Маркус (ви не повірите) додає ще один цілочисельний параметр в createBread - recipe.
Найцікавіше, як завжди, відбувається далеко від комп'ютерів. А саме: менеджер вперше після початку розробки зустрічається з замовником і нарешті розуміє, навіщо йому потрібна була піч. Він (менеджер) в сьомий раз приходить до програмістам і каже: - Нам потрібно, щоб в печі можна було обпалювати цеглу.
Для Бориса це остання зустріч з менеджером, але все ж він з останніх сил вносить зміни в архітектуру. Він виділяє абстрактний клас AbstractHeatingSmth - абстрактне нагріває щось. Для нього він створює фабрику HeatingFactory. Від AbstractHeatingSmth він успадковує ProductOven і Furance. В останнього є фабричний метод makeBrick, що створює екземпляр об'єкта Brick. Але нічого не працює. Читачеві пропонується самостійно знайти помилку в архітектурі.
У Маркуса теж не все так гладко. Йому доводиться створити вже третій (!) За рахунком клас. Він називає його Brick, і додає в свій Manager метод makeBrick.
Звичайно, можна заперечити, що у Маркуса всередині методу createBread твориться ад та Ізраїль. і це насправді так. Але за допомогою шаблону «шаблонний метод» безлад цілком можна структурувати. А в достатку фабрик і абстракцій розібратися, ну, трохи складніше.
Висновки, які я хочу зробити, напевно, трохи передбачувані.
Підхід Бориса хороший тим, що практично кожну частину системи можна ізолювати і покрити тестами. Але часу на створення такої кількості класів піде непристойно багато, і кожна зміна вимог обернеться каскадним зміною коду. Спроба ж зробити архітектуру гнучкою, передбачивши побажання замовника, зазвичай провалюється - архітектура гнеться зовсім не в тому місці. Адже, як відомо «світ не просто дивніше, ніж ми собі уявляємо, - він більш дивно, ніж ми можемо собі уявити». І, отримавши черговий change request, програміст переконується в цьому як ніхто інший.
Підхід Маркуса, скінчено, не дозволяє використовувати модульне тестування. але зате він дає результат набагато швидше, і зміни даються меншою кров'ю. Цей підхід - той самий швидкий старт, якого так хочуть стартаперів всіх мастей. І, як не дивно, в такому коді дійсно легше розібратися, тому що він простіше.
А переписати все заново, якщо що, - це завжди встигну.
Картинку взяв com .tr / galeridetay.aspx? P = 2cid = 35509rid = 4369 "> звідси