Merhaba, bu seride sizlere Uncele Bob'un (Robert C. Martin) SOILD presnipleri için yazdığı makaleleri Türkçe'ye çevireceğim. Umarım yararlı bir yazı dizisi olur.
Seri'nin diğer yazıları :
Open Closed Principle
"None but Buddha himself must take the responsibility of giving out occult secrets..." — E. Cobham Brewer 1810–1897. Dictionary of Phrase and Fable. 1898.
"Buda'nın kendisi dışında hiçbiri gizli sırlar verme sorumluluğunu almamalıdır ..."
Bu ilke Tom DeMarco ve Meilir Page-Jones çalışmalarında tanımlanmıştır. Bu çalışmalarada bu prensibe cohession denmiştir. Cohession ise bir modülün ilişkili elemanları arasında fonksiyonel ilişkinliği ifade etmektedir.
Bu bölümde, bu anlamı biraz değiştireceğiz ve uyumu bir modülün veya bir sınıfın değişmesine neden olan sebeplerle ilişkilendireceğiz.
A CLASS SHOULD HAVE ONLY ONE REASON TO CHANGE.
(Bir sınıf sadece bir sebepten dolayı değişmelidir.)
Bir Game sınıfının olduğunu ve bu sınıfın mevcut kareyi takip etmek ve skoru hesaplamak gibi iki ayrı sorumluluğu olduğunu düşünelim. Dikkat ederseniz sınıfın birbirinden farklı iki sorumluluğu mevcut. Bu durumada, bu iki sorumluluk iki sınıfa ayrılmalıdır. Game, kareleri takip etme sorumluluğunu sürdürürken, yeni oluşturulan Scorer sınıfı skoru hesaplama sorumluluğunu alır.
Bu iki sorumluluğu iki ayrı sınıfa ayırma nedenimiz nedir ? Çünkü her sorumluluk bir değişim eksenidir. Gereksinimler değiştiğinde, bu değişiklik sınıflar arasında sorumluluk değişikliği ile ortaya çıkacaktır. Bir sınıf birden fazla sorumluluk üstlenirse, değişmesi için birden fazla sebep olacaktır.
Bir sınıfın birden fazla sorumluluğu varsa, sorumluluklar coupled(çift hale gelmiş) olmuş demektir.
Bir sorumlulukta yapılan değişiklikler, sınıfın diğer sorumluklarını kullanma yeteneğini bozabilir veya engelleyebilir. Sorumluluklar arasında bu tür bağlantı, değişiklikte beklenmedik şekillerde kırılgan tasarımlara yol açar.
Örneğin, aşağıdaki tasarımı düşünün. Rectangle sınıfının gösterilen iki yöntemi vardır. Biri dikdörtgeni ekrana çizer, diğeri dikdörtgenin alanını hesaplar.
İki farklı uygulama Rectangle sınıfını kullanır. Bir uygulama hesaplamalı geometri yapar. Geometrik şekillerin matematiğinde yardımcı olması için Rectangle kullanır.Asla dikdörtgeni ekrana çizmez.Diğer uygulama doğası gereği grafikseldir. Ayrıca bazı hesaplama geometrisi yapabilir, ancak kesinlikle dikdörtgeni ekrana çizer.
Bu tasarım SRP'yi ihlal etemektedir. Rectangle sınıfının iki sorumluluğu vardır. İlk sorumluluk, bir dikdörtgenin geometrisinin matematiksel bir modelini sağlamaktır. İkinci sorumluluk, dikdörtgeni grafik kullanıcı arayüzünde oluşturmaktır.
SRP'nin ihlali birkaç kötü soruna neden olur. İlk olarak, GUI'yi hesaplamalı geometri uygulamasına dahil etmeliyiz. .NET'te GUI bağımlılığının derlemesinin hesaplamalı geometri uygulamasıyla oluşturulması ve dağıtılması gerekir.
İkinci olarak, GraphicalApplication üzerinde yapılan bir değişiklik Rectangle'ın bir nedenle değişmesine neden olursa, bu değişiklik bizi ComputationalGeometryApplication uygulamasını yeniden oluşturmaya, yeniden test etmeye ve yeniden konuşlandırmaya zorlayabilir. Bunu yapmayı unutursak, bu uygulama öngörülemeyen şekillerde bozulabilir.
Daha iyi bir tasarım, iki sorumluluğu aşağıda gösterildiği gibi tamamen farklı iki sınıfa ayırmaktır. Bu tasarım, Dikdörtgenin hesaplama bölümlerini GeometricRectangle sınıfına taşır. Şimdi dikdörtgenlerin oluşturulma biçiminde yapılan değişiklikler ComputationalGeometryApplication'ı etkileyemez.
What is a Responsibility?
(Sorumluluk nedir?)
Tek Sorumluluk İlkesi (SRP) bağlamında bir sorumluluğu “değişim nedeni” olarak tanımlıyoruz. Bir sınıfı değiştirmek için birden fazla nedeni düşünebiliyorsanız, o sınıfın birden fazla sorumluluğu vardır. Bunu görmek bazen zor olabilir. Sorumlulukları gruplar halinde düşünmeye alışkınız. Örneğin, aşağıdaki Modem arayüzünü düşünün. Çoğumuz bu arayüzün son derece makul göründüğünü kabul edeceğiz. Bildirdiği dört işlev kesinlikle modeme ait işlevlerdir.
Ancak, burada gösterilen iki sorumluluk vardır. İlk sorumluluk bağlantı yönetimidir. İkincisi veri iletişimidir. Dial ve Hangup işlevleri modem bağlantısını yönetirken, Send ve Recv işlevleri veri iletir.
Bu iki sorumluluk birbirinden ayrılmalı mı? Bu uygulamanın nasıl değiştiğine bağlıdır. Uygulama, bağlantı işlevlerinin imzasını etkileyecek şekilde değişirse, tasarım Rigidity(Sertlik) kokusu alacaktır, çünkü gönderme ve okuma çağrısı yapan sınıfların bizim istediğimizden daha sık derlenmesi ve yeniden konuşlandırılması gerekecektir. Bu durumda iki sorumluluk aşağıda gösterildiği gibi ayrılmalıdır. Bu, istemci uygulamalarının iki sorumluluğu birleştirmesini önler.
Öte yandan, uygulama iki sorumluluğun farklı zamanlarda değişmesine neden olacak şekilde değişmiyorsa, bunları ayırmaya gerek yoktur. Gerçekten de onları ayırmak Needless Complexity(Gereksiz Karmaşıklık) kokusu alacaktı.
Burada bir korozyon var. Bir değişim ekseni, yalnızca değişiklikler gerçekten meydana gelirse bir değişim eksenidir. Herhangi bir belirti yoksa, SRP'yi veya bu konuda başka bir ilkeyi uygulamak akıllıca değildir.
Separating coupled responsibilities.
(Birleştirilmiş sorumlulukların ayrılması.)
Şekil 8-3'te ModemImplementation sınıfında her iki sorumluluğu da yerine getirdiğime dikkat edin. Bu arzu edilmez, ancak gerekli olabilir. Donanım veya işletim sisteminin ayrıntılarıyla ilgili olmak zorunda olduğumuz ve bizi çift olmayı tercih etmeyeceğimiz şeyleri birleştirmeye zorlayan çoğu zaman sebepler vardır. Bununla birlikte, arayüzlerini ayırarak, uygulamanın geri kalanıyla ilgili olarak kavramları birbirinden ayırdık.
ModemImplementation sınıfını bir çamur veya siğil olarak görebiliriz; ancak, tüm bağımlılıkların bundan uzaklaştığına dikkat edin. Kimsenin bu sınıfa ihtiyacı yoktur. Ana ihtiyaçlar dışında hiç kimse bunun var olduğunu bilmeye ihtiyaç duymaz. Böylece, çirkin parçayı bir çitin arkasına koyduk. Çirkinliğin dışarı sızmasına ve uygulamanın geri kalanını kirletmesine gerek yoktur. (Sınıf yerine Interface bağımlılığından bahsediliyor)
SONUÇ
SRP, ilkelerin en basitlerinden ve doğru yapılması en zorlarından biridir. Birbirine karşı sorumluluklar, doğal olarak yaptığımız bir şeydir. Bu sorumlulukları bulmak ve birbirinden ayırmak, yazılım tasarımının gerçekte ne olduğudur. Gerçekten de tartışacağımız ilkelerin geri kalanı bu ilkeye şu ya da bu şekilde geri dönüyor.
Bibliography [DeMarco79]: Structured Analysis and System Specification, Tom DeMarco, Yourdon Press Computing Series, 1979
[PageJones88]: The Practical Guide to Structured Systems Design, 2d. ed., Meilir PageJones, Yourdon Press Computing Series, 1988
Yazının Orjinali
Bonus :
Seri'nin diğer yazıları :
Open Closed Principle
1 - SRP: The Single Responsibility Principle
"None but Buddha himself must take the responsibility of giving out occult secrets..." — E. Cobham Brewer 1810–1897. Dictionary of Phrase and Fable. 1898.
"Buda'nın kendisi dışında hiçbiri gizli sırlar verme sorumluluğunu almamalıdır ..."
Bu ilke Tom DeMarco ve Meilir Page-Jones çalışmalarında tanımlanmıştır. Bu çalışmalarada bu prensibe cohession denmiştir. Cohession ise bir modülün ilişkili elemanları arasında fonksiyonel ilişkinliği ifade etmektedir.
Bu bölümde, bu anlamı biraz değiştireceğiz ve uyumu bir modülün veya bir sınıfın değişmesine neden olan sebeplerle ilişkilendireceğiz.
A CLASS SHOULD HAVE ONLY ONE REASON TO CHANGE.
(Bir sınıf sadece bir sebepten dolayı değişmelidir.)
Bir Game sınıfının olduğunu ve bu sınıfın mevcut kareyi takip etmek ve skoru hesaplamak gibi iki ayrı sorumluluğu olduğunu düşünelim. Dikkat ederseniz sınıfın birbirinden farklı iki sorumluluğu mevcut. Bu durumada, bu iki sorumluluk iki sınıfa ayrılmalıdır. Game, kareleri takip etme sorumluluğunu sürdürürken, yeni oluşturulan Scorer sınıfı skoru hesaplama sorumluluğunu alır.
Bu iki sorumluluğu iki ayrı sınıfa ayırma nedenimiz nedir ? Çünkü her sorumluluk bir değişim eksenidir. Gereksinimler değiştiğinde, bu değişiklik sınıflar arasında sorumluluk değişikliği ile ortaya çıkacaktır. Bir sınıf birden fazla sorumluluk üstlenirse, değişmesi için birden fazla sebep olacaktır.
Bir sınıfın birden fazla sorumluluğu varsa, sorumluluklar coupled(çift hale gelmiş) olmuş demektir.
Bir sorumlulukta yapılan değişiklikler, sınıfın diğer sorumluklarını kullanma yeteneğini bozabilir veya engelleyebilir. Sorumluluklar arasında bu tür bağlantı, değişiklikte beklenmedik şekillerde kırılgan tasarımlara yol açar.
Örneğin, aşağıdaki tasarımı düşünün. Rectangle sınıfının gösterilen iki yöntemi vardır. Biri dikdörtgeni ekrana çizer, diğeri dikdörtgenin alanını hesaplar.
İki farklı uygulama Rectangle sınıfını kullanır. Bir uygulama hesaplamalı geometri yapar. Geometrik şekillerin matematiğinde yardımcı olması için Rectangle kullanır.Asla dikdörtgeni ekrana çizmez.Diğer uygulama doğası gereği grafikseldir. Ayrıca bazı hesaplama geometrisi yapabilir, ancak kesinlikle dikdörtgeni ekrana çizer.
Bu tasarım SRP'yi ihlal etemektedir. Rectangle sınıfının iki sorumluluğu vardır. İlk sorumluluk, bir dikdörtgenin geometrisinin matematiksel bir modelini sağlamaktır. İkinci sorumluluk, dikdörtgeni grafik kullanıcı arayüzünde oluşturmaktır.
SRP'nin ihlali birkaç kötü soruna neden olur. İlk olarak, GUI'yi hesaplamalı geometri uygulamasına dahil etmeliyiz. .NET'te GUI bağımlılığının derlemesinin hesaplamalı geometri uygulamasıyla oluşturulması ve dağıtılması gerekir.
İkinci olarak, GraphicalApplication üzerinde yapılan bir değişiklik Rectangle'ın bir nedenle değişmesine neden olursa, bu değişiklik bizi ComputationalGeometryApplication uygulamasını yeniden oluşturmaya, yeniden test etmeye ve yeniden konuşlandırmaya zorlayabilir. Bunu yapmayı unutursak, bu uygulama öngörülemeyen şekillerde bozulabilir.
Daha iyi bir tasarım, iki sorumluluğu aşağıda gösterildiği gibi tamamen farklı iki sınıfa ayırmaktır. Bu tasarım, Dikdörtgenin hesaplama bölümlerini GeometricRectangle sınıfına taşır. Şimdi dikdörtgenlerin oluşturulma biçiminde yapılan değişiklikler ComputationalGeometryApplication'ı etkileyemez.
What is a Responsibility?
(Sorumluluk nedir?)
Tek Sorumluluk İlkesi (SRP) bağlamında bir sorumluluğu “değişim nedeni” olarak tanımlıyoruz. Bir sınıfı değiştirmek için birden fazla nedeni düşünebiliyorsanız, o sınıfın birden fazla sorumluluğu vardır. Bunu görmek bazen zor olabilir. Sorumlulukları gruplar halinde düşünmeye alışkınız. Örneğin, aşağıdaki Modem arayüzünü düşünün. Çoğumuz bu arayüzün son derece makul göründüğünü kabul edeceğiz. Bildirdiği dört işlev kesinlikle modeme ait işlevlerdir.
Modem.cs -- SRP Violation
public interface Modem
{
public void Dial(string pno);
public void Hangup();
public void Send(char c);
public char Recv();
}
Ancak, burada gösterilen iki sorumluluk vardır. İlk sorumluluk bağlantı yönetimidir. İkincisi veri iletişimidir. Dial ve Hangup işlevleri modem bağlantısını yönetirken, Send ve Recv işlevleri veri iletir.
Bu iki sorumluluk birbirinden ayrılmalı mı? Bu uygulamanın nasıl değiştiğine bağlıdır. Uygulama, bağlantı işlevlerinin imzasını etkileyecek şekilde değişirse, tasarım Rigidity(Sertlik) kokusu alacaktır, çünkü gönderme ve okuma çağrısı yapan sınıfların bizim istediğimizden daha sık derlenmesi ve yeniden konuşlandırılması gerekecektir. Bu durumda iki sorumluluk aşağıda gösterildiği gibi ayrılmalıdır. Bu, istemci uygulamalarının iki sorumluluğu birleştirmesini önler.
Öte yandan, uygulama iki sorumluluğun farklı zamanlarda değişmesine neden olacak şekilde değişmiyorsa, bunları ayırmaya gerek yoktur. Gerçekten de onları ayırmak Needless Complexity(Gereksiz Karmaşıklık) kokusu alacaktı.
Burada bir korozyon var. Bir değişim ekseni, yalnızca değişiklikler gerçekten meydana gelirse bir değişim eksenidir. Herhangi bir belirti yoksa, SRP'yi veya bu konuda başka bir ilkeyi uygulamak akıllıca değildir.
Separating coupled responsibilities.
(Birleştirilmiş sorumlulukların ayrılması.)
Şekil 8-3'te ModemImplementation sınıfında her iki sorumluluğu da yerine getirdiğime dikkat edin. Bu arzu edilmez, ancak gerekli olabilir. Donanım veya işletim sisteminin ayrıntılarıyla ilgili olmak zorunda olduğumuz ve bizi çift olmayı tercih etmeyeceğimiz şeyleri birleştirmeye zorlayan çoğu zaman sebepler vardır. Bununla birlikte, arayüzlerini ayırarak, uygulamanın geri kalanıyla ilgili olarak kavramları birbirinden ayırdık.
ModemImplementation sınıfını bir çamur veya siğil olarak görebiliriz; ancak, tüm bağımlılıkların bundan uzaklaştığına dikkat edin. Kimsenin bu sınıfa ihtiyacı yoktur. Ana ihtiyaçlar dışında hiç kimse bunun var olduğunu bilmeye ihtiyaç duymaz. Böylece, çirkin parçayı bir çitin arkasına koyduk. Çirkinliğin dışarı sızmasına ve uygulamanın geri kalanını kirletmesine gerek yoktur. (Sınıf yerine Interface bağımlılığından bahsediliyor)
SONUÇ
SRP, ilkelerin en basitlerinden ve doğru yapılması en zorlarından biridir. Birbirine karşı sorumluluklar, doğal olarak yaptığımız bir şeydir. Bu sorumlulukları bulmak ve birbirinden ayırmak, yazılım tasarımının gerçekte ne olduğudur. Gerçekten de tartışacağımız ilkelerin geri kalanı bu ilkeye şu ya da bu şekilde geri dönüyor.
Bibliography [DeMarco79]: Structured Analysis and System Specification, Tom DeMarco, Yourdon Press Computing Series, 1979
[PageJones88]: The Practical Guide to Structured Systems Design, 2d. ed., Meilir PageJones, Yourdon Press Computing Series, 1988
Yazının Orjinali
Bonus :
Bonus :
Tags
code quality
OOD
OOP
Single Responsibility Principle
Software Architecture
Software Engineering
SOLID
SRP