Dahili Değerler, Bölüm 2: Sipariş ve Ayırma

semaver

New member


  1. Dahili Değerler, Bölüm 2: Sipariş ve Ayırma

Bir yazılım sisteminin dahili değerleri de sipariş ve ayırmayı içerir. Peki bileşenler ve arayüzler nasıl kesilir? Ve sorumluluklar bileşenler ve arayüzler üzerinde nasıl yansıtılır?



Muz ve goril



Kim bilmiyor, A Z'den akla gelebilecek tüm sorumlulukları yırtan aşırı kilolu bileşenler? Muz istiyorsanız, her zaman gorilini onunla birlikte alın. Bu bileşenlerin değişimi stresli bir macera tatilinden sonra hissediyor. Anlama hakkında bile konuşamazsınız.

Endişelerin ayrılması ve tek sorumluluk


Bu bağlamda geçerli olan iki ilke, sorumlulukların ayrılması ve bir sorumluluk bileşenidir.

  • Örneğin, birincisi, uzman mantığı, altyapı mantığının, yardımcı işlevlerin asla tek bir bileşende birleştirilmesi gerektiği anlamına gelir. Buna izin verilirse, bir yön değiştirilirse tüm bileşene her zaman dokunulmalıdır. Buna ek olarak, bu aynı zamanda bileşen kullanıcıları için değişim ihtiyaçlarına da yol açar.
  • İkincisi, her bileşenin tam olarak sorumluluk alması gerektiği anlamına gelir. Ve bu nedenle bu sorumluluk sadece yarısını değil, tam olarak yerine getirilmelidir.
Mimar/geliştirici her iki prensibi de tutarlı bir şekilde kullanıyorsa, ortaya çıkan sistemlerin hem anlaşılması daha kolaydır hem de daha kolay değiştirilebilir.

İyi kesim





Dahili Değerler- Seri




Bileşenler için geçerli olanlar da arayüzler için mantıklıdır. Şişmiş maksimum arayüzler, bir uçak pilot kabinindeki sayısız kontrol gibi davranır, yani tamamen karışıktır. Bu yüzden Corba'nın Yineleyicisi sınıfında düzinelerce yöntem vardı. Bu bolluk geliştiriciler yaratır. Daha sofistike görevler için diğer net arayüzlere ek olarak, normal kullanım için bazı yöntemlere sahip bir yineleyici sınıfı en iyi yaklaşımdır.

Bu nedenle her arayüzün doğranmış rolü veya sorumluluğu vardır. En karmaşık bileşenler de birkaç arayüze sahip olabilir.

Kütle bildirimleri, birçok parametrenin karışıklığı olan yöntemlerle arayüzleriniz varsa, kötü iç kalite konusunda net bir farkındalık yaratabilirsiniz.

Sadece kod değil


Ve bu analizler kavramsal tasarımda veya gereksinimlerin belirtilmesinde de gerçekleştirilebilir. Bir UML sınıfı yalnızca ikincisini kaydırdıktan sonra veya yanal belgelerin bir gereksinimi içeriyorsa, sorumlulukların ayrılması ile iyi sipariş edilmediği garanti edilir.

Gösterge ve test yok


Ancak, “sipariş ve ayırma” sadece bir kalite göstergesidir, test yoktur.

Çok küçük sorumluluklar keserseniz, minimum bileşenlerden oluşan bir okyanus oluşturulur. Bu nedenle karmaşıklık, bileşenlere karşılıklı bağımlılıklarında gittikçe daha fazla hareket eder. Bu nedenle sonuç, en aşırı formunda bir ovma olarak da tanımlanabilen yoğun bir bileşen örgüsüdür. Bu durumda, bir değişiklik birçok bileşeni etkileyebilir. Bu özellikle çok ince ayrıntılı mikro hizmetlere dayanan mimariler riskidir.


()




Ne yazık ki, bu bağlantı artık geçerli değil.

Boşa harcanan eşyalara olan bağlantılar, 7 günlük daha büyükse veya çok sık çağrılmışsa gerçekleşmez.


Bu makaleyi okumak için bir Haberler+ paketine ihtiyacınız var. Şimdi yükümlülük olmadan bir hafta deneyin – yükümlülük olmadan!
 
Üst