Vonatkozások szétválasztása

A számítástechnikában a vonatkozások szétválasztása olyan tervezési alapelv, amely a számítógépes programot külön szakaszokra különíti el úgy, hogy az egyes szakaszok külön vonatkozásokat fedjenek le. A vonatkozás olyan információkészlet, amely befolyásolja a számítógépes program kódját. A vonatkozás lehet olyan általános, mint "az alkalmazás hardverének részletei", vagy olyan konkrét, mint "melyik osztály neve példányosítható". A szétválasztást jól megtestesítő programot moduláris^[1] programnak nevezzük. A modularitást, és ezáltal a vonatkozások elkülönítését úgy érjük el, hogy az információkat egy jól meghatározott interfésszel rendelkező kódrészbe foglaljuk. Az egységbezárás az információ elrejtésének^[2] egyik eszköze. Az réteges architektúra kialakítása a vonatkozások elkülönítésének másik megvalósítási módja (pl. Prezentációs réteg, üzleti logikai réteg, adatelérési réteg, perzisztencia réteg).^[3]

A vonatkozások szétválasztása nagyobb szabadságfokot eredményez a program tervezésének, telepítésének vagy használatának bizonyos szempontjaiból. Ezek között értjük a kód egyszerűsítésének és karbantartásának fokozott szabadságát. Ha a vonatkozások jól el vannak különítve, több lehetőség kínálkozik a modulok frissítésére, újrafelhasználására és független fejlesztésére. A modulok megvalósítási részleteinek elrejtése - az interfész mögött - lehetővé teszi egyetlen osztály kódrészének javítását vagy módosítását anélkül, hogy a fejlesztőnek ismernie kellene más szakaszok részleteit, és anélkül, hogy módosításokat kellene végrehajtania a többi osztályban. A modulok az interfész különböző változatait is felfedhetik, ami növeli a bonyolult rendszer részleges szerkesztésének szabadságát, a funkciók elvesztése nélkül.

A vonatkozások szétválasztása az absztrakció egyik formája. Csakúgy, mint a legtöbb absztrakció esetében, a vonatkozások elkülönítése további kódrészletek hozzáadását jelenti, azaz általában több végrehajtandó kód jön létre. Tehát a jól elkülönített vonatkozások számos előnye ellenére, gyakran jár a végrehajtás során jelentkező hátrányokkal.

Implementációja

A moduláris vagy objektumorientált programozás mechanizmusai, amelyeket egy programozási nyelv biztosít, lehetővé teszik a fejlesztők számára a szétválasztás fenntartását.^[4] Például az objektumorientált programozási nyelvek, mint a C#, C++, Delphi és Java, elkülöníthetik az átfedéseket külön objektumokká míg, az architekturális tervezési minták, mint az MVC vagy az MVP, a tartalmat elkülöníthetik a nézettől, azaz az adatfeldolgozást (modellt) a tartalomtól. A szolgáltatásorientált tervezés feloszthatja a vonatkozásokat különböző szolgáltatásokká. Az olyan eljárási programozási nyelvek, mint a C és a Pascal, elkülöníthetik a vonatkozásokat eljárásokra vagy függvényekre. Az aspektusorientált programozási nyelvek azt aspektusokra és objektumokra választhatják szét.

A vonatkozások szétválasztása számos más területen is fontos tervezési elv, mint például a várostervezés, az építészet és az információtervezés.^[5] A cél az összetett, egymástól függő rendszerek hatékonyabb megértése, megtervezése és kezelése, hogy a funkciókat újra felhasználhassák, optimalizálhassák más funkcióktól függetlenül, és el lehessen szigetelni más funkciók esetleges meghibásodásaitól.

Gyakori példák: egy hely szétválasztása helyiségekké, hogy az egyik helyiségben végzett tevékenység ne befolyásolja a többi helyiségben élő embereket, valamint a fűtőtest egyik áramkörre, míg a lámpák másikra bekötése, hogy a fűtőtest általi túlterhelés ne kapcsolja le a lámpákat. A szobákkal ellátott példa beágyazást mutat, ahol az egyik helyiségen belüli információ - például az, hogy mennyire rendetlen - a többi helyiség számára nem elérhető, csak az interfészen keresztül, amely az ajtó. Az áramköri példa pedig azt mutatja, hogy az egyik modulon belüli aktivitás, - az az áramkör amely a saját fogyasztóival van összekötve - nem befolyásolja a különböző modulokban végzett tevékenységeket, ezért egyik modul sem foglalkozik azzal, ami a másikban történik.

Eredete

