Skip to content

Komponensorientáltság

Miért?
A szoftvernek black box építőelemekre van szüksége, amelyeket párhuzamosan lehet fejleszteni és tesztelni. Ez serkenti a továbbfejleszthetőséget, a produktivitást és a helyességet.

A CCD-értékrendszer elvei eddig kisebb kódrészletekre vonatkoztak. Mi álljon egy eljárásban, mit kellene több eljárásra bontani? Mely eljárásait tegye nyilvánossá egy osztály? Honnan kellene egy kliensobjektumnak egy szervizbjektumra szert tennie? Eddig a szoftverfejlesztés elveiről volt szó kicsiben.

Nincsen mit mondania a CCD-értékrendszernek a szoftverfejlesztés nagyobb struktúráiról? Mi a helyzet a szoftverarchitektúrával? Éppen itt lép képbe a komponensorientáltság. Eddig ugyan használtuk a „komponens” kifejezést, de inkább csak lazán és köznyelvi értelemben. Innentől fogva azonban a komponensnek valami nagyon specifikusat kell jelentenie, amit alapvetőnek tartunk a továbbfejleszthető szoftver szempontjából.

Amíg a szoftvert csak osztályokból és eljárásokból felépülőnek képzeljük el, addig úgymond a számítógépet tranzisztorszinten próbáljuk leírni. Végeredményben ez nem fog menni, mert belefulladunk a részletekbe. Még az osztályok összefoglalása rétegekbe sem segít túl sokat. Inkább egy leírási lehetőségre van szükségünk a nagyobb szoftverstruktúrákra. De nem csak erre: A leíróeszköznek implementációs eszköznek is kellene lennie – olyannak, mint az osztályok – ahhoz, hogy a modell, a terv, a leírás a kódban tükröződjön.

Az operációs rendszer folyamatai ugyanilyen architektúraeszközök, de végeredményben ezek is túl nagyok. Addig, amíg egy egy alkalmazás egy folyamatának egy EXE-je több száz vagy több ezer osztályból áll, addig nem nyerünk ezzel semmit sem.

A komponensorientáltság siet segítségünkre. Azt mondja ki, hogy egy alkalmazásfolyamatnak először is komponensekből kell állnia, nem osztályokból. Csak a komponensek építőelemei lesznek majd az osztályok. És mégis mi egy komponens? Van néhány meghatározás a komponensekre, amelyek közül két kritérium tűnik megingathatatlannak:

  • A komponensek bináris funkcióegységek. (Egy osztály azonban egy forráskódszintű funkcióegység.)
  • A komponensek teljesítményét külön(!) szerződések írják le. (Egy osztály teljesítményének leírása azonban magában az osztályban található. Eljárásai szignatúrájának összege az.)

A Clean Code fejlesztő a szoftver tervezésénél a folyamatok komponensek szerinti meghatározását keresi, amelyekből a folyamatok állni fognak. Azt kérdezi magától, hogy az alkalmazást mely „szolgáltatási blokkok” teszik ki. És ezeket a blokkokat a Clean Code fejlesztő a osztályokból történő felépítése szempontjából fekete doboznak tekinti. Ezek a blokkok jól meghatározott szolgáltatásokkal ellátott assembly-k, de ismeretlen a struktúrájuk.

Egy C klienskompmponens éppen ezért nem tud semmit az S szervizkomponensének az osztálystruktúrájáról, csak S szerződését ismeri, mely független S implementációjától. A szerződések a komponensek számára olyanok, mint az interfészek az osztályok számára. Nem véletlenül állnak a szerződések nagyrészt vagy teljesen interfészekből.

A komponensek tehát ugyanúgy a tervezés elemei, mint a implementációé. Ezt kihangsúlyozandó a komponenseket fizikailag egymástól függetlenül kell implementálni; egy bevált eszköz ehhez a komponens-munkapad, ami elkülönített Visual Studio solution-öket jelent komponensimplementálásonként. Ez nem csak az egy feladatra összpontosítást segíti, mert az ember egy komponens munkája közben az fejlesztői környezetben csak annak a kódját látja. Ezen kívül az álobjektumokat használó konzekvens unit tesztelést is segíti, mivel más komponensek forráskódja nem látható. Az ilyen kódszervezés növeli a produktivitást, mert a szerződések elkülönített szerződéseiknek köszönhetően páthuzamosan fejleszthetők. És végül a fizikai elkülönülés a kód lopódzó entrópianövekedése ellen is hat. Mert ahol a komponensek között a kapcsolatokat csak a szerződésen keresztül lehet felépíteni, ott a csatolás (coupling) laza és kontrollált.

A komponensorientáltsághoz ezért nem csak a bináris, nagyobb kódegységek elkülönített szerződésekkel tartoznak, hanem a szerződések kifejlesztése is még az implementálás előtt (Contract-first Design). Mert amint a szerződések meg vannak határozva, melyeket egy komponens importál és exportál, elkezdődhet mindentől függetlenül a munka a komponensen.

Lásd még az eszközök alatt.

Published inPraktikák