Doğru yazılım ayrıştırması

hiyerarşik ayrıştırma

Başvurunuz için sınıf yazmaya asla hemen başlamamalısınız. Önce tasarlanması gerekiyor. Tasarım, düşünceli bir mimari ile bitmelidir. Ve bu mimariyi elde etmek için, sistemi tutarlı bir şekilde ayrıştırmanız gerekir.

Ayrıştırma hiyerarşik olarak yapılmalıdır - önce sistem, işleyişini en genel biçimde tanımlayan büyük işlevsel modüllere / alt sistemlere bölünür. Daha sonra ortaya çıkan modüller daha detaylı analiz edilir ve alt modüllere veya nesnelere bölünür.

Nesneleri seçmeden önce, sistemi en azından zihinsel olarak temel anlamsal bloklara bölün. Küçük uygulamalarda bunu yapmak genellikle çok kolaydır: sistem önce alt sistemlere / paketlere bölündüğü ve paketler sınıflara ayrıldığı için birkaç hiyerarşi seviyesi yeterlidir.

Bu fikir göründüğü kadar önemsiz değil. Örneğin, Model-View-Controller (MVC) gibi yaygın bir "mimari modelin" özü nedir?

Her şey sunumu iş mantığından ayırmakla ilgilidir . İlk olarak, herhangi bir kullanıcı uygulaması iki modüle ayrılır - biri iş mantığının kendisinin uygulanmasından sorumludur (Model), ikincisi ise kullanıcıyla etkileşimden sorumludur (Kullanıcı Arayüzü veya Görünüm).

Ardından, modüllerin bir şekilde etkileşime girmesi gerektiği ortaya çıktı, bunun için görevi modüllerin etkileşimini yönetmek olan bir Kontrolör eklediler. Ayrıca MVC'nin mobil (klasik) sürümünde, View'in modelden olayları alabilmesi ve görüntülenen verileri gerçek zamanlı olarak değiştirebilmesi için Observer modeli eklenir.

Sistemin en büyük bileşenlere ilk bölümünün bir sonucu olarak elde edilen tipik üst düzey modüller tam olarak şunlardır:

• İş mantığı;
• Kullanıcı arayüzü;
• Veri tabanı;
• Mesajlaşma sistemi;
• Nesne kabı.

İlk bölme genellikle tüm uygulamayı 2-7'ye (en fazla 10 parça) böler. Daha fazla parçaya ayırırsak, onları gruplandırma isteği olacak ve yine 2-7 üst düzey modül alacağız.

fonksiyonel ayrıştırma

Modüllere/alt sistemlere ayırma en iyi şekilde sistemin çözdüğü görevlere göre yapılır . Ana görev, birbirinden bağımsız olarak otonom olarak çözülebilen/gerçekleştirilebilen bileşen alt görevlerine bölünmüştür.

Her modül, bazı alt görevleri çözmekten ve ilgili işlevi yerine getirmekten sorumlu olmalıdır . İşlevsel amaca ek olarak modül, işlevini yerine getirmesi için gerekli olan bir dizi veri ile de karakterize edilir, yani:

Modül = İşlev + Çalıştırmak için gerekli veriler.

Modüllere ayrıştırma doğru yapılırsa, diğer modüllerle (diğer işlevlerden sorumlu) etkileşim minimum düzeyde olacaktır. Olabilir, ancak yokluğu modülünüz için kritik olmamalıdır.

Bir modül keyfi bir kod parçası değil, belirli bir göreve çözüm sağlayan ve ideal olarak bağımsız veya başka bir ortamda çalışabilen ve yeniden kullanılabilen, işlevsel olarak anlamlı ve eksiksiz ayrı bir program birimidir (alt program). Modül, bir tür "davranış ve gelişimde göreli bağımsızlığa sahip bütünlük" olmalıdır. (Christopher İskender)

Bu nedenle yetkin ayrıştırma, her şeyden önce sistem fonksiyonlarının ve bu fonksiyonları gerçekleştirmek için gerekli verilerin analizine dayanır . Bu durumda işlevler, nesne olmadıkları için sınıf işlevleri ve modüller değildir. Bir modülde yalnızca birkaç sınıfınız varsa, o zaman aşırıya kaçmışsınız demektir.

Güçlü ve zayıf bağlantı

Modülerleştirme ile aşırıya kaçmamak çok önemlidir. Yeni başlayana yekpare bir Yay uygulaması verirseniz ve ondan onu modüllere ayırmasını isterseniz, o zaman her bir Yay Fasulyesini ayrı bir modüle çıkaracak ve işinin bittiğini düşünecektir. Ama değil.

Ayrıştırma kalitesinin ana kriteri, modüllerin görevlerini çözmeye nasıl odaklandıkları ve bağımsız olduklarıdır.

Bu genellikle şu şekilde formüle edilir: "Ayrıştırma sonucunda elde edilen modüller, maksimum dahili olarak eşlenik (yüksek iç kohezyon) ve minimum düzeyde birbirleriyle bağlantılı (düşük harici bağlantı) olmalıdır."