A vonatkozások szétválasztása kifejezését valószínűleg Edsger W. Dijkstra alkotta meg 1974-ben "On the role of scientific thought"^[6] című cikkében.

Tizenöt évvel később az a vonatkozások szétválasztása kifejezés elfogadott gondolattá vált. 1989-ben Chris Reade írt egy könyvet "Elements of Functional Programming"^[7] címmel, amelyben leírja a vonatkozások szétválasztását. A könyvben kifejti, hogy egy programozónak három fő dologra kell figyelnie:

Meg kell határoznia a program végrehajtásának tárgyát
A végrehajtás folyamatát kis lépésekre kell bontania
Kezelnie kell a memóriát a futás során

Reade továbbá azt is mondja, ideális estben a fejlesztőnek csak első pontra kellene koncentrálnia, de megbízhatóbb eredményeket kapunk ha az adminisztrációt leválasztjuk a fő feladatról és automatizáljuk.

Példák

TCP/IP

A vonatkozások elkülönítése elengedhetetlen az Internet kialakítása szempontjából. Az Internet Protocol Suite nagy erőfeszítéseket tett a vonatkozások jól meghatározott rétegekre bontására. Ez lehetővé teszi a protokolltervezők számára, hogy egy rétegben összpontosítsanak az függőségekre, és a többi réteget figyelmen kívül hagyják. Az SMTP alkalmazásréteg protokoll például függ az e-mail munkamenet megbízható szállítási (általában TCP) szolgáltatásán keresztül történő lebonyolításának minden részletétől, de legkevésbé sem vonatkozik rá, hogy a szállítási szolgáltatás hogyan teszi megbízhatóvá ezt a folyamatot. Hasonlóképpen, a TCP sem aggódik az adatcsomagok útválasztása miatt, amelyet a hálózati réteg kezel.

HTML, CSS, JavaScript

A HyperText Markup Language (HTML), a Cascading Style Sheets (CSS) és a JavaScript (JS) kiegészítik egymást a weboldalak és webhelyek fejlesztésénél. A HTML-t főként a weboldal tartalmának szervezésére, a CSS-t a tartalom megjelenítési stílusának meghatározására használják, a JS pedig meghatározza, hogy a tartalom hogyan kommunikál és hogyan viselkedik a felhasználóval. Eredetileg, a CSS bevezetése előtt a HTML mind a szemantika, mind a stílus megjelenítésének feladatait ellátta.

Tárgyorientált programozás

A tárgyorientált programozás lehetővé teszi, hogy a különféle problémákat különálló szoftverkonstrukciókként kezeljék, mindegyiket a többivel egyenlő alapon. Minden vonatkozás biztosítja a saját osztálystruktúráját, amelybe a közös objektumok rendeződnek, és hozzájárul az értékeivel és a metódusaival az összetett eredményhez, amellyel egymást keresztezik. A konzisztencia szabályai leírják, hogy a különféle vonatkozások osztályai és metódusai miként kapcsolódnak egymáshoz, lehetővé téve a metódus összetett viselkedését többféle vonatkozásban. A vonatkozások többdimenziós elkülönítése lehetővé teszi a vonatkozások elemzését és összeállítását többdimenziós "mátrixként", amelyben az egyes vonatkozásokat egy-egy dimenzió reprezentálja, és amelyben különböző választási pontokat sorolnak fel, a mátrix elemeiként a megfelelő szoftverelemek.

Aspektusorientált programozás

Az aspektusorientált programozás lehetővé teszi a kereszthivatkozások elsődleges kérdésként való kezelését. Például a legtöbb program valamilyen biztonságot és naplózást igényel. A biztonság és a naplózás gyakran másodlagos probléma, az elsődleges szempont gyakran az üzleti célok megvalósítása, annak ellenére hogy, a program megtervezésekor, annak biztonságát kezdettől fogva bele kellene építeni a tervezésbe. A biztonság utólagos alkalmazása gyakran elégtelen biztonsági modellt eredményez, amely túl sok rést hagy a jövőbeli támadások számára. Ez megoldható aspektusorientált programozással. Például meg lehet írni egy szempontot, hogy egy bizonyos API-hoz érkező hívásokat és a hibákat, amikor azok egy kivételt dobnak, mindig naplózzák, függetlenül attól, hogy a program eljárási kódja kezeli-e a kivételt, avagy sem.^[8]

A mesterséges intelligencia elemzési szintjei

A kognitív tudományban és a mesterséges intelligenciában gyakran hivatkoznak David Marr elemzési szintjeire. A kutatónak figyelnie kell arra, hogy (1) mire van szüksége, az intelligencia valamilyen aspektusának kiszámításához, (2) ehhez milyen algoritmust kell alkalmaznia, vagy (3) hogy az algoritmust hogyan valósítják meg hardveren. A vonatkozásoknak ez a szétválasztása hasonló az interfész/megvalósítás megkülönböztetéséhez a szoftver- és hardverfejlesztésben.

Normalizált rendszerek

Normalizált rendszerekben a vonatkozások szétválasztása a négy vezérelv egyike. Ezen elv betartása az egyik olyan eszköz, amely segít csökkenteni azokat a kombinatorikus hatásokat, amelyek idővel bekerülnek a karbantartott szoftverekbe. A normalizált rendszerekben a vonatkozások szétválasztását aktívan támogatják az eszközök.

Elválasztás részosztályokon keresztül

A vonatkozások elkülönítése részosztályokon keresztül is meg valósítható és érvényesíthető.^[9]

Szétválasztás részleges osztályokon keresztül Rubyban

bear_hunting.rb

class Bear
  def hunt
    forest.select(&:food?)
  end
end

bear_eating.rb

class Bear
  def eat(food)
    raise "#{food} is not edible!" unless food.respond_to? :nutrition_value
    food.nutrition_value
  end
end

bear_hunger.rb

class Bear
  attr_accessor :hunger
  def monitor_hunger
    if hunger > 50
      food = hunt
      hunger -= eat(food)
    end
  end
end

Jegyzetek

↑ Laplante, Phillip. What Every Engineer Should Know About Software Engineering. CRC Press (2007). ISBN 978-0849372285
↑ Mitchell, Dr. R. J.. Managing Complexity in Software Engineering. IEE, 5. o. (1990). ISBN 0863411711
↑ Microsoft Application Architecture Guide. Microsoft Press (2009). ISBN 978-0-7356-2710-9
↑ Painter. „Software Plans: Multi-Dimensional Fine-Grained Separation of Concerns”, Kiadó: Penn State.
↑ Garofalo, Raffaele. Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern. Microsoft Press, 18. o. (2011). ISBN 978-0735650923
↑ Dijkstra, Edsger W. On the role of scientific thought, Selected writings on Computing: A Personal Perspective. New York, NY, USA: Springer-Verlag, 60–66. o. (1982). ISBN 0-387-90652-5
↑ Reade, Chris. Elements of Functional Programming. Boston, MA, USA: Addison-Wesley Longman (1989). ISBN 0-201-12915-9
↑ Jess Nielsen: Building Secure Applications, 2006. június 1. (Hozzáférés: 2012. február 8.)
↑ Tiago Dias: Hyper/Net: MDSoC Support for .NET. DSOA 2006, 2006. október 1. (Hozzáférés: 2007. szeptember 25.)

Fordítás

Ez a szócikk részben vagy egészben a Separation of concerns című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk

Multi-Dimensional Separation of Concerns Archiválva 2016. augusztus 9-i dátummal a Wayback Machine-ben
TAOSAD Archiválva 2016. december 19-i dátummal a Wayback Machine-ben
Tutorial and Workshop on Aspect-Oriented Programming and Separation of Concerns Archiválva 2008. május 16-i dátummal a Wayback Machine-ben

[laplante-1] Laplante, Phillip. What Every Engineer Should Know About Software Engineering. CRC Press (2007). ISBN 978-0849372285

[mitchell-2] Mitchell, Dr. R. J.. Managing Complexity in Software Engineering. IEE, 5. o. (1990). ISBN 0863411711

[microsoft-3] Microsoft Application Architecture Guide. Microsoft Press (2009). ISBN 978-0-7356-2710-9

[richard-4] Painter. „Software Plans: Multi-Dimensional Fine-Grained Separation of Concerns”, Kiadó: Penn State.

[garofalo-5] Garofalo, Raffaele. Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern. Microsoft Press, 18. o. (2011). ISBN 978-0735650923

[6] Dijkstra, Edsger W. On the role of scientific thought, Selected writings on Computing: A Personal Perspective. New York, NY, USA: Springer-Verlag, 60–66. o. (1982). ISBN 0-387-90652-5

[7] Reade, Chris. Elements of Functional Programming. Boston, MA, USA: Addison-Wesley Longman (1989). ISBN 0-201-12915-9

[8] Jess Nielsen: Building Secure Applications, 2006. június 1. (Hozzáférés: 2012. február 8.)

[9] Tiago Dias: Hyper/Net: MDSoC Support for .NET. DSOA 2006, 2006. október 1. (Hozzáférés: 2007. szeptember 25.)

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]