CSC/ECE 517 Fall 2012/ch2a 2w25 nr: Difference between revisions
No edit summary |
|||
| Line 4: | Line 4: | ||
[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request. | [http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request. | ||
In a way, law of demeter can be thought of a more specialized version of low coupling principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system. | In a way, law of demeter can be thought of a more specialized version of low [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system. | ||
=='''Who can class A interact with ?<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>'''== | =='''Who can class A interact with ?<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>'''== | ||
Revision as of 23:55, 26 October 2012
Law of Demeter
Introduction
Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.
In a way, law of demeter can be thought of a more specialized version of low coupling principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system.
Who can class A interact with ?<ref name="">Who can class interact with</ref>
If M is a method belonging to class A, then M may invoke other methods belonging to the following:
1. Class A
2. Members of A
3. Parameters of A
4. Objects created by M
5. Objects created by other methods of class A called by M
6. Globally accessible objects
When and How to identify Law of Demeter
Chained 'get' statements
value = object.getName().getCountry().getZip()
This clearly denotes we are violating the law of demeter since we our access crosses the boundary.
Importing or including many classes
In java we tend to include a lot of libraries, this is also an indication of law violation.
Advantages<ref name="Advantages">Advantages</ref>
Reusable code
Better design
Less risk of breaking functionality
Modular code
References
<references/>