Tasarım Seviyesinde Eşleşme (Coupling) Nedir

Giriş

Coupling iki bakış açısıyla tanımlanabilir.

1. Mimari Seviye
2. Tasarım Seviye

Bu yazıda daha çok tasarım seviyesi açıklamak amaçlanıyor.

Coupling Nedir?

Açıklaması şöyle

"The degree in which components depend on each other for their proper operation is called coupling. Coupling is achieved primarily by the mechanisms chosen to interact between components. The less coupled a system is, the more cohesive it is."

Bir başka açıklama şöyle

In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are the strength of the relationships between modules.

Bir başka açıklama şöyle

Generally speaking, the ease with which any system can be extended is dependent upon the degree to which its subsystems are tightly or loosely coupled. Usually, the more loosely coupled the subsystems are, the easier it is to modify them as they are isolated & don't necessarily require a complete understanding of the system as a whole

Nesneye Yönelik Tasarım

Nesneye Yönelik Tasarımda High Cohesion, Low Coupling amacına ulaşılmaya çalışılır.

Modüller Arası Coupling 

Şeklen şöyle

Diğer Coupling Çeşitleri
Bazı coupling çeşitleri şöyle.

No coupling: The modules do not know each other.
Call coupling: A module calls another one.
Data coupling: A module calls another one passing parameters to it.
Stamp coupling: A module calls another one passing complex parameters to it.
Control coupling: A module influences the control flow of another module.
External coupling: The modules communicate using a simple global variable.
Common coupling: The modules communicate using a common global data structure.
Content coupling: A modules depends on the inner working of another module. This is the strongest form of coupling.

Call Coupling 

Bir nesne diğerini çağıracaktır ve bundan kaçış yoktur. Bunu iki şekilde çözebiliriz

1. A nesneyi B nesnesine üye alan (field, member) olarak verilir.

2. A nesnesi B nesnesine metod parametresi olarak verilir. 

Her ikisi de Call Coupling olmasına rağmen muhtemelen 2. yöntem yani metod parametresi olarak kullanmak daha düşük bir coupling yaratır. Açıklaması şöyle

... injects dependencies not only into objects but also as arguments into methods. This means we do not have to structurally link all objects together ... The method just adds a new parameter for a new dependency. The result is we avoid high coupling because objects no longer require structural references to all other objects.

Coupling'e Sebep Olan Yöntemler

Bir kaç sebep sayılabilir.

1. Inheritance

Kalıtım sıkı bir coupling sözleşmesidir. Kalıtım ile gelen arayüze sadık kalmak gerekir. 

2. Composition

3.Composition With Interfaces

4. Data Transfer Objects

5. Streams and pipes

Kod içinde circular reference varsa High Coupling olduğu çok rahat görülebilir.

Low Coupling Nasıl Elde Edilir?

Bir çok yöntem var.

1.En basit olanı Encapsulation (Bilgi Saklama) kullanmak. Encapsulation şöyle tarif edilir.

"Encapsulation (aka information hiding) is the idea that one shouldn't expose implementation details"

The degree in which components depend on each other for their proper operation is called coupling. Coupling is achieved primarily by the mechanisms chosen to interact between components. The less coupled a system is, the more cohesive it is.

2. Message Center kullanmak. Açıklaması şöyle. Burada Message Center Publish/Subscribe veya benzeri bir altyapıyı temsil ediyor.

Message center reduces coupling and enables view models and other components to communicate with without having to know anything about each other besides a simple Message contract.

3. Bazı tasarım Örüntüleri Kullanmak
Örneğin Facade örüntüsü coupling'i bitirmez ancak azaltabilir. Açıklaması şöyle.

The facade hides whatever you do behind it. It is similar to how an object encapsulates its state. The facade encapsulates a (sub)system. The consumer code only needs to talk to the facade and it is unaware of the details behind it.

Of course, it is still coupled. And yes, you have moved the problem to the Facade. However, thanks to the Facade, the consumer code does not have to change because of the changes of what is behind the facade.

Coupling (Eşleşme) Nedir - Architectural Principle

Giriş
Coupling iki bakış açısıyla tanımlanabilir.

1. Mimari Seviye
2. Tasarım Seviye

1. Mimari Seviyede Eşleşme
Mimari seviyeden bakarsak Coupling aslında bir Mimari Prensibi (Architectural Principle). Yani hangi Architectural Style veya hangi Architectural Pattern kullanılıyor olursa olsun bu kuralın dikkate alınması gerekiyor. Mimari seviyede Coupling dışındaki diğer bazı prensipler de şeklen şöyle.

Mimari seviyesindeki bakış açısıyla şöyle bir liste yapabiliriz.

There are degrees of loose coupling. It's not a binary state. This is not a complete list, but for the purposes of this discussion, some degrees are:

Level 0 - No abstractions, hardcoded references

Level 1 - Abstractions (interfaces), but everything in one project

Level 2 - One solution, separate projects abstractions

Level 3 - Abstractions are not part of the project but are loaded separately (think NuGet)

Level 4 - Independently hosted microservices

Level 3 ve 4 ile ilgili bazı açıklamalar şöyle. Level 3 standartlaşmaya doğru gitmiş ve muhtemelen tekrar kullanılabilen bir soyutlama seviyesinde. Ancak halen, Level 3 seviyesinde yapılan bir değişiklik diğer kod parçalarında tekrar derlemeye sebep oluyor.

Level 3 moves the abstraction out of the solution, so that it can live its own life. This is the most useful when more than one solution consumes this abstraction, or when the developers of the abstraction are a completely different team from the developers of the main product. Maybe it's a different company team, maybe they're different companies altogether.

You've probably used several third party libraries. How much did you know about their teams, who developed them, or the internals of the library they created? Not much. And that's the point, because the abstraction is so loosely coupled to the end product that you don't even need to know anything (other than its interface) about it anymore.

But level 3 still suffers a specific problem: if the abstraction gets updated, then all of its consumers will have to rebuild (or at the very least re-release) to account for these new changes. This requires an active line of communication, at least one-way (e.g. a third party developer's news feed announcing a patch to fix issues or expand the feature set).

This is what level 4 (microservices) solve. Because it's now an independently deployed application, any published change goes live for every consumer at the same time. The consumers don't need to change anything or re-release their own application.

As long as the interface or public URL doesn't change, the two services don't even need to communicate anything about any of their changes.

Örnek

Bir örnek şöyle

A very clear example of why this is desirable is e.g. an identity provider.

- Levels 0/1/2 all amount to authorization for this specific application.

- Level 3 makes it possible to standardize identity management across all of the library's consumers, but in the end each consumer is still choosing to update to new versions of the library individually.

- By having this as a microservice (level 4), any changes made to the identity provider (e.g. changed rights, user access, different security protocols) automatically deploy everywhere at the same time, and the developers of the consuming applications don't even need to be kept in the loop at any stage.

Microservice Mimarisinde Low Coupling
Level 4 ile coupling seviyesi en düşük olan seviye bu. Bu seviyede artık değişiklikler yüzünden kodu tekrar derleme azalıyor. Açıklaması şöyle.

services know little about each other. A change to one service should not require changing the others. Communication between services should happen only through public service interfaces.

Eğer low coupling olmazsa açıklaması şöyle.

Without loose coupling, changes to one service affect other services, so we would not be able to release changes fast and safely, which is the core benefit of microservice architecture. More importantly, issues caused by tight coupling could be disastrous, e.g., data inconsistencies or even data loss.

2. Tasarım Seviyesinde Eşleşme
Tasarım Seviyesinde Eşleşme - Coupling yazısına taşıdım