1. Cégtörténet

Szeretnék elmesélni egy történetet, amely bemutatja, hogyan segít az OOP a nagy rendszerek bonyolultsága elleni küzdelemben. Ez szükséges ahhoz, hogy megértse az OOP célját .

Volt egyszer egy kis cég, amely intergalaktikus hajózási szolgáltatásokat nyújtott...

Nevezzük Galaxy Rush-nak. 5 főt foglalkoztatott. Egyik a pénzügyben, a másik raktárban dolgozott, a harmadik a kiszállításokat végezte, a negyedik a reklámozást, az ötödik pedig az egész vállalkozást irányította.

Nagyon keményen dolgoztak, és mindenben sikerült. A cégnek jó hírneve volt, és sok pénzt keresett. De évről évre egyre több megrendelés érkezett, így a főnöknek további alkalmazottakat kellett felvennie. Még több a raktárnak, több a kiszállításnak, még egy a pénzügynek, és egy további reklámszakértő a cég piaci részesedésének bővítésére.

És ekkor kezdődtek a problémák. Többen voltak , és kezdték egymás útjában állni.

A marketinges költései kimerítik a bankszámlát egy új reklámkampányra, így nincs pénz a sürgősen kiszállítandó termékek vásárlására.

A raktárban 10 vadonatúj hipermeghajtó található, amelyeket havonta egyszer szállítanak ki az ügyfélnek. Az egyik futár berepült, és elvitt egy hipermeghajtót egy másik ügyféltől, ami miatt a 10 hipermeghajtóra vonatkozó szokásos rendelés egy hónapot késett. Az első futár egyszerűen nem tudott arról, hogy a másik rendelést az a második futár töltötte be.

Az új menedzser asszisztens futárt küld egy űrhajóra, hogy további árukat vásároljon. Eközben mindenki más arra vár, hogy megjelenjen egy szabad űrhajó. Rengeteg sürgős szállítás van, de ez az asszisztens csak a beszerzést felügyeli, és igyekszik jól végezni a munkáját. Minél jobban teljesíti a munkavállaló feladatait, annál jobban beleavatkozik mások munkájába.

Java webinar

A helyzetet elemezve a főnök rájön, hogy az olyan fontos erőforrásokat, mint az űrhajó, a készpénz és a termékek nem használják fel optimálisan. Ehelyett a „szundi, veszít” szabály vonatkozik rájuk. Bármelyik alkalmazott olyan erőforrást vehet igénybe, amelyre mindenkinek szüksége van a munkájához, ezzel veszélyeztetve a többi alkalmazottat és a vállalat egészét.

Valamit tenni kellett, ezért a főnök úgy döntött, hogy a monolitikus céget néhány részlegre osztja. Létrehozott egy szállítási osztályt, egy marketing osztályt, egy beszerzési osztályt, egy pénzügyi osztályt és egy leltári osztályt. Már senki sem tudta egyszerűen elvenni az űrhajót. A szállítási osztály vezetője minden információt megkapott a szállításokról, és a legjövedelmezőbb megrendeléssel kiadta a hajót a futárnak. Ezenkívül a raktár nem engedte, hogy a futárok egyszerűen elvigyenek bármilyen árut, amit akartak. Ehelyett a termékek raktárból történő kiszedése ellenőrzött folyamattá vált. A pénzügyi osztály nem szabadítana fel pénzt marketingkampányra, ha tudná, hogy hamarosan vásárlásra kerül sor. Minden osztálynak egy nyilvános arca volt – az osztályvezető.Mindegyik részleg belső felépítése saját dolga volt. Ha egy futár termékeket akart beszerezni, akkor a raktárvezetőhöz ment, nem a raktárba. Ha új rendelés érkezett, azt a szállítási osztály vezetője ( public-facing representative) kapta, nem futár ( someone not authorized to interact with the other departments).

Más szóval, a főnök csoportokba (részlegekbe) vonta össze az erőforrásokat és az erőforrásokkal kapcsolatos tevékenységeket , és megtiltotta másoknak, hogy beavatkozzanak az osztályok belső struktúrájába. A hivatalok közötti interakcióknak egy adott személyen kellett keresztülmenniük.

Az OOP szempontjából ez nem más, mint a program objektumokra osztása. A módszerek és változók monolitikus programja objektumokból álló programmá válik. Az objektumoknak pedig vannak változói és metódusai.

A probléma az volt, hogy bármely alkalmazott bármilyen erőforrással dolgozhatott, és parancsokat adhatott bármely másik alkalmazottnak, mindezt felügyelet vagy ellenőrzés nélkül. Kis korlátozást vezettünk be, de nagyobb rendet értünk el. És mindent jobban tudtunk irányítani.

