Her sınıfın sadece bir sorumluluğu olduğundan emin olun, neden?

Microsoft belgelerine göre, Wikipedia SOLID ilke makalesi veya çoğu BT mimarı, her sınıfın yalnızca bir sorumluluğunun olmasını sağlamalıyız. Nedenini bilmek istiyorum, çünkü eğer herkes bu kurala katılıyorsa kimse bu kuralın nedenleri konusunda hemfikir değil gibi görünüyor.

Bazıları daha iyi bakım sunulduğunu, bazılarının kolay test edildiğini veya sınıfın daha sağlam veya güvenli olduğunu belirtti. Doğru ve ne anlama geliyor? Bakım neden daha iyi, testler daha kolay mı yoksa kod daha sağlam mı?

Modülerlik. Herhangi bir makul dil size kod parçalarını bir arada yapıştırma imkanı verecektir, ancak programcı kaynak üzerinde ameliyat gerçekleştirmeden büyük bir kod parçasını yapıştırmanın genel bir yolu yoktur. Bir kod yapısına birçok görevi sıkıştırarak kendinizi ve başkalarını parçalarını başka şekillerde bir araya getirme fırsatını soyar ve bir parçanın diğerlerini etkileyebilecek değişikliklere neden olabilecek gereksiz bağımlılıklar ortaya çıkarırsınız.

SRP, sınıflar için olduğu kadar işlevler için de geçerlidir, ancak genel OOP dilleri birbirine yapıştırma işlevlerinde göreceli olarak zayıftır.

