Като две програмисти изпечен хляб
Аз работя като програмист в продължение на много години, по време на които, странно, бях цялото му лице. . Manager (ако във вашата вселена клас на продукта, от когото наследява разликата в клас е минимална ръководител на проекта, малко по-дълбоко разбиране (е то само изглежда, да) към нуждите на клиента, идва за втори път и каза: - разпределението на абстракция ", както и се осъществява чрез прилагане в зависимост трасьорът!
изискването на клиента, че е негова собствена инициатива. Но никой няма да знае за това, нали? - Имаме нужда от хляб, сладкиши и торти печени по различни рецепти.
"Хм," - казва Борис и помни шаблон "строител" (заедно разбира се с "свободен интерфейс."). Той създава Рецепта клас, както и за него - строител RecipeBuilder. Рецепта той въвежда (изведнъж!) В огъня с помощта на сетер setRecipe (рецепта: Рецепта).
И Маркъс (Няма да повярваш) добавя единствен параметър число createBread - рецепта.
Най-интересното, както винаги, се извършва далеч от компютъра. А именно, мениджърът за първи път след началото на развитието среща с клиента и най-накрая да разбере защо това е необходимо печка. Той (управителя) за седми път на въпрос за програмисти, и казва: - Трябва да отидем във фурната може да се пекат тухли.
За Борис беше последната среща с управителя, но все пак той миналата сила прави промени в архитектурата. Той идентифицира AbstractHeatingSmth абстрактен клас - отоплителна нещо абстрактно. За него, тя създава HeatingFactory фабрика. От AbstractHeatingSmth той наследява ProductOven и Furance. Последният има фабрика метод makeBrick, Тухла създава инстанция на даден обект. Но нищо не работи. Читателят се насърчава да намери своя грешка в архитектурата.
Марк също не е толкова гладка. Той трябва да се създаде една трета (!) От класа на сметка. Той го нарича тухла, и допринася за неговото метод Мениджър makeBrick.
Разбира се, може да се твърди, че Маркъс вътре createBread метод случва Ad и Израел. и това наистина е така. Но с помощта на шаблон "метод шаблон" на е доста бъркотия може да бъде структурирана. И в изобилието на растения и абстракции, за да се разбере, добре, малко по-сложно.
Изводите, които искам да направя, може би, малко по-предсказуем.
Борис подход е добре, че почти всяка част от системата може да се изолира и да се обхванат тестове. Но време за създаването на такъв голям брой класове ще остави много неприлично, и всеки изисквания на климата ще се превърнат каскада промяна код. Опитът да се направи архитектурата гъвкав, за предвиждане на изискванията на клиентите, обикновено се проваля - архитектура навежда изцяло на грешното място. Както е известно, "светът не е само изненадващо, отколкото можем да си представите - той е невероятен, отколкото можем да си представим." И като друго искане на климата, програмист прави сигурен, че това прилича на никоя друга.
Marcus подход, върху, предотвратява използването на единица тестване. но тя дава резултати много по-бързо, а промените са по-малко кръв. Този подход - най-бързият старт, който е толкова нетърпелив да стартиращи компании от всякакъв вид. И, странно, това, че кодът е наистина лесно да се разбере, защото е по-лесно.
А пренаписва всичко отначало, ако това - тя винаги е много време.
Снимка взе ком .tr / galeridetay.aspx? P = 2cid = 35509rid = 4369 "> тук
Свързани статии