"Szervusz, Amigo! Az OOP egy másik előnyéről szeretnék mesélni. Látod, a programok inkább állatok, mint épületek. Nem épülnek, hanem kinőttek. A fejlesztés folyamatos változásokat jelent. Az építőiparban legyen egy jó terved, és kövesd azt a T-nek megfelelően. De a szoftverfejlesztésben ez nem így van."
Gyakran előfordul, hogy valamit nem tud úgy csinálni, ahogyan azt szerette volna, és sokat kell átdolgoznia a programját. És még gyakrabban változnak az ügyfelek igényei.
– De mi van akkor, ha az ügyfél valóban részletes specifikációt ad?
"Nézze meg, mi történik az idő múlásával. Ha egy termék sikeres lesz, az ügyfél egy új verziót szeretne kiadni, majd egy másikat, és még egyet. És természetesen néhány " apró változtatást " kell végrehajtania . A szoftverfejlesztés tehát a változások hosszú sorozata. Csak a ritmus különbözik. Egy új verzió minden héten, havonta egyszer vagy félévente megjelenhet."
– Szóval mire következtetünk mindebből?
"A termék belső szerkezetét úgy kell karbantartani, hogy lehetővé tegye a nagyobb (és kisebb) változtatások elvégzését minimális átdolgozással."
"Hogyan csinálod, hogy?"
"Már beszéltünk arról, hogy egy program olyan objektumokból áll, amelyek kölcsönhatásba lépnek egymással. Használjunk vastag pontokat a programunk összes objektumának ábrázolására a táblán. Nyilakat rajzolunk minden objektumról (pontról) az összes objektumra. (pontok), amelyekkel kölcsönhatásba lép."
Most kombináljuk az objektumokat (pontokat) csoportokba. A pontok ugyanabba a csoportba tartoznak, ha sokkal jobban kapcsolódnak egymáshoz, mint a többi pont. Ha egy pont nyilak többsége a csoport pontjaira mutat, akkor az objektumokat megfelelően csoportosítottuk. Az ugyanazon a csoporton belüli pontokról azt mondják, hogy szorosan kapcsolódnak egymáshoz, míg a különböző csoportok pontjai lazán kapcsolódnak egymáshoz.
Ezt hívják " laza csatolás elvének ". A program több részre, gyakran rétegekre van felosztva, amelyek logikája erősen kötődik a belső szerkezetükhöz, és gyengén kötődik más rétegekhez/részekhez. A rétegek közötti kölcsönhatás általában erősen kompartmentalizált. Egy réteg meghívhat egy másik réteget az osztályainak csak egy kis részhalmazával.
– Ugyanaz a „munkamegosztás” elv, de nagyobb léptékben?
"Pontosan. Ez lehetővé teszi egy osztály átszervezését, hatékonyabbá tételét, és még több ember felvételét, és ha nem változtatjuk meg a tárcaközi protokollokat, akkor minden változtatásunk helyi lesz. Senkit nem kell átképezni. Mi nem Nem kell átdolgozni a teljes rendszert. Minden osztály optimalizálhatja belső ügyeit ilyen módon, ha jól megválasztják a tanszéki interakció mechanizmusait."
"Ha jól választják ki őket. És mi van, ha nem jól választják ki?"
"Akkor gyorsan elfogy a " mozgástér " a változtatásokhoz, és át kell dolgoznia az egész rendszert. Ez időről időre megtörténik. A jövőt nem tudjuk megjósolni, de minimalizálhatjuk, hogy hányszor kell újraírnunk a programot."
"Rendben. Látom az előnyét a program ilyen felosztásának, de hogyan jön a képbe az OOP?"
"Amikor kiválasztjuk, hogyan építsük fel a részlegeket és hogyan működjenek együtt egymással, az" absztrakció elvét " alkalmazzuk. A programozás során az absztrakciót arra használjuk, hogy meghatározzák a program felosztásának legjobb módját és a részek kölcsönhatását. Ez az elv ismételten alkalmazzuk az alkotórészekre is mindaddig, amíg a programot egyedi osztályokra nem bontjuk."
"És elrejteni ezeknek az alkatrészeknek a belső szerkezetét, és szigorúan korlátozni, hogyan kölcsönhatásba lépnek más részekkel – ez a beágyazás , igaz?"
"Pontosan. A beágyazás és az absztrakció az OOP sarokkövei. Egy jó programnak ehhez a két alapelvhez kell ragaszkodnia. Később megnézünk más alapelveket, és megértjük azok előnyeit."
"Jó cucc. Alig várom!"
GO TO FULL VERSION