Keresés

Új hozzászólás Aktív témák

  • proci985

    MODERÁTOR

    válasz Dave-11 #1579 üzenetére

    kicsit kompaktabban és konyhanyelven:

    a program leképezi a valós dolgot, innentől könnyebben elképzelhető, könnyebben használható. az emberi agy szeret kötni dolgokat valahova, tehát végereményben logikusabb lesz a felépítés.

    ez azt is jelenti, hogy általában a dologok közötti egymásrahatások is átláthatóbbak, jól csinálva egyszerűbben átlátható lesz az architektúra (tehát a classok kapcsolata, egymásraépülése és végeredményben a program felépítése), tisztábbak lesznek az interfacek. a funkciók és változók szintén köthetőek lesznek a valós dologhoz, tehát könnyebben átlátható lesz, hogy mi miért kellhet, kevesebbet kell kommenteket/dokumentációt olvasni, emiatt könnyebben módosíthatóvá és megérthetővé válik a program. az ember kvázi építőkockákat kap, amik segítségével a nagy egész könnyebben feldarabolhatóvá (főleg design patternsek alkalmazásával), így könnyebben megérthetővé válik.

    másik fontos szempont, hogy a dolgok elkülönülnek egymástól, tehát egy dolog nem több egységben (component/class) lesz megvalósítva, ez megint átláthatóbb kódot jelent. ami egyben azt is jelenti, hogy egyszerűbben átláthatóvá válik a programlogika. ez ismét a módosíthatóság/karbantarthatóság/megérthetőség hármast erősíti, illetve a tesztelhetőséghez is kell. htlmt generáló php+jquery+css+sqlnél pl elég vicces tud lenni, amikor az ember elkezdi keresni, hogy a 20+ fileból ugyanmár mi is felelős egy adott gomb működéséért, ha nincsen szépen megtervezve a rendszer (és persze a html útközben változik).

    tesztelhetőséghez amiatt fontos, mert egyszerűbb egységek szintjén kezdeni, és általában minél kevesebb egység kell egy adott feladat kipróbálásához (elsősorban itt dependencykre kell gondolni), annál könnyebben lesz tesztelhető egy adott megoldás. a jól definiált interface szintén nagyban segíti a blackbox testinget. azt nem szabad elfelejteni, hogy az OO design egyben ronthat is a tesztelhetőségen, bizonyos design patternek (pl singleton vagy insulation classek) ilyen szempontból problémásak.

    ami még lényeges, hogy az OO design nem igazán enged meg globális változókat, amik megintcsak nagyban rontják a későbbi karbantarthatóságot.

    namost, ami az egésznek a lényege: a programok életciklusa hosszú lehet, ezalatt cserélődhet a teljes fejlesztői gárda, cserélődhetnek a célok, amiket az ember elvár a terméktől. az OO design ezekre a kérdésekre ad (részleges) választ és segít abban, hogy az a kód, amit az ember megír, később is használható legyen, amikor módosítani kell.

Új hozzászólás Aktív témák