[Javalist] Csatolások szoftverekben

[istvan.ketler at lhsystems.com]

Szerintem meg az OO mint olyan pont arról szól, hogy csökkentsük a lehetséges csatolások számát. Ezt nem "intuitíve érezzük" mi szoftverfejlesztők, hanem a tapasztalat során megtanultuk.

Van egy fickó, talán hallottad a nevét. B.W.Kernighan a neve. Részt vett valami olyaminek a létrehozásában, ami immár majdnem 40 éve alapjaiban változatlan. Megírta a "Software tools" sorozatát, amiből a 76-ban társszerzőként megírt, 82-ben "a programozás magasiskolája" címmel lefordított könyvében a következő gondolatok találhatók.

1. Top-down tervezés és struktúrált tervezés/programozás - általánosabb fogalmakkal kezdünk, majd lépésenként finomítunk, egyszerre mindig csak egy problémára koncentrálva. Ez könnyebben belőhető és módosítható programhoz vezet, és ezek a programok kevésbé károsodnak a módosítástól.
2. hatékonyság és megbízhatóság - tesztek eredményeinek elemzése alapján.
3. hordozhatóság igénye (76-ban!!!) - a rendszerfüggő részeket kis, pontosan körülhatárolt csomagban fogjuk össze
4. struktúrált tervezés szerinte: egy program vagy rendszer általános tervezésének irányítása oly módon, hogy az egyes részek jól illeszkedjenek egymáshoz, de ugyanakkor megfelelő mértékben függetlenek is maradjanak, hogy külön-külön módosíthatók legyenek.
5. az összetett programokat lehetőség szerint egyszerűbbekből építsük fel.
6. tesztelni az általános viselkedésen kívül a határeseteket mindenképpen kell; kritikus esetekre kihegyezett teszteket kell írni
7. tesztelés során előre tudni kell hogy adott bemenetre a program milyen viselkedést kell produkáljon
8. programrészeknek egyetlen kicsi feladata legyen, programrészek együttműködése adja a bonyolult viselkedést
9. program tervezésekor egyik legfontosabb szempont hogy a program könnyen módosítható legyen később - legjobb módja ha a programrészek annyira lazán kapcsolódnak, amennyire csak lehetséges
10. programot írjunk egyszerű, könnyen érthető módon, ezután mérjünk teljesítményt és ekkor optimalizáljunk (rontsuk az olvashatóságot) ha szükséges
11. minden kis programdarabot külön teszteljünk, rögtön megírásakor, nem a végén egy menetben

Ezek közül több is összefügg a csatolással, de mindegyik máig is érvényes (és persze nem ő fedezte ezeket fel, hiszen akkor már alkalmazták is egy részén a Bell Labsnál, ahonnan kipottyant a C nyelv és a Unix).

Szóval a szoros/laza csatolás és a program módosíthatósága közötti összefüggést úgy látom, már legalább 40 évvel ezelőtt is elég jól ismerték...

Legfontosabb gondolata pedig szerintem ez volt ebben a könyvben:

"Tévedés azonban azt hinni, hogy bármelyik technika merev alkalmazása önmagától jó programokat eredményez."

István Ketler
Senior Consultant
Lufthansa Systems Hungaria Kft. 
Development Center Pest 
Neumann János u. 1/e
1117 Budapest
Hungary 
Tel: +36 1 887-2815 
Fax: +36 1 887-2977
Mobile: +36 30 600-4936 
Room: Infopark E, Room LH2-24 
e-mail: istvan.ketler at lhsystems.com 
Internet: www.LHsystems.hu


 
Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Monika Houck

-----Original Message-----

From: javalist-bounces at lists.javaforum.hu [mailto:javalist-bounces at lists.javaforum.hu] On Behalf Of Molnár Miklós
Sent: Friday, May 18, 2012 2:19 PM
To: 'Java lista'
Subject: Re: [Javalist] Csatolások szoftverekben

Hali,

Igen intuitive mindannyian érezzük a csatolások fontosságát (nem megy szembe a tapasztalattal, sőt), de azért egészen más feeling matematikai formalizmusos bizonyítást mögötte látni. 
Ráadásul az absztrahált modell nekem roppant rokonszenves volt, kellően általános és specifikus.
Én csak a konklúziót írtam most, az előadásban a matekrész csak érintve volt, de már a bevezetés szintjén is roppant durva volt az egész. Ha tanultál "formális nyelveket és autotamákat", viszonyításként számomra még annál is nehezebb volt (pedig abból is alig mentem át annó). PhD-hegyek születnek a témában világszerte, annyi sok a nyitott kérdés, nehézség.

Csatolások a cikluson belül is vannak (ahol nincs interface), nemhogy modul-szinten. Tehát sokkal finomabb az egész felbontása. 

Nem értek egyet a Symbianos levezetéseddel.
- A történelem nem ismeri a "ha"-t. Közismert vicc: ha a nagyanyámnak kerekei lennének ő lenne a bécsi autóbusz.
- Nem tudod alátámasztani a feltételezéseidet az említett soraidban. Az említett előadó meg mégis csak publikált egy olyan eredményt, ami hatást generált
- A Symbian "architektúra reverse engine" projekt effektív megtörtént, a Nokiával közösen.
- Magam részéről régóta óriási és elsőrendű fontosságot tulajdonítok a csatolásoknak, a komplexitás kontextusában (csak én elsődrendűen adattárházas környezetben). Ugyanílyetén módon nem hiszek azokban a szoftverfejlesztési trendekben, hogy csak módosítani kell "igény szerint"
igen is kell valamennyire utánamenni egyebekkel is a változásmanagement folyamat keretében (még ha ez overheadet is jelent). Analóg módon, ahogy egy
B+ fába se elég elemet beszúrni, utána a fát ki kell egyensúlyozni.

MM

_______________________________________________
Javalist mailing list
Javalist at lists.javaforum.hu
http://lists.javaforum.hu/mailman/listinfo/javalist