Ez az oszd meg és uralkodj a legtisztább formájában.

2. Hogyan készülnek a programok

Szeretnék még egy fontos pontot érinteni, amely felfedi az OOP egy másik előnyét . Látod, hogy a programok inkább állatok, mint épületek? Nem épülnek. Felnőttek. A fejlődés állandó változás. Az építőiparban lehet egy jó terved és azt pontosan követheted. Szoftverfejlesztésnél ez nem így van.

A programozás során nagyon gyakran nem tudsz valamit úgy csinálni, ahogy eredetileg tervezted, és sokat kell átdolgoznod. Az ügyfelek igényei még gyakrabban változnak.

De mi van akkor, ha az ügyfél nagyon pontos specifikációt ad meg? Ez még rosszabbá teszi a dolgokat. Nézze meg, mi történik a termékkel idővel.

A termék sikere arra készteti a vásárlót, hogy egy új verziót, majd még egyet és még egyet kiadjon. És természetesen nem kell mást tennie, mint "kis változtatásokat" tenni a meglévő terméken. Láthatja tehát, hogy a termékfejlesztés állandó változások sorozata. Csak az időskála különbözik. Az új verzió hetente egyszer, havonta egyszer vagy félévente egyszer megjelenhet.

És milyen következtetést vonhatunk le mindebből? A termék belső szerkezetét úgy kell fenntartani, hogy minimális átdolgozással jelentős (és kisebb) változtatásokat lehessen végrehajtani.

Tárgykohézió

De ezt megtenni nehezebb, mint eldönteni. Már említettük, hogy egy program olyan objektumokból áll, amelyek kölcsönhatásba lépnek egymással. Rajzoljuk fel a programunk összes objektumát a táblára, pontokkal ábrázolva. És rajzoljunk nyilakat minden objektumról (pontról) az összes többi objektumra (pontra), amellyel kölcsönhatásba lép.

Most az objektumokat (pontokat) csoportokba foglaljuk. A pontokat akkor kell csoportosítani, ha a köztük lévő kapcsolatok sokkal intenzívebbek, mint a többi ponttal rendelkezők. Ha egy pontból a legtöbb nyilak a saját csoportjában lévő többi ponthoz jutnak, akkor a csoportok helyesen lettek kialakítva. Azt mondjuk, hogy egy csoporton belüli pontok kohéziója magas , míg a különböző csoportok pontjai alacsonyabb kohéziót mutatnak.

Laza csatolás elve

Létezik egy "laza csatolás elve". Egy program több részre van felosztva, amelyek gyakran rétegek. Ezeknek a rétegeknek/részeknek a logikája szorosan kapcsolódik belső szerkezetükhöz, és nagyon lazán kapcsolódik más rétegekhez/részekhez. A rétegek közötti kölcsönhatások általában nagyon szabályozottak. Az egyik réteg hivatkozhat a második rétegre, és az osztályainak csak egy kis részhalmazát használja. Ez a "vállalat részlegekre való felosztásának" elve, amit korábban láttunk, de nagyobb léptékben.

Az eredmény az, hogy egy osztályt szükség szerint átszervezhetünk a hatékonyság növelése érdekében, és még több embert tudunk felvenni a részlegre, és amíg nem változtatjuk meg a többi részlegünkkel való interakciós protokollt, addig minden változtatás helyben maradnak. Senkinek nem kell újratanulnia semmit. Nem kell az egész rendszert átdolgozni. Minden osztály el tudja végezni ezt a fajta belső optimalizálást, ha a részlegek közötti interakció mechanizmusai jól meg vannak választva.

Jól választott. De mi van akkor, ha nem jól választottak? Ekkor a változtatási kapacitás gyorsan kimerül, és újra kell készítenie az egész rendszert. Ezt időnként meg kell tenni. A jövőt nem lehet megjósolni, de az újravágások számát minimálisra csökkentheti.

Az absztrakció elve

Az „ absztrakció elve ” az osztályok felépítésének és interakcióinak megválasztása . A programozás során arra használják, hogy meghatározzák a legjobb módot a program részekre bontására, valamint arra, hogy ezek a részek hogyan működjenek együtt. Alkalmazhatjuk újra az elvet, a kapott részeket részekre bontva mindaddig, amíg a programot külön osztályokra nem bontjuk.

Ezeknek az alkatrészeknek a belső szerkezetének elrejtése és a más részekkel való kölcsönhatás szigorú korlátozása a tokozás . A tokozás és az absztrakció az OOP sarokkövei . Egy jó programnak ezt a két elvet kell követnie. A jövőben megvizsgáljuk a többi alapelvet, és megvizsgáljuk, milyen előnyökkel jár.