Mivel két programozó sült kenyér
Én programozóként dolgozik évek óta, amelynek során, furcsa módon, mindig valami, amit a program. És milyen érdekes dolog, amit észrevettem, hogy a kód írtam egy hónappal ezelőtt, mindig szeretne egy kicsit fix. A fél évvel ezelőtt meg akarom változtatni a kódot annyira, és a kód van írva két vagy három évvel ezelőtt, ez tesz engem emo: Azt akarom, hogy sírni és meghal. Ebben a cikkben fogom leírni két megközelítés. Hála az első architektúra program összezavarodik és karbantartása - indokolatlanul drága, és a második - a KISS elv.
Tehát, képzeljük el, hogy van két programozók. Egyikük intelligens, olvasott egy csomó cikket a Habré tudja GOF katalógus fejből, és Fowler - az arca. Tovább tesz mindent könnyű. Az első fogják hívni, például Boris N. és a második - Markus P. Természetesen kitalált neveket, és minden mérkőzést a valódi emberek és programozók véletlen.
Tehát mindketten projektmenedzser jön (ha a világegyetem PM nem megy maga a programozók nevezni, mint valami más, mint a BA vagy a vezető valójában nem változik.), És azt mondja:
- Srácok, meg kell, hogy kenyeret.
Ez így van, „én” megjelölése nélkül termelési mód.
Mit tehetünk mi programozók?
Boris létrehozza első absztrakció - Termék osztály, akitől örökölte kenyér osztály és példányosítjuk esetekben az osztály gyári módszer osztály ProductFactory - createProduct ().
Marcus teszi közel azonos. Ez megteremti kenyér menedzser osztály és az osztály a gyári módszer createBread ().
Bár a különbség minimális. Projektmenedzser, egy kicsit mélyebbre érteni (ez csak úgy tűnik, igen, igen), hogy az ügyfél igényeit, jön a második alkalommal, és azt mondta:
- Meg kell, hogy a kenyér nem könnyű csinálni, és kemencében sült.
És ha ez nem lehet megmondani, hogy a kenyér sütés vákuumban, és a sütőben? Nos, mit a programozók?
Boris átnevezi ProductFactory osztály Sütő, és kiemeli absztrakció - AbstractOven. Annak érdekében, hogy teljesen szépen, ez createProduct () metódus átnevezi bakeProduct (). Így először Boris refactored alkalmazásával „megjelenése absztrakció”, valamint végre egy sablon „absztrakt Factory” egy hajszál, ahogy le van írva a szakirodalomban. Jó neked, Boris.
De Marcus nem csinál semmit. Az ő szempontjából, és minden olyan jól. Nos, lehet, hogy érdemes egy kis változás végrehajtása createBread ().
holdfázis változások, valamint az igazgató a harmadik alkalommal jön programozók. Azt mondja:
- Meg kell, hogy a különböző típusú kályhák.
Nos, ez igaz.
Boris vidáman dörzsölte a kezét, létrejön a három örökös AbstractOven - ElectricOven, mikrohullámú sütő és GasOven. Egy osztály Sütő eltávolítja szükségtelen.
Marcus is módosítja a programot. Hozzáteszi, hogy az eljárás createBread egész paraméter ovenType.
A negyedik alkalommal kerül programozók vezetője. Már csak olvasni egyik könyvsorozat „Megértem a világot.” Interferenciát az új információs és PMBOK adta váratlan eredmény. A menedzser szerint:
- Meg kell, hogy gáztűzhely nem sült gáz nélkül.
Boris teljesen alaptalan úgy véli, hogy a gáz forrása lehet egyetlen. Ilyen esetekben mindig a kedvenc sablon. Ez létrehoz GasSourceSingleton egyedül, és csökkentik a kapcsolat valósítja meg a GasSource interface GasOven. Hurrá, kérte a függőség injekció révén szetter!
Modest természet Marcus teremt valódi saját területén az osztályban gasLevel menedzsere. Természetesen kevés változtatni a logikája a módszer createBread, de mit lehet tenni!
De két nappal később, a menedzser jött az ötödik alkalommal, és jóllakott nyalás, azt mondja:
- Meg kell, hogy a kályha is sütni piték és több (külön - hússal, külön - káposztával), és sütemények.
A programozók is akar enni, így veszi fel a munkát.
Boris már kezd valamit érezni, de nem maradhat tovább. A kemence tudja, mit kell főzni? Nyilván ugyanaz - szüksége volt egy szakács. Boris nem hosszú ideig (esetleg hosszú) gondolkodás teremt Cook osztályban. Ez egy olyan módszer előállítására, hogy az input elméleti sütő - szakács (Owen: AbstractOwen): Termék. Végtére is, logikus - a séf veszi a sütőt, és segíthet felkészülni. Ezután Boris teremt több örökös Class Termék - Cake és pépes és örököl pépes MeatPasty és CabbagePasty. Ezután minden egyes terméktípus létre külön szakács - BreadCook, PastyCook és CakeCook.
Úgy tűnik, több normális, de az idő telt, hogy sokkal több, mint Marcus, aki csak még egy egész paramétert eljárás createBread - breadType.
A hatodik alkalommal a menedzser jön. By the way, mi van most kér - ez nem 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, megakadályozza, hogy a készülék használatát tesztelés, 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ő.