Design Patterns- Low Coupling And High Cohesion

1. Design Patterns- Low Coupling And High Cohesion By: Eliezer Jacob And Idan Cohen

2. Introduction • Incomputer sciencecouplingordependencyis the degree to which each program module relies on each one of the other modules. • Our target we always want to reach is to use low or weak connection between objects or classes but get high cohesion. • When we use low coupling, any change in one module shouldn’t bring change in another.

3. Example Here is the class diagram of the example: Register Without low coupling Sale Payment Register With low coupling Sale Payment

4. Difficulties in system without low coupling Systems that do not exhibit low coupling might experience the following developmental difficulties: • Change in one module force a ripple of changes in other module (not always possible). • Modules are difficult to understand in isolation. • Modules are difficult to reuse or test because dependent modules must be included.

5. Low Coupling- Continue • The concept of coupling is usually related to the concept of cohesion: low coupling facilitates high cohesion, and vice versa. • For example, one approach to increasing cohesion is functional design. Modules with single responsibilities tend to communicate less with other modules, which typically causes the side-effect of reduced coupling. • This can also be seen in OOP, where coherence is said to increase when classes are refactored to contain more closely-related code. This tends to cause the connections between the classes to become less dependent on their internal implementations, which results in reduced coupling.

6. Low Coupling- Continue • Specifically, coupling increases between two classes A and B if: • A has an attribute that refers to (is of type) B. • A calls on services of an object B. • A has a method which references B (via return type or parameter). • A is a subclass of (or implements) class B.

7. Types Of Coupling • The types of coupling are as follows: • Content coupling (worst): when one module modifies or relies on the internal workings of another module. Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependant module. • Data coupling: when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data which are share. • Message coupling (low and best): This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange messages.

8. Example for Low Coupling Suppose we have the following situation by the POS example: there are- Sale, Register, Payment. We want to make a payment through register and update payment and sale. Here are 2 ways to build the model: 1) 1: create() makePayment() :Register p: Payment 2: addPayment(p) :Sale 2) 1: makePayment() makePayment() :Register :Sale 1.1: create() :Payment

9. Example for Low Coupling- continue Now, lets test the 2 models in point of view of low coupling. The first add the connection of register to payment, while the other one doesn't increase the connection at all. The first model obligate the running of 2 functions, meaning 2 different connections. The second model obligate the running of one function (makePayment) and as a result the other function as well (create), meaning the connection from register has done only for sale and sale run payment.

10. Example of High Cohesion As the example of low coupling, here is the example of high cohesion: 1) 1: create() makePayment() :Register p: Payment 2: addPayment(p) :Sale 2) 1: makePayment() makePayment() :Register :Sale 1.1: create() :Payment

11. Example of High Cohesion- Continue Now, lets test the 2 models in point of view of low coupling. Here, we try that register performed the action of makePayment, but if we will load more and more function on register it won’t be cohesion at all. For instance, let suppose we have 50 systems and they are all received by register. If it will do everyone works we get non- cohesion and also collapse. The target is to consider not payment only, but more like its. As you can see, the second model take the “responsibility” of payment creation to sale and it supporting high cohesion in register.

12. Example-Health Care Center

13. Example-Health Care Center

14. הדוגמא של בית החולים: 1) רופא מקושר לפגישה, פגישה מקושרת לחולה ורופא מקושר לחולה. אין צורך שחולה יחזיק את פגישה, הוא רק יחזיק קשר שלו עם הרופא האישי שלו ודרכו יוכל לדעת מתי הפגישה שלו. 2) נניח שהפקיד שגובה את התשלום הרבעוני הוא גם קובע פגישות לחולים ב- call center. כך, יש קשר בין הפקיד לCC, בין ה-CC לחולה, ובין הפקיד לחולה. ניתן לצמצם זאת כך שהחולה יפנה לפקיד אם ברצונו לבדוק את פגישותיו, לתאם פגישה או לבטל פגישה. והורדנו את הקשר של החולה עם ה-CC. סה"כ חסכנו ב-2 קשרים במערכת מסועפת אך קטנה יחסית ולכן הנמכנו את הקישור בין המחלקות והמידול שלנו נכון ופשוט יותר. וההתלכדות נשארה אותו דבר ואף גדלה (לחולה יש מניע לפנות יותר לפקיד כדי לקבל או לתת לו יותר מידע).

15. summary To summarize, low coupling came, many times, combined with high cohesion and it’s desirable they come together. Low coupling help the programmer to connect less objects and classes between themselves, and high cohesion help sharing things despite the low coupling. The perfect program\model is when we have low coupling and high cohesion together!