Geliştirme aşamasında izlememiz gereken birkaç tasarım ilkesi
pengdai Java Ar-Ge Birliği
Eser sahibi: pengdai
1. Geliştirme ilkeleri
S: Tek sorumluluk SRP
O: Açık ve kapalı prensip OCP
L: Richter ikame ilkesi LSP
I: Arayüz izolasyon yasası
D: DIP'yi ters çevirme ilkesine güvenin
Bileşim / toplama yeniden kullanım ilkesi
Dimit Yasası
Yazılım geliştirmede, öncekiler yazılım sistemlerinin tasarımı ve geliştirilmesine yönelik bazı ilke ve modelleri özetlemişlerdir.Geliştirme için hangi dil kullanılırsa kullanılsın, sistem tasarımı ve geliştirmemiz için rehberlik edeceklerdir. Bu makale temel olarak bu ortak ilkeleri özetleyecek ve anlamlarını ayrıntılı olarak açıklayacaktır.
Temel nesne yönelimli ilkeler (katı) beştir, ancak bu beşe ek olarak Dimit kuralı ve bileşik yeniden kullanım ilkesi vb. Vardır, bu nedenle ortak makalelerde altı veya Yedi ilke; ayrıca internette yer alan ilgili diğer bazı kitapları ve ilkeleri de vereceğim;
İki, S tek sorumlu SRP
Tek Sorumluluk İlkesi, bir sınıf, tek bir şeyi yapmak en iyisidir, sadece bir tek şey onun değişmesine neden olur. Tek sorumluluk ilkesi, nesne yönelimli düşük bağlantı ve yüksek uyum ilkesinin bir uzantısı olarak görülebilir Sorumluluk, uyumu iyileştirmek ve değişim nedenini azaltmak için değişimin nedeni olarak tanımlanır.
1. Tanım
Bir nesne yalnızca tek bir sorumluluk içermelidir ve sorumluluk tamamen bir sınıfta özetlenmiştir. (Her nesnenin tek bir sorumluluğu olmalıdır ve bu sorumluluk tamamen sınıf tarafından özetlenmelidir.), Yani yeniden tanımlanır ve sınıfı değiştirmek için tek bir neden vardır.
2. İlke analizi
Bir sınıf, bir modül kadar büyük veya bir yöntem kadar küçük olabilir. Ne kadar çok sorumluluğu varsa, yeniden kullanılması o kadar az olasıdır. Bir sınıfın çok fazla sorumluluğu varsa, bu sorumlulukları bir araya getirmekle eşdeğerdir. Sorumluluklar değiştiğinde, diğer sorumlulukların işleyişini etkileyebilir.
Sınıf sorumlulukları temel olarak iki yönü içerir: Veri sorumluluğu ve davranışsal sorumluluk , Veri sorumluluğu öznitelikleri aracılığıyla somutlaşır ve davranış sorumluluğu yöntemleri aracılığıyla somutlaşır.
Tek sorumluluk ilkesi, yüksek uyum ve düşük bağlantı elde etmek için bir kılavuzdur. Birçok kod yeniden düzenleme tekniğinde bulunabilir. Uygulanması en basit ama en zor ilkedir. Tasarımcıların sınıfın farklı sorumluluklarını keşfetmesini gerektirir ve Bunları ayırmak için, keşif sınıfının çoklu sorumlulukları, tasarımcıların güçlü analiz ve tasarım yeteneklerine ve ilgili yeniden düzenleme deneyimine sahip olmasını gerektirir.
3. Avantajlar
Sınıf karmaşıklığını azaltın, sınıf sorumlulukları açık ve nettir. Örneğin, veri sorumlulukları ve davranış sorumlulukları açık ve nettir;
Sınıfların okunabilirliğini ve sürdürülebilirliğini geliştirin;
Değişikliğin neden olduğu risk azaltılır ve değişiklik kaçınılmazdır.Arayüzün tek sorumluluğu iyi yapılırsa, bir arabirim değişikliği yalnızca ilgili sınıfı etkileyecek ve diğer arabirimler üzerinde hiçbir etkisi olmayacaktır.Bu, sistemin ölçeklenebilirliğini ve sürdürülebilirliğini etkileyecektir. Çok büyük yardım.
Not: Tek sorumluluk ilkesi, arayüz veya sınıf tasarımının makul olup olmadığını ölçmek için "sorumluluk" veya "değişim nedeni" kullanarak program yazmak için bir standart ortaya koyar, ancak "sorumluluk" ve "değişim nedeni" için belirli bir standart yoktur. Hangi sorumluluklardan sorumlusunuz? Bu sorumluluklar nasıl geliştirilir? İyileştirmeden sonra bir arayüz veya sınıf var mı? Bunların gerçek durumdan değerlendirilmesi gerekir. Projeden projeye ve çevreden çevreye değişir.
4. Örnekler
SpringMVC'de Varlık, DAO, Hizmet, Denetleyici, Util vb. Ayrımı.
3. O Açık ve Kapalı Prensip OCP
Açık-Kapalı İlke, OCP genişletmeye açıktır ve değişiklik için kapalıdır (tasarım modellerinin temel ilkesi)
1. Tanım
Bir yazılım varlığı (sınıflar, modüller ve işlevler gibi) genişletme için açık ve değişiklik için kapalı olmalıdır. Bir sistem veya modülde genişletmeye açık ve modifikasyon için kapalı olduğu anlamına gelir. Kaynak kodunu değiştirmeden işlevlerinizi genişletmek iyi bir sistemdir. Açma ve kapama ilkesini gerçekleştirmenin anahtarı soyutlamadır.
2. İlke analizi
Yazılım varlığının talep nedeniyle değişmesi gerektiğinde, mevcut kodu değiştirmek yerine, yazılım için yeni talebi karşılayacak yeni davranışlar sağlayacak şekilde mevcut yazılım varlığını genişletmeye çalışın, böylece değişen yazılım belirli bir düzeyde uyarlanabilirliğe sahip olur. Ve esneklik. Mevcut yazılım modülleri, özellikle en önemli soyut katman modülleri, artık değiştirilemez, bu da değişen yazılım sistemine belirli bir düzeyde istikrar ve süreklilik sağlar.
Aç-kapa ilkesinin gerçekleştirilmesinin anahtarı soyutlamadır: "aç-kapa" ilkesinde, soyut sınıfın veya arayüzün değiştirilmesine izin verilmez ve somut uygulama sınıfının genişletilmesine izin verilir Soyut sınıf ve arayüz "aç-kapat" prensibindedir. Burada son derece önemli bir rol oynar .. Yani değişebilecek gereksinimleri tahmin etmek ve tüm olası bilinen uzantıları öngörmek .. Yani burada anahtar "soyutlama"!
Kapalı değişkenlik ilkesi: sistemin değişken faktörlerini bulun ve onu kapsülleyin. Bu, "aç-kapa" ilkesinin en iyi gerçekleştirilmesidir. Değişkenlerinizi birden çok sınıfa koymayın veya programın her köşesine dağıtmayın. Değişken faktörleri toplamalısınız ... ve kullandığınız değişken faktörleri toplamamalısınız. En iyi çözüm, değişkenlerinizi bloklar halinde kaplamaktır! Süper büyük sınıfların, süper uzun sınıfların ve süper uzun yöntemlerin ortaya çıkmasından kaçının !! Programınıza sanatsal bir hava katın ve programı sanatsal bir hedef haline getirin!
3. Örnekler
Tasarım modundaki hem şablon yöntem modu hem de gözlemci modu, açma ve kapama ilkesinin mükemmel tezahürleridir.
Dört, L Richter ikame prensibi LSP
Liskov İkame Prensibi, LSP: Bir temel sınıfın ortaya çıkabildiği her yerde, alt sınıflar da ortaya çıkabilir; bu fikir, kalıtım mekanizması üzerinde bir kısıtlama olarak ifade edilir.Yalnızca alt sınıf, temel sınıfının yerini alabildiğinde, sistemin çalıştığı garanti edilebilir. Alt sınıfların belirlenmesi, kalıtımın ve yeniden kullanımın sağlanmasının temelidir.
1. Tanım
İlk tanımlama yöntemi nispeten katıdır: eğer S tipindeki her o1 nesnesi için, T tipinde bir o2 nesnesi varsa, böylece T ile tanımlanan tüm P programları, o2 ile tüm o1 nesneleriyle değiştirilir, ardından P programı Davranışta herhangi bir değişiklik yoktur, bu durumda S tipi, T türünün bir alt türüdür.
İkinci tanım yönteminin anlaşılması daha kolaydır: temel sınıfa (ana sınıf) yapılan tüm referanslar, alt sınıflarının nesnelerini şeffaf bir şekilde kullanabilmelidir. Diğer bir deyişle, alt sınıf, temel sınıfın görünebileceği yerin yerini alabilmelidir. Alt sınıflar, temel sınıfa yeni davranışlar da ekleyebilir.
Richter ikame ilkesi, Amerika Birleşik Devletleri'ndeki ilk kadın bilgisayar bilimi doktoru olan 2008 Turing Ödülü sahibi, MIT profesörü Barbara Liskov ve Carnegie Mellon Üniversitesi profesörü Jeannette Wing tarafından 1994 yılında önerildi. Orijinal metin aşağıdaki gibidir: q (x), T türündeki x nesneleri hakkında kanıtlanabilir bir özellik olsun. O zaman q (y), Swhere S türündeki y nesneleri için doğru olmalıdır S, T'nin bir alt türüdür.
2. İlke analizi
Bu, temel kategori ile alt kategori arasındaki ilişkiyle ilgilidir. Yalnızca bu ilişki mevcut olduğunda, Richter ikame ilkesi mevcuttur. Bir kare bir dikdörtgendir, Liskov ikamesi ilkesini anlamanın klasik bir örneğidir.
Richter İkame İlkesi popüler bir şekilde ifade edilebilir: Temel sınıf nesnesi yazılımda kullanılabiliyorsa, alt sınıf nesnesi kullanılmalıdır. Tüm temel sınıfları alt sınıflarıyla değiştirin, program herhangi bir hata veya istisna üretmez, bunun tersi doğru olmaz, bir yazılım varlığı bir alt sınıf kullanıyorsa, o zaman temel sınıfı kullanamayabilir.
Richter İkame İlkesi, açma ve kapama ilkesini gerçekleştirmenin önemli yollarından biridir.Alt sınıf nesnesi, temel sınıf nesnesinin kullanıldığı her yerde kullanılabileceğinden, temel sınıf türü, nesneyi programda ve ardından çalışma zamanında tanımlamak için mümkün olduğunca kullanılmalıdır. Alt sınıf türünü belirleyin ve üst sınıf nesnesini alt sınıf nesnesiyle değiştirin.
Beş, arayüz izolasyon yasası
(Arayüz Ayrım Prensibi, ISL): İstemci ihtiyaç duymadığı arayüzlere güvenmemelidir. (Bu yasa Dimit yasası ile bağlantılıdır)
1. Tanım
İstemci, ihtiyaç duymadığı arayüzlere güvenmemelidir.
Başka bir tanımlama yöntemi: Bir arabirim çok büyük olduğunda, bazı küçük arabirimlere bölünmesi gerekir ve arabirimi kullanan istemcinin yalnızca onunla ilgili yöntemleri bilmesi gerekir.
Bu tanımdaki arayüzün, tanımlanan yöntemi ifade ettiğini unutmayın. Örneğin, belirli bir sınıfın public metodu dışarıdan çağrılır. Bu yöntem, dışarıya arayüzdür.
2. İlke analizi:
(1) Arayüz izolasyonu ilkesi, tek bir genel arayüz yerine birden çok özel arayüzün kullanılması anlamına gelir. Her arayüz görece bağımsız bir rol üstlenmeli, ne fazla ne de az, yapılmaması gereken şeyleri yapmamalı ve yapılması gerekenleri yapmalıdır.
Bir arabirim yalnızca bir rolü temsil eder ve her rolün kendine özgü arabirimi vardır. Şu anda bu ilkeye "rol yalıtımı ilkesi" denilebilir.
Arayüz sadece müşterinin ihtiyaç duyduğu davranışları sağlar, yani gerekli yöntemler ve istemcinin ihtiyaç duymadığı davranışlar gizlidir.Müşteriye büyük bir toplam arayüz yerine mümkün olduğu kadar küçük tek bir arayüz sağlanmalıdır.
(2) Bir arayüzü bölmek için arayüz izolasyon prensibini kullanırken, öncelikle tek sorumluluk prensibi yerine getirilmelidir, bir arayüzde bir grup ilgili operasyon tanımlanır ve yüksek uyumun sağlanması öncülü altında arayüzde ne kadar az yöntem olursa o kadar iyidir.
(3) Sistem tasarlanırken kişiye özel servisler kullanılabilir, yani farklı istemcilere farklı genişlik ve dar arayüzler sağlanır ve kullanıcının ihtiyaç duymadığı davranışlar gizlenirken sadece kullanıcının istediği davranışlar sağlanır.
Altı, D, DIP ters çevirme ilkesine bağlıdır
Bağımlılık-Tersine Çevirme İlkesi, belirli bir uygulamaya değil, soyutlamaya dayanır.Özellikle, yüksek seviyeli modül, düşük seviyeli modüle bağlı değildir ve her ikisi de soyutlamaya dayanır. Soyutlama somutluğa bağlı değildir, somutluk soyutlamaya bağlıdır.
1. Tanım
Yüksek seviyeli modüller, düşük seviyeli modüllere dayanmamalıdır, hepsi soyutlamaya dayanmalıdır. Soyutlama ayrıntılara bağlı olmamalı ve ayrıntılar soyutlamaya bağlı olmalıdır. Basitçe ifade etmek gerekirse, bağımlılığı tersine çevirme ilkesi, müşterinin soyut birleştirmeye güvenmesini gerektirir. İlke beyanı:
(1) Soyutlama ayrıntılara bağlı olmamalıdır; ayrıntılar soyutlamaya bağlı olmalıdır;
(2) Gerçekleştirme için değil, arayüz için programlama gereklidir.
2. İlke analizi
(1) Açma ve kapama ilkesi nesne yönelimli tasarımın amacı ise, bağımlılığı tersine çevirme ilkesi tasarım odaklı "açılma ve kapanma" ilkesine ulaşma aracıdır. En iyi "açılma ve kapanma" ilkesine ulaşmak istiyorsanız bağımlılık tersine çevirmeye uymaya çalışmalısınız. İlkeler Bağımlılık tersine çevirme ilkesinin "soyutlama" için en iyi standart olduğu söylenebilir! Kişisel olarak, bağımlılık tersine çevirme ilkesinin ikame ilkesine bir tamamlayıcı olduğunu düşünüyorum .. İkame ilkesini anlıyorsunuz ve sonra tersine çevirme ilkesini anlamalısınız. Bu çok kolay.
(2) Bağımlılığı tersine çevirme ilkesini uygulamanın yaygın yollarından biri, kodda soyut sınıfları kullanmak ve somut sınıfları yapılandırma dosyasına koymaktır.
(3) Sınıflar arası bağlantı: sıfır bağlantı ilişkisi, somut bağlantı ilişkisi, soyut bağlantı ilişkisi. Bağımlılığın tersine çevrilmesi ilkesi, müşterinin soyut bağlaşıma güvenmesini gerektirir ve soyut bir biçimde eşleştirme, bağımlılığı tersine çevirme ilkesinin anahtarıdır.
3. Örnek 1
Bu bağımlılığı tersine çevirmeyi anlamak için öncelikle nesne yönelimli tasarımdaki bağımlılık kavramını anlamamız gerekir:
Bağımlılık (Bağımlılık): Bir tür kullanım ilişkisidir, belirli bir şeyin değişmesi, o şeyi kullanan diğer şeyleri etkileyebilir ve bir şeyin başka bir şeyi kullandığını belirtmek gerektiğinde kullanılır. (A sınıfının değişmesinin B sınıfının değişmesine neden olduğu varsayılırsa, B sınıfının A sınıfına bağlı olduğu söylenir) Çoğu durumda, bağımlılık ilişkisi başka bir sınıfın nesnesini parametre olarak kullanan bir sınıfın yöntemine yansıtılır. UML'de bağımlılık ilişkisi, oklu noktalı bir çizgiyle temsil edilir ve bağımlı taraf, bağımlı tarafı gösterir.
4. Örnek 2
Bir sistem, farklı veri kaynaklarından gelen verileri birden çok biçime dönüştürebilen bir veri dönüştürme modülü sağlar.Örneğin, bir veritabanından (DatabaseSource) verileri ve bir metin dosyasından (TextSource) verileri dönüştürebilir. Dönüştürülen biçim olabilir Bir XML dosyası (XMLTransformer) veya bir XLS dosyası (XLSTransformer) vb.
Gereksinimlerdeki değişiklikler nedeniyle, sistemin yeni veri kaynakları veya yeni dosya biçimleri eklemesi gerekebilir.Yeni bir veri kaynağı türü veya yeni bir dosya biçimi türü eklendiğinde, müşteri sınıfı MainClass'ın kaynak kodunun yeniyi kullanmak için değiştirilmesi gerekir. Sınıf, ancak açma ve kapama ilkesini ihlal ediyor. Şimdi onu yeniden inşa etmek için bağımlılığı tersine çevirme ilkesini kullanın.
Elbette, belirli koşullara göre, AbstractSource AbstractStransformer'a da enjekte edilebilir. Bağımlılık enjeksiyonunun üç yolu vardır:
Yedi, kompozisyon / toplama yeniden kullanım prensibi
(Composite / Aggregate ReusePrinciple, CARP): Yazılımın yeniden kullanılması amacına ulaşmak için kalıtım yerine nesne kompozisyonunu kullanmayı deneyin.
1. Tanım
Genellikle Bileşik Yeniden Kullanım İlkesi (Bileşik Yeniden Kullanım İlkesi veya CRP) olarak adlandırılır. Yeniden kullanım amacına ulaşmak için kalıtım yerine nesne bileşimini kullanmaya çalışın.
Yeni bir nesnede var olan bazı nesneleri yeni nesnenin parçası yapmak için kullanmaktır; yeni nesne, bu nesnelere delege ederek mevcut işlevleri yeniden kullanma amacına ulaşır. Kısacası, kompozisyon / toplama kullanmaya çalışın ve kalıtımı kullanmamaya çalışın.
2. İlke analizi
(1) Nesne yönelimli tasarımda, mevcut tasarımlar ve uygulamalar, iki temel yöntemle, yani birleştirme / birleştirme ilişkileri veya kalıtım yoluyla farklı ortamlarda yeniden kullanılabilir.
Kalıtımın yeniden kullanımı : Uygulaması basit ve genişletmesi kolay. Sistemin kapsüllenmesini yok edin; temel sınıftan miras alınan uygulama statiktir ve çalışma zamanında değiştirilemez ve yeterli esneklik yoktur; yalnızca sınırlı bir ortamda kullanılabilir. ("Beyaz Kutu" yeniden kullanımı)
Kombinasyon / toplama çoklama : Birleştirme derecesi nispeten düşüktür, üye nesneyi seçmeli olarak çağırma işlemi, çalışma zamanında dinamik olarak gerçekleştirilebilir. ("Kara kutu" yeniden kullanımı)
(2) Kombinasyon / birleştirme sistemi daha esnek hale getirebilir ve sınıflar arasındaki birleştirme derecesi azalır Bir sınıfın değişikliğinin diğer sınıflar üzerinde nispeten az etkisi olacaktır Bu nedenle, yeniden kullanımı sağlamak için genellikle kombinasyon / birleştirme kullanılması tercih edilir; Kalıtımı göz önünde bulundurun. Kalıtımı kullanırken, Richter'in ikame ilkesine kesinlikle uymanız gerekir. Kalıtımın etkili kullanımı, sorunu anlamaya ve karmaşıklığı azaltmaya yardımcı olurken, kalıtımın kötüye kullanılması, sistem oluşturma ve bakımının zorluğunu ve sistemin karmaşıklığını artıracaktır. Bu nedenle, kalıtımın yeniden kullanımını dikkatlice kullanmanız gerekir.
(3) Bu ilke ve Richter'in İkame İlkesi birbirini tamamlayıcı niteliktedir ve her ikisi de "aç-kapa" ilkesinin somut olarak gerçekleştirilmesi için şartnamelerdir. Bu ilkenin ihlal edilmesi "aç-kapa" ilkesinin farkına varmayacaktır. Her şeyden önce, bileşim ve birleştirme kavramlarını anlamalıyız:
Not: Toplama ve kompozisyon arasındaki fark nedir?
Sentez (kombinasyon) : Bir bütün ve bir parça arasındaki ilişkiyi temsil eder ve bütüne dayalı bir ilişkiyi ifade eder (bütün ve parça ayrılamaz); örneğin, gözler ve ağız kafa için bir kombinasyon ilişkisidir. Baş olmadan gözler ve ağız olmaz. Bölünmüş. UML'de, kombinasyon ilişkisi içi dolu bir elmasla düz bir çizgi ile temsil edilir.
polimerizasyon : Toplama, bileşik bir ilişkiden daha güçlü bir bağımlılık ilişkisidir ve aynı zamanda bütün ile parça arasındaki ilişkiyi de temsil eder (bütün ve parça ayrılabilir); örneğin, vidalar ile araba oyuncakları arasındaki ilişki ve oyuncaklardan ayrılan vidalar diğer ekipmanlarda da kullanılabilir. UML'de, toplama ilişkisi içi boş bir elmas içeren düz bir çizgi ile temsil edilir.
Sekiz, Dimit yasası
(Demeter Yasası, LoD: Sistemdeki sınıflar, sınıflar arasındaki bağlantı derecesini azaltmak için diğer sınıflarla etkileşime girmemeye çalışın.
1. Tanım
Ayrıca, çeşitli biçimlerde En Az Bilgi İlkesi (LKP) olarak da adlandırılır:
"Yabancılarla" konuşma. İngilizce tanımı şudur: Yabancılarla konuşma.
Yalnızca doğrudan arkadaşlarınızla iletişim kurun. İngilizce tanımı şudur: Yalnızca en yakın arkadaşlarınızla konuşun.
Her yazılım birimi, diğer birimler hakkında minimum bilgiye sahiptir ve bu birimle yakından ilgili olan yazılım birimleriyle sınırlıdır.
Basitçe söylemek gerekirse, bir nesne diğer nesneler hakkında olabildiğince az bilgiye sahip olmalıdır. Bir sınıf, birleştirilmesi veya çağrılması gereken sınıf hakkında en az bilgiye sahip olmalıdır.İçinizdeki kişilerin (bağlı veya çağrılan sınıf) ne kadar karmaşık olduğunun benim için önemi yok. Bu sizin işiniz, sağladığınız genel yöntemleri biliyorum, ben Sadece o kadar çok ara, diğerlerini umursama.
2. Hukuk analizi
Arkadaşlar kategorisi: Dimit Kanunu'nda bir nesne için arkadaşları aşağıdaki kategorileri içerir:
(1) Mevcut nesnenin kendisi (bu);
(2) Geçerli nesne yöntemine parametre olarak iletilen nesne;
(3) Mevcut nesnenin üye nesnesi;
(4) Mevcut nesnenin üye nesnesi bir koleksiyonsa, koleksiyondaki öğeler de arkadaştır;
(5) Mevcut nesne tarafından oluşturulan nesne.
Yukarıdaki koşullardan biri karşılanırsa herhangi bir nesne mevcut nesnenin "arkadaşı" olur, aksi takdirde "yabancı" olur.
3. Dar anlam ve geniş anlam:
Dar Dimit kuralında, iki sınıfın birbiriyle doğrudan iletişim kurması gerekmiyorsa, bu durumda iki sınıfın doğrudan etkileşime girmemesi gerekir.Sınıflardan birinin diğer sınıfın bir yöntemini çağırması gerekiyorsa, Bu çağrı üçüncü bir şahıs aracılığıyla iletilebilir.
Dar anlamda Dimit yasası : Sınıflar arasındaki bağlantıyı azaltabilir, ancak sisteme çok sayıda küçük yöntem katacak ve sistemin her köşesine dağılacaktır, bir sistemin yerel tasarımını basitleştirebilir, çünkü her parçanın uzak bir nesnesi olmayacaktır. Doğrudan korelasyon, ancak aynı zamanda sistemin farklı modülleri arasındaki iletişim verimliliğini azaltacak ve sistemin farklı modülleri arasında koordinasyonu zorlaştıracaktır.
Genelleştirilmiş Dimit Yasası : Bilgi akışının kontrolü, nesneler arasındaki bilginin yönü ve etkisi, özellikle de bilgi gizleme kontrolü ile ilgilidir. Bilgilerin gizlenmesi, çeşitli alt sistemleri birbirinden ayırarak bağımsız olarak geliştirilmesine, optimize edilmesine, kullanılmasına ve değiştirilmesine olanak sağlayabilir ve yazılımın yeniden kullanımını teşvik edebilir. Her modül diğer modüllere bağlı olmadığından, her biri Bir modül başka yerlerde bağımsız olarak kullanılabilir. Bir sistemin ölçeği ne kadar büyükse, bilgi gizleme o kadar önemli ve bilgi gizlemenin önemi o kadar açıktır.
4. Dimit yasasının temel amacı aşırı bilgi yüklemesini kontrol etmektir.
Sınıfların bölünmesinde, mümkün olduğunca gevşek bağlanmış sınıflar oluşturulmalıdır.Sınıflar arasındaki bağlantı ne kadar düşükse, yeniden kullanıma o kadar elverişlidir.Gevşetilmiş bir şekilde bağlanmış bir sınıf değiştirildiğinde, ilişkili sınıflara çok fazla zarar vermeyecektir. Geniş yayılma
Sınıfın yapısal tasarımında her sınıf, üye değişkenlerinin ve üye işlevlerinin erişim haklarını en aza indirmelidir;
Sınıfın tasarımında, mümkün olduğunda, bir tür değişmez sınıf olarak tasarlanmalıdır;
Diğer sınıflara yapılan göndermeler açısından, bir nesnenin diğer nesnelere göndermesi en aza indirilmelidir.
5. Örnekler
Cephe (yapı tipi)
Dimit kanunu ve tasarım deseni Cephe deseni, Arabulucu deseni
Sistemdeki sınıflar, diğer sınıflarla etkileşime girmemeye çalışın, sınıflar arasındaki eşleşmeyi azaltın, çünkü sisteminizde, genişlettiğinizde, bu sınıfları değiştirmeniz gerekebilir ve sınıflar arasındaki ilişki belirler Modifikasyonun karmaşıklığı, etkileşim ne kadar fazla olursa, modifikasyonun zorluğu o kadar büyük olur. Tersine, etkileşim ne kadar küçükse, modifikasyon o kadar zor olur.Örneğin, A sınıfı B sınıfına ve B sınıfı C sınıfına bağlıdır. A sınıfını değiştirdiğinizde, B sınıfının etkilenip etkilenmeyeceğini ve B sınıfının etkisinin C sınıfını etkileyip etkilemeyeceğini göz önünde bulundurmalısınız.C sınıfı şu anda D sınıfına bağlıysa, hehe, bunu böyle değiştirmek istiyorum Bazıları aldı.
Dokuz, QA
1. Nesneye yönelik tasarımın diğer ilkeleri?
Ambalaj değişiklikleri;
Daha az miras ve daha fazla kullanım kombinasyonu kullanın;
Arayüz programlama için, uygulama programlaması için değil;
Etkileşimli nesneler arasında gevşek bağlantı tasarımı için çok çalışın;
Sınıf genişletme için geliştirilmeli ve değişiklik için kapatılmalıdır (açık ve kapalı OCP prensibi);
Somut sınıflara değil, soyutlamaya güvenin (tersine çevrilmiş DIP ilkesine bağlıdır);
Gizli ilke: sadece arkadaşlarla konuşun (asgari bilgi ilkesi, Dimit kuralı);
Açıklama: Bir nesnenin diğer nesneler hakkında olabildiğince az bilgisi olması, yöntem çağrılarını sınırlar içinde tutması ve yalnızca aşağıdaki kapsama ait olan yöntemleri çağırması gerekir: nesnenin kendisi (yerel yöntem) nesne bileşenleri, yöntem parametreleri olarak aktarılır. Bu yöntemle oluşturulan veya somutlaştırılan herhangi bir nesne;
Beni bulma (beni ara) Seni bulacağım (seni arayacağım) (Hollywood prensibi);
Bir sınıfın değişmesi için yalnızca bir nedeni vardır (tek sorumluluk SRP ilkesi);
2. Richter ikame ilkesini açıklayabilir misiniz?
Kesin olarak tanımlanmış : S tipindeki her o1 nesnesi için, T tipinde bir o2 nesnesi varsa, böylece T tarafından tanımlanan tüm P programları, tüm nesneler o1 ile o2 ile değiştirildiğinde, P programının davranışını değiştirmez, o zaman S tipi T tipinin alt türü
Popüler ifade : Temel sınıfa (üst sınıf) yapılan tüm referanslar, alt sınıflarının nesnelerini şeffaf bir şekilde kullanabilmelidir. Başka bir deyişle, alt sınıf, ana sınıfın işlevlerini genişletebilir, ancak ana sınıfın orijinal işlevlerini değiştiremez. Aşağıdaki 4 anlamı içerir:
- Alt sınıflar, üst sınıfın soyut yöntemlerini uygulayabilir, ancak ana sınıfın soyut olmayan yöntemlerini geçersiz kılamaz.
- Alt sınıflara kendi benzersiz yöntemlerinizi ekleyebilirsiniz.
- Bir alt sınıfın bir yöntemi, bir üst sınıfın bir yöntemini aşırı yüklediğinde, yöntemin ön koşulları (yani yöntemin biçimsel parametreleri), ana yöntemin girdi parametrelerinden daha rahattır.
- Alt sınıfın yöntemi, ana sınıfın soyut yöntemini uyguladığında, yöntemin son koşulu (yani yöntemin dönüş değeri) ana sınıftan daha katıdır.
3. Dimit yasası hangi koşullarda ihlal edilecek? Neden bu problem var?
Dimit'in kuralı, sınıflar arasındaki bağlantıyı azaltmak için "yabancılarla değil, sadece arkadaşlarla konuşun" önermektedir.
4. Açma ve kapama ilkesine uyan bir tasarım modeli örneği verin.
Açma ve kapama ilkesi, kodunuzun genişletme için açık ve değişiklik için kapalı olmasını gerektirir. Bu, yeni bir işlev eklemek istiyorsanız, test edilen kodu değiştirmeden kolayca yeni kod ekleyebileceğiniz anlamına gelir. Strateji modeli gibi, açılma ve kapanma ilkesine dayalı birkaç tasarım modeli vardır.Yeni bir stratejiye ihtiyacınız varsa, temel mantığı değiştirmeden yalnızca arayüzler uygulamanız ve konfigürasyonlar eklemeniz gerekir. Çalışan bir örnek, strateji modelini temel alan ve açık ve kapalı ilkesini izleyen Collections.sort () yöntemidir. Yeni nesneler için sort () yöntemini değiştirmenize gerek yoktur. Tek yapmanız gereken kendi Karşılaştırıcı arayüzünüzü uygulamaktır. .
5. Flyweight modu (Flyweight modu) ne zaman kullanılmalı?
Flyweight modu, nesneleri paylaşarak çok fazla nesne oluşturmayı önler. Flyweight modelini kullanmak için, nesnelerinizin değişmez olduğundan emin olmanız gerekir, böylece onları güvenle paylaşabilirsiniz. JDK'daki Dize havuzu, Tamsayı havuzu ve Uzun havuz, uçuş ağırlığı modelini kullanmanın iyi örnekleridir.
