Mivel két programozó sült kenyér
Mivel két programozó sült kenyér
Én programozóként dolgozik évek óta, amelynek során, furcsa módon, én egész arca. . Managert (ha az univerzum Termék osztály, akitől örökli az osztály különbség minimális projektmenedzser, egy kicsit mélyebb megértése (ez csak úgy tűnik, igen), hogy az ügyfél igényeinek, jön a második alkalommal, és azt mondta, - a elosztását absztrakció „, valamint valósul végrehajtása attól szetter!
A követelmény az ügyfél, ez volt a saját kezdeményezésére. De senki nem fog tudni róla, igaz? - Szükségünk van a kenyér, torták és sütemények sült különböző recepteket.
„Hmm,” - mondja Boris és emlékszik sablon „építő” (együtt természetesen a „szabad felület.”). Ez létrehoz egy recept osztály, és neki - builder RecipeBuilder. Recept ő vezeti be (hirtelen!) A tűzbe segítségével egy szetter setRecipe (recept: recept).
És Marcus (nem hinnéd) egészíti ki egy egész paramétert createBread - recept.
A legérdekesebb, mint mindig, zajlik távol a számítógépet. Nevezetesen, az igazgató először a rajt után a fejlődés találkozik az ügyféllel, és végre megérteni, hogy miért volt szükség kályha. Ő (a menedzser) hetedik alkalommal kerül programozók, és azt mondja: - Meg kell, hogy a kemencében sütni lehet tégla.
Boris volt az utolsó találkozó a vezetője, de még mindig az utolsó erőt, amely változtatásokat tesz az architektúra. Ő azonosítja AbstractHeatingSmth absztrakt osztály - a fűtés valami elvont. Számára ez teremt HeatingFactory gyárban. Tól AbstractHeatingSmth ő örökli ProductOven és furance. Az utóbbi egy gyár módszer makeBrick, Tégla létrehoz egy példányát egy tárgy. De semmi sem működik. Az olvasó arra ösztönzik, hogy megtalálja a saját hibát az építészetben.
Marcus is, nem olyan sima. Ő és egy harmadik (!) A számla osztályban. Azt kéri, hogy a tégla, és hozzáteszi, hogy a menedzser módszer makeBrick.
Persze, azt mondhatjuk, hogy Marcus belül createBread módszerrel történik Ad és Izrael. és valóban ez a helyzet. De olyan sablon használatával „sablon” módszer elég rendetlenség lehet felépíteni. És a rengeteg növény és absztrakciók megérteni, nos, egy kicsit bonyolultabb.
A következtetések, hogy szeretnék csinálni, talán egy kicsit kiszámítható.
Boris megközelítés jó, hogy szinte minden része a rendszernek lehet izolálni és fedél vizsgálatok. De az idő, hogy egy ilyen nagy számú osztály elhagyja sok illetlen, és minden változást követelmények fog fordulni kaszkád kód változás. A kísérlet, hogy az architektúra rugalmas, előre jelezze a vásárlók igényeinek, általában sikertelen - építészet hajlik teljesen rossz helyen. Amint az ismert, „a világ nem csak meglepő, mint gondolnánk - ő egy hihetetlen, mint amit el tudunk képzelni.” És van egy másik változtatási kérelem a programozó biztosítja, hogy ez, mint senki más.
Marcus megközelítés felett, használatát megakadályozza az egység tesztelése. de ez ad eredményeket sokkal gyorsabb, és a változások kevesebb vér. Ez a megközelítés - a leggyorsabb start, amely oly szívesen induló mindenféle. És furcsa módon, hogy a kód valóban könnyebb megérteni, mert könnyebb.
Az újraírt újra, ha ez - ez mindig rengeteg idő.
Kép vette com .tr / galeridetay.aspx? P = 2cid = 35509rid = 4369 „> itt