Modül içinde Yüksek Uyum, yüksek uyum veya "uyum", modülün dar bir sorunu çözmeye odaklandığını ve heterojen işlevleri veya ilgisiz sorumlulukları yerine getirmekle meşgul olmadığını gösterir.

Uyum, modül tarafından gerçekleştirilen görevlerin birbiriyle ilişkili olma derecesini karakterize eder.

High Cohesion'un bir sonucu, Tek Sorumluluk İlkesi'dir - herhangi bir nesnenin/modülün yalnızca bir sorumluluğu olması ve onu değiştirmek için birden fazla neden olmaması gerektiği şeklindeki beş SOLID ilkesinden ilki .

Low Coupling , gevşek bağlantı, sistemin bölündüğü modüllerin, mümkünse, bağımsız veya gevşek bir şekilde birbirine bağlı olması gerektiği anlamına gelir. Etkileşim kurabilmeli, ancak aynı zamanda birbirleri hakkında mümkün olduğunca az şey bilmeliler.

Her modülün diğer modülün nasıl çalıştığını, hangi dilde yazıldığını ve nasıl çalıştığını bilmesine gerek yoktur. Çoğu zaman, bu tür modüllerin etkileşimini düzenlemek için, bu modüllerin içine yüklendiği belirli bir kap kullanılır.

Uygun tasarımla, bir modülü değiştirirseniz diğerlerini düzenlemek zorunda kalmazsınız veya bu değişiklikler minimum düzeyde olur. Bağlantı ne kadar gevşekse, programı yazmak/anlamak/genişletmek/onarmak o kadar kolay olur.

İyi tasarlanmış modüllerin aşağıdaki özelliklere sahip olması gerektiğine inanılmaktadır:

• İşlevsel bütünlük ve eksiksizlik - her modül bir işlevi uygular, ancak bunu iyi ve eksiksiz uygular, modül, işlevini gerçekleştirmek için bağımsız olarak tam bir işlem seti gerçekleştirir.
• Bir giriş ve bir çıkış - girişte, program modülü belirli bir başlangıç ​​​​verisi seti alır, anlamlı işleme gerçekleştirir ve bir sonuç verisi seti döndürür, yani standart IPO ilkesi uygulanır - giriş -\u003e işlem -\u003e çıktı.
• Mantıksal bağımsızlık - program modülünün çalışmasının sonucu yalnızca ilk verilere bağlıdır, ancak diğer modüllerin çalışmasına bağlı değildir.
• Diğer modüllerle zayıf bilgi bağlantıları - mümkünse modüller arasındaki bilgi alışverişi en aza indirilmelidir.

Yeni başlayan birinin modüllerin bağlantısını nasıl daha da azaltacağını anlaması çok zordur. Kısmen bu bilgi, kısmen - akıllı kitapları okuduktan sonra deneyimle gelir. Ancak mevcut uygulamaların mimarilerini analiz etmek en iyisidir.

Kalıtım yerine kompozisyon

Yetkin ayrıştırma bir tür sanattır ve çoğu programcı için zor bir iştir. Burada basitlik yanıltıcıdır ve hatalar maliyetlidir.

Ayrılmış modüllerin birbiriyle güçlü bir şekilde birleştiği ve bağımsız olarak geliştirilemeyeceği görülür. Veya her birinin hangi işlevden sorumlu olduğu net değil. Benzer bir sorunla karşılaşırsanız, büyük olasılıkla modüllere ayırma yanlış yapılmıştır.

Her bir modülün oynadığı rolün her zaman net olması gerekir . Ayrıştırmanın doğru yapıldığının en güvenilir kriteri, modüllerin uygulamanın geri kalanından izole olarak kullanılabilen (ve dolayısıyla yeniden kullanılabilen) bağımsız ve değerli alt programlar olup olmadığıdır.

Bir sistemi ayrıştırırken, kendinize şu soruları sorarak kalitesini kontrol etmeniz önerilir: "Her modül hangi görevi yerine getiriyor?", "Modüllerin test edilmesi ne kadar kolay?", "Modülleri kendi başlarına kullanmak mümkün mü? veya başka bir ortamda?" başkalarını etkiler mi?"

Modülleri mümkün olduğunca özerk tutmaya çalışmalısınız . Daha önce de belirtildiği gibi, bu, uygun ayrıştırma için önemli bir parametredir . Bu nedenle, modüller başlangıçta zayıf bir şekilde birbirine bağımlı olacak şekilde gerçekleştirilmelidir. Eğer başardıysanız, o zaman harikasınız.

Değilse, o zaman burada da her şey kaybolmaz. Alt sistemler arasındaki bağlantıları daha da küçültmenize ve zayıflatmanıza izin veren bir dizi özel teknik ve kalıp vardır. Örneğin, MVC söz konusu olduğunda, bu amaç için Observer modeli kullanılmıştır, ancak başka çözümler de mümkündür.

Ayrıştırma tekniklerinin “mimarın araç setini” oluşturduğu söylenebilir. Sadece tüm alt sistemlerden bahsettiğimizi anlamak ve hiyerarşinin tüm seviyelerinde , yani sadece sınıflar arasında değil, aynı zamanda her hiyerarşik seviyedeki modüller arasında da bağlantıyı zayıflatmak gerekiyor .