Аз работя като програмист в продължение на много години, по време на които, странно, аз винаги нещо, което аз програма. И какво интересно нещо, което забелязах в кода, който написах преди месец, че винаги искат нещо малко корекция. В половин година преди Искам да променя кода толкова много, а кодът е написана преди две или три години, той ме прави емо: Искам да плача и да умре. В тази статия, ще опиша два подхода. Благодарение на първата програма за архитектура се обърква и поддръжка - е неоправдано скъпо, а вторият - на принципа на KISS.
Така че, представете си, че има две програмисти. Един от тях е интелигентен, прочетете един куп членове на Хабре той знае GOF каталог от сърце и Фаулър - в лицето. Друг прави всичко лесно. Първият ще се казва, например, Борис Н., а вторият - Маркус П. Разбира се, фиктивни имена и всички мачове с реални хора и програмисти случайни.
Така че, те и двете ръководител на проекта идва (ако си вселена PM не се отиде към програмистите го наричат като нещо друго, като например BA или олово в действителност тя не се променя.) И казва:
- Момчета, ние трябва да се направи хляб.
Точно така, "Да", без да уточнява начина на производство.
Какво можем да направим нашите програмисти?
Борис създава първата си абстракция - клас на продукта, от когото наследява Хляб клас и конкретни примери случаи на фабрика клас метод клас ProductFactory на - createProduct ().
Маркъс прави почти същото. Той създава Хляб клас мениджър и клас с фабрично метод createBread а ().
Докато разликата е минимална. Ръководител на проекта, малко по-дълбоко разбран (тя просто изглежда така, да) към нуждите на клиента, идва за втори път и каза:
- Ние се нуждаем, че хляб не е лесно да се направи, и се пече във фурната.
И след като е било невъзможно да се каже, че хлябът е печене във вакуум, и във фурната? Е, това, което правят програмистите?
Борис преименува ProductFactory клас Фурна, и подчертава абстракция - AbstractOven. За да го направи абсолютно красиво, то createProduct () метод преименува bakeProduct (). По този начин, за първи път Борис refactored чрез прилагане на "освобождаване на абстракция", както и изпълняват шаблон "Abstract Factory" на косъм, тъй като е описано в литературата. Добре е за теб, Борис.
Но Марк не направи нищо. От негова гледна точка и всичко толкова добре. Е, може би си заслужава малко промяна createBread на изпълнение ().
Луната фаза промени, както и мениджърът за трети път идва на програмистите. Той казва:
- Ние трябва да имаме различни видове печки.
Е, това е вярно.
Борис радостно триене ръцете си, създава три наследник AbstractOven - ElectricOven, микровълнова фурна и GasOven. А клас Фурна го премахва като ненужно.
Марк също прави промени в програмата. Той добавя метод createBread параметър число ovenType на.
Четвъртият дойде време за управление на програмистите. Той току-що е прочел една от поредицата от книги "Аз разбирам света." Смущения на нова информация и PMBOK даде неочакван резултат. Мениджър казва:
- Трябва да отидем газова печка не може да се пече без газ.
Борис е абсолютно безпочвени смята, че източникът на газ може да бъде само един. За такива случаи, винаги има любимата ни шаблон. Той създава GasSourceSingleton сам, и да се намали свързаност го реализира чрез GasSource интерфейс GasOven. Ура, той кандидатства инжектирането на зависимост чрез инкубатора!
Скромен по природа Маркус създава реална частна сфера в мениджъра на клас gasLevel. Разбира се, няма какво да се промени логиката на createBread на метод, но какво да се прави!
Но два дни по-късно, на управителя дойде за пети път, а сит облизване, той казва:
- Ние трябва да стигнем до печката може да се пече още пайове и (отделно - с месо, отделно - със зеле) и сладкиши.
Програмистите също искат да ядат, така че да отнеме работата.
Борис вече започва да се почувстваме по, но не могат да останат по-дълго. Както фурната знае какво трябва да се готви? Очевидно е едно и също - тя имаше нужда готвач. И Борис не е дълъг период от време (може би дълго) мислене създава Кук клас. Това е метод за приготвяне на получаване на входа на абстрактен фурна - готвя (Оуен: AbstractOwen): Продукт. В края на краищата, това е логично - главният готвач е на фурната и може да помогне в подготовката. Тогава Борис създава няколко наследници клас на продукта - торта и пастообразни и наследява от Паста MeatPasty и CabbagePasty. След това, за всеки тип продукт се създава отделен готвач - BreadCook, PastyCook и CakeCook.
Изглежда по-нормално, но времето, необходимо много повече от това на Марк, който току-що си с още един параметър, за да число метод createBread - breadType.
За шести пореден път мениджърът идва. Между другото, това, което е сега той иска - това не е изискване на клиента, че е негова собствена инициатива. Но никой няма да знае за това, нали?
- Имаме нужда от хляб, сладкиши и торти печени по различни рецепти.
"Хм," - казва Борис и помни шаблон "строител" (заедно разбира се с "свободен интерфейс."). Той създава Рецепта клас, както и за него - строител RecipeBuilder. Рецепта той въвежда (изведнъж!) В огъня с помощта на сетер setRecipe (рецепта: Рецепта).
И Маркъс (Няма да повярваш) добавя единствен параметър число createBread - рецепта.
Най-интересното, както винаги, се извършва далеч от компютъра. А именно, мениджърът за първи път след началото на развитието среща с клиента и най-накрая да разбере защо това е необходимо печка. Той (управителя) за седми път на въпрос за програмисти, и казва:
- Трябва да отидем във фурната може да се пекат тухли.
За Борис беше последната среща с управителя, но все пак той миналата сила прави промени в архитектурата. Той идентифицира AbstractHeatingSmth абстрактен клас - отоплителна нещо абстрактно. За него, тя създава HeatingFactory фабрика. От AbstractHeatingSmth той наследява ProductOven и Furance. Последният има фабрика метод makeBrick, Тухла създава инстанция на даден обект. Но нищо не работи. Читателят се насърчава да намери своя грешка в архитектурата.
Марк също не е толкова гладка. Той трябва да се създаде една трета (!) От класа на сметка. Той го нарича тухла, и допринася за неговото метод Мениджър makeBrick.
Разбира се, може да се твърди, че Маркъс вътре createBread метод случва Ad и Израел. и това наистина е така. Но с помощта на шаблон "метод шаблон" на е доста бъркотия може да бъде структурирана. И в изобилието на растения и абстракции, за да се разбере, добре, малко по-сложно.
Изводите, които искам да направя, може би, малко по-предсказуем.
Борис подход е добре, че почти всяка част от системата може да се изолира и да се обхванат тестове. Но време за създаването на такъв голям брой класове ще остави много неприлично, и всеки изисквания на климата ще се превърнат каскада промяна код. Опитът да се направи архитектурата гъвкав, за предвиждане на изискванията на клиентите, обикновено се проваля - архитектура навежда изцяло на грешното място. Както е известно, "светът не е само изненадващо, отколкото можем да си представите -
Той е невероятен, отколкото можем да си представим. " И като друго искане на климата, програмист прави сигурен, че това прилича на никоя друга.
Маркъс подход, над, предотвратява използването на единица тестване, но тя дава резултати, много по-бързо, а промените са по-малко кръв. Този подход - най-бързият старт, който е толкова нетърпелив да стартиращи компании от всякакъв вид. И, странно, това, че кодът е наистина лесно да се разбере, защото е по-лесно.
А пренаписва всичко отначало, ако това - тя винаги е много време.
Свързани статии