Daha iyi bakım, kolay test, daha hızlı hata düzeltme, SRP uygulamasının sadece (çok hoş) sonuçlarıdır. Asıl sebep (Robert C. Matin'in söylediği gibi):

Bir sınıfın değişmesi için bir ve sadece bir nedeni olmalıdır.

Başka bir deyişle, SRP değişim yerini yükseltir .

SRP ayrıca DRY kodunu da teşvik eder. Sadece bir sorumluluğu olan sınıflarımız olduğu sürece, onları istediğimiz her yerde kullanmayı seçebiliriz. İki sorumluluğu olan bir sınıfımız varsa, ancak bunlardan sadece birine ihtiyacımız var ve ikincisi müdahale ediyorsa, 2 seçeneğimiz var:

1. Sınıfı bir diğerine kopyalayıp yapıştırın ve hatta başka bir çok sorumluluklu mutant yaratın (teknik borcu biraz artırın).
2. Sınıfı bölün ve orijinal sınıfın kapsamlı kullanımı nedeniyle pahalı olabilecek ilk etapta olması gerektiği gibi yapın.

Belirli bir sorunu çözmek için kod oluşturmak kolaydır. Daha sonra güvenli bir şekilde yapılacak değişikliklere izin verirken bu sorunu gideren bir kod oluşturmak için daha karmaşıktır. SOLID, kodu daha iyi yapan bir dizi uygulama sağlar.

Hangisinin doğru olduğuna gelince: Üçü de. Hepsi tek bir sorumluluk kullanmanın yararı ve bunu kullanmanızın nedenidir.

Ne demek istediklerini gelince:

• Daha iyi bakım, bunun daha kolay olduğu ve sık sık değişmediği anlamına gelir. Daha az kod olduğundan ve bu kod belirli bir şeye odaklandığından, sınıfla ilgili olmayan bir şeyi değiştirmeniz gerekirse, sınıfın değişmesi gerekmez. Ayrıca, sınıfı değiştirmek istediğinizde, genel arayüzü değiştirmek zorunda olmadığınız sürece, yalnızca o sınıf için endişelenmeniz gerekir, başka bir şey yoktur.
• Kolay test, daha az test, daha az kurulum demektir. Sınıfta o kadar hareketli parça yoktur, bu nedenle sınıfta olası arızaların sayısı daha küçüktür ve bu nedenle test etmeniz gereken daha az vaka vardır. Kurulacak daha az özel alan / üye olacak.
• Yukarıdaki ikisinden dolayı daha az değişen ve daha az başarısız olan bir sınıf alırsınız ve bu nedenle daha sağlamdır.

Prensibi izleyerek bir süre kod oluşturmaya çalışın ve daha sonra bazı değişiklikleri yapmak için bu kodu tekrar ziyaret edin. Sağladığı büyük avantajı göreceksiniz.

Her bir sınıfa aynısını yaparsınız ve hepsi de SRP'ye uyan daha fazla sınıfa girersiniz. Yapıları bağlantılar açısından daha karmaşık hale getirir, ancak her bir sınıfın sadeliği onu haklı çıkarır.

İşte benim görüşüme göre, Tek Sorumluluk İlkesinin iyi bir uygulama olduğu iddiasını destekleyen argümanlar. Ayrıca, daha ayrıntılı nedenleri okuyabileceğiniz ve benimkinden daha belirgin olan diğer literatürlere bağlantılar da veriyorum:

• Daha iyi bakım : İdeal olarak, sistemin bir işlevselliğinin değişmesi gerektiğinde, değiştirilmesi gereken bir ve yalnızca bir sınıf olacaktır. Sınıflar ve sorumluluklar arasında net bir eşleştirme, projeye dahil olan herhangi bir geliştiricinin hangi sınıf olduğunu tanımlayabildiği anlamına gelir. (@ MaciejChałapuk'un belirttiği gibi, bkz. Robert C. Martin, "Temiz Kod" .)

• Daha kolay test : İdeal olarak, sınıflar mümkün olduğunca az ortak arayüze sahip olmalı ve testler yalnızca bu ortak arayüze hitap etmelidir. Net bir şekilde test edemiyorsanız, sınıfınızın birçok bölümü özel olduğu için, bu, sınıfınızın çok fazla sorumluluğa sahip olduğunun ve daha küçük alt sınıflara ayırmanız gerektiğinin açık bir işaretidir. Lütfen bunun 'herkese açık' veya 'özel' sınıf üyesi olmayan diller için de geçerli olduğunu unutmayın; Küçük bir ortak arayüze sahip olmak, sınıfın hangi bölümlerini kullanması gerektiğini müşteri koduna göre açık bir şekilde ifade eder. (Daha fazla bilgi için Kent Beck, "Test Odaklı Geliştirme" kısmına bakın.)

• Sağlam kod : Kodunuz iyi yazılmış olduğundan daha fazla veya daha az başarısız olmaz; ancak, tüm kodlar gibi, asıl amacı makine ile değil, diğer geliştiricilerle iletişim kurmaktır (bkz. Kent Beck, "Uygulama Kalıpları" , Bölüm 1). ve bir hatayı keşfetme ve çözme arasında daha az zaman geçecektir.

Çok sayıda neden var, ancak sevdiğim şey, UNIX'in ilk programlarının çoğunun kullandığı yaklaşım: Bir şeyi iyi yapın. Bunu bir şeyle yapmak yeterince zor ve yapmaya çalıştığınız şeyleri zorlaştırmak zorlaşıyor.

Diğer bir sebep de yan etkileri sınırlamak ve kontrol etmektir. Kombinasyon kahve makinemin kapı açıcısını çok sevdim. Ne yazık ki, ziyaretçilerim varken kahve genellikle taşardı. Geçen gün kahve içtikten sonra kapıyı kapatmayı unuttum ve birisi çaldı.

Psikolojik açıdan bakıldığında, bir seferde yalnızca birkaç şeyi takip edebilirsiniz. Genel tahminler yedi artı veya eksi ikidir. Bir sınıf birden fazla şey yaparsa, hepsini bir kerede takip etmeniz gerekir. Bu, ne yaptığınızı izlemek için yeteneğinizi azaltır. Bir sınıf üç şey yaparsa ve bunlardan sadece birini istiyorsan, sınıfla ilgili bir şey yapmadan önce olayları takip etme yeteneğini tüketebilirsin.

Birden çok şey yapmak, kod karmaşıklığını arttırır. En basit kodun ötesinde, artan karmaşıklık böcek olasılığını artırır. Bu açıdan, sınıfların mümkün olduğunca basit olmasını istersiniz.

Bir şey yapan bir sınıfı test etmek çok daha kolaydır. Her test için sınıfın yaptığı veya gerçekleşmeyen ikinci şeyin olduğunu doğrulamak zorunda değilsiniz. Ayrıca bozuk koşulları düzeltmeniz ve bu testlerden biri başarısız olduğunda tekrar test etmeniz gerekmez.

Çünkü yazılım organik. Gereksinimler sürekli değişir, bu yüzden bileşenleri mümkün olduğunca az baş ağrısı ile manipüle etmeniz gerekir. SOLID ilkelerini takip etmeyerek, somut olarak belirlenmiş bir kod tabanına sahip olabilirsiniz.

Yük taşıyan beton duvarlı bir ev düşünün. Bu duvarı herhangi bir destek olmadan açtığınızda ne olur? Ev muhtemelen çökecek. Yazılımda bunu istemiyoruz, bu nedenle uygulamaları çok fazla zarara neden olmadan kolayca taşıyabileceğiniz / değiştirebileceğiniz / değiştirebileceğiniz şekilde yapılandırıyoruz.

Ben düşünce izleyin: 1 Class = 1 Job.

Bir Fizyoloji Analojisi Kullanmak: Motor (Sinir Sistemi), Solunum (Akciğerler), Sindirim (Mide), Koku (Gözlem), vb. ilgili alt sistemlerinin her birinin çalışma şekli ya da bir uç nokta alt sistemi olup olmadıkları ve bir parmağını kaldırmak ya da saç folikülü yetiştirmek gibi yalnızca 1 görevi yerine getirmeleri.

Bir işçi yerine yönetici olarak hareket ettiği gerçeğini karıştırmayın. Sonunda bazı işçiler, bir işlemin kendisi tarafından yürütülemeyecek kadar karmaşık hale geldiklerinde sonunda Müdür'e terfi etti.

Deneyimlediklerimin en karmaşık kısmı, bir Sınıfı Operatör, Süpervizör veya Yönetici süreci olarak ne zaman atayacağımı bilmektir. Ne olursa olsun, 1 sorumluluk (Operatör, Süpervizör veya Yönetici) işlevini gözlemlemeniz ve belirtmeniz gerekecektir.

Bir Sınıf / Nesne bu tür rollerden birden fazlasını gerçekleştirdiğinde, genel işlemin performans sorunları yaşamaya başlayacağını veya şişe boyunlarını işleyeceğini göreceksiniz.

Özellikle Tek Sorumluluk gibi önemli bir ilkeyle, şahsen insanların bu ilkeyi benimsemelerinin birçok nedeni olduğunu umuyorum.

Bu nedenlerden bazıları şunlar olabilir:

• Bakım - SRP, bir sınıftaki sorumluluğun değiştirilmesinin diğer sorumlulukları etkilememesini sağlayarak bakımı kolaylaştırır. Bunun nedeni, eğer her bir sınıfın yalnızca bir sorumluluğu varsa, bir sorumluluğa yapılan değişikliklerin diğer sorumluluklardan ayrı tutulmasıdır.
• Test Etme - Bir sınıfın bir sorumluluğu varsa, bu sorumluluğun nasıl test edileceğini bulmayı çok kolaylaştırır. Bir sınıfın birden fazla sorumluluğu varsa, doğru olanı test ettiğinizden ve testin sınıfın sahip olduğu diğer sorumluluklardan etkilenmediğinden emin olmalısınız.

Ayrıca, SRP'nin bir SOLID ilkeleri paketi ile geldiğini de unutmayın. SRP'ye uymak ve gerisini görmezden gelmek, ilk başta SRP yapmamak kadar kötü. Bu nedenle, SRP'yi kendi başınıza değil, tüm SOLID ilkeleri bağlamında değerlendirmelisiniz.

Bu ilkelerin önemini anlamanın en iyi yolu ihtiyaç duymaktır.

Acemi bir programcı olduğum zaman, tasarım konusunda fazla düşünmedim, hatta tasarım desenlerinin var olduğunu bile bilmiyordum. Programlarım büyüdükçe, bir şeyi değiştirmek, diğer birçok şeyi değiştirmek anlamına geliyordu. Hataları takip etmek zordu, kod çok büyük ve tekrarlıydı. Nesne hiyerarşisinde pek bir şey yoktu, her yerdeydi. Yeni bir şey eklemek veya eski bir şeyi kaldırmak, programın diğer bölümlerinde hatalara yol açar. Git figürü.

Küçük projelerde önemli olmayabilir, ancak büyük projelerde işler çok kabus olabilir. Daha sonra tasarım patlayıcılarının konseptleriyle karşılaştığımda kendime "ah ya, bunu yapmak o zamanları çok daha kolay hale getirecekti" dedim.

İhtiyaç doğana kadar tasarım kalıplarının önemini gerçekten anlayamazsınız. Kalıplara saygı duyuyorum çünkü deneyimlerimden kod bakımını kolaylaştırdığını ve kodun sağlam olduğunu söyleyebilirim.

Ancak, tıpkı sizin gibi, hala "kolay test" konusunda kararsızım çünkü ünite testine henüz girmedim.

Cevap, diğerlerinin de belirttiği gibi, hepsi doğrudur ve hepsi birbiriyle beslenir, test edilmesi daha kolay hale getirir, bakımı daha kolay hale getirir kodları daha sağlam hale getirir, bakımı daha kolay hale getirir ...

Bunların hepsi kaynatılarak temel bir prensip - kod, işi yapabilmek için gereken kadar küçük ve gereken kadar az olmalıdır. Bu, bir uygulama, dosya veya bir işlev için olduğu kadar bir sınıf için de geçerlidir. Bir kod parçasının yaptığı şey ne kadar çoksa, anlamak, sürdürmek, genişletmek veya test etmek zorlaşır.

Bence tek kelimeyle özetlenebilir: kapsam. Yapıtların kapsamına yakından dikkat edin, bir uygulamada herhangi bir noktada kapsam dahilindeki şeyler ne kadar azsa o kadar iyidir.

Genişletilmiş kapsam = daha karmaşıklık = işlerin yanlış gitmesi için daha fazla yol.

Bir sınıf çok büyükse, sürdürmek, test etmek ve anlamak zorlaşır, diğer cevapların da bu iradeyi kapsaması gerekir.

Bir sınıfın problemsiz olarak birden fazla sorumluluğu olması mümkündür, ancak yakında çok karmaşık sınıflarla ilgili problemlere çarpıyorsunuz.

Ancak basit bir “tek sorumluluk” kuralına sahip olmak, yeni bir sınıfa ihtiyaç duyduğunuzda bilmenizi kolaylaştırır .

Bununla birlikte, “sorumluluğu” tanımlamak zordur, “uygulamanın belirttiği her şeyi yap” anlamına gelmez, asıl beceri, sorunu “sorumluluk” un küçük birimlerine nasıl ayıracağını bilmektir.