Demeter törvénye

Demeter törvénye egy szoftverfejlesztési irányelv, melyet elsősorban objektumorientált programoknál alkalmaznak. Az irányelvet az Északkeleti Egyetemen, Bostonban fogalmazták meg 1987 őszén. A lényege: „csak a közvetlen barátaiddal beszélgess”. Egy adott objektum más dolgok felépítését vagy tulajdonságait a lehető legkevésbé ismerje.

Az A objektum igénybe veheti a B objektum egy szolgáltatását (meghívja egy metódusát), de A objektum nem érheti el a B objektumon keresztül egy C objektum szolgáltatásait. Ez azt jelentené, hogy az A objektumnak implicit módon a szükségesnél jobban kell ismernie a B objektum belső felépítését. A megoldás B objektum felépítésének módosítása oly módon, hogy az A objektum közvetlenül hívja B objektumot, és a B objektum intézi a szükséges hívásokat a megfelelő alkomponensekhez. Ha a törvényt követjük, kizárólag B objektum ismeri saját belső felépítését.

Kissé formálisabban O objektum M metódusa a következőket hívhatja:

• O-t magát
• M paramétereit
• M-en belül létrehozott/példányosított objektumokat
• O közvetlen komponenseit

Általánosságban egy objektumnak el kell kerülnie egy meghívott objektum által visszaadott objektum metódusainak hívását, például A.x().y().

Demeter törvényét alkalmazva a szoftver sokkal karbantarthatóbb és adaptálható lesz. Mivel az objektumok kevésbé függnek más objektumok belső felépítésétől, az objektumok felépítése sokkal könnyebben módosítható, akár a hívó szerkezetének módosítása nélkül is.

Hátrányok

A törvény alkalmazásának egyik hátránya, hogy szükségessé teszi kis burkoló metódusok használatát, melyek továbbítják a kéréseket a megfelelő komponensekhez. Ez növelheti a belső fejlesztési időt, a tárigényt, és csökkentheti a teljesítményt.

Emellett a burkoló metódusok inverz függőségeket hozhatnak létre. Ha egy kliensnek ellenjavalljuk, hogy egy harmadik féllel kommunikáljon, és ehelyett inkább kliens-specifikus metódusokat építünk be (pl. getAsUsualPleaseForBobby()), akkor a módosított objektum fokozatosan elveszíti önálló, független jellegét. Így az elv szolgai alkalmazása egyes esetekben csak fordítottá és implicitté teszi azokat a függőségeket, amelyeket meg akart szüntetni.

Nehéz lehet eldönteni azt is, hogy egyáltalán milyen dolgokat tekintsünk az elv hatáskörébe tartozó „szolgáltatásnak”. Adat- és segédobjektumok (például egy matcher) esetében például nem beszélhetünk önálló szolgáltatásról.

Irodalom

• (1989. szeptember 1.) „Assuring good style for object-oriented programs”. IEEE Software, 38–48. o. 
• Lieberherr, Karl J. (1995. november 26.). „Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns”, Boston, Kiadó: PWS Publishing Company, International Thomson Publishing. 
• The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley, 140–141. o. (2002. november 26.) 
• Larman, Craig. Applying UML and Patterns, 3rd, Prentice Hall, 430–432. o. (2005. november 26.)  (from this book, "Law of Demeter" is also known as "Don't talk to strangers")
• McConnell, Steve. Code Complete, 2nd, Microsoft Press, 150. o. (2004. november 26.) 
• ASP.NET MVC in Action. Manning Publications, 14. o. (2009. november 26.) 

További információk

• Simple Law of Demeter in Ruby/Rails with demeter gem
• Brad Appleton: “Introducing Demeter and its Laws”
• “Object-Oriented Programming: An Objective Sense of Style” (OOPSLA '88 Proceedings) (PDF)
• The Paperboy, The Wallet, and The Law Of Demeter (PDF)
• Phil Haack: "The Law of Demeter is not a Dot Counting Exercise"
• Lieber: "Phil Holland's Law of Demeter"