DRY ve OOD ile tanıtılan kod bağlantısı

DRY vs Code coupling hakkında rehberlik arıyorum. Kodumu çoğaltmayı sevmiyorum ve ayrıca ilgisiz modüller arasında kod bağlamayı sevmiyorum. Çoğaltma tanıtıldıktan bir yıl sonra aynı kod tekrar bulursam bu yüzden yinelenen kodu refactor. Ancak, gerçek dünyanın çok daha öngörülemez olduğu durumları giderek artan bir şekilde yaşadım ve kodu yeniden düzenledikten sonra, kodu tekrar çatallamayı gerektiren durumlar ortaya çıkıyor.

Örneğin, benzinli arabaları, benzinli SUV'ları, elektrikli arabaları ve elektrikli SUV'ları işlemek için kodum olsaydı, yinelenen kodu "benzin" hiyerarşisine ve "elektrikli" hiyerarşiye yeniden düzenlediğimi varsayalım, her ikisi de "araç" hiyerarşisine iner. Çok uzak çok iyi. Ve sonra, şirketim orijinal bir hiyerarşimde temel değişiklikler gerektirecek bir hibrit otomobil ve bir melez Yarı tanıtıyor. Belki benzin ve elektrik hiyerarşileri arasında "bileşim" gerektirebilir.

Açıkça kod çoğaltma kötüdür, çünkü yukarıdaki tüm ürünler için ortak bir değişikliğin uygulanması için geçen süreyi arttırır. Ancak ortak kodu yeniden düzenlemek, ürüne özgü varyasyonları tanıtmayı eşit derecede zorlaştırır ve bir hatayı düzeltmek için kod satırını bulmak zorunda kaldığında çok sayıda "sınıf atlama" ya yol açar - daha üst düzey bir ana sınıftaki bir değişiklik tüm torunları arasında tetikleyici regresyon hatalarını tetikler.

DRY ile istenmeyen kod bağlantısı arasındaki en uygun denge nasıl sağlanır?

diyelim ki, "benzin" hiyerarşisine ve "elektrikli" hiyerarşiye yinelenen kodu yeniden düzenledim, her ikisi de "araç" hiyerarşisinden. Çok uzak çok iyi.

Ve sonra, şirketim orijinal bir hiyerarşimde temel değişiklikler gerektirecek bir hibrit otomobil ve bir melez Yarı tanıtıyor. Belki benzin ve elektrik hiyerarşileri arasında "bileşim" gerektirebilir

Bence bu insanların miras üzerine kompozisyona doğru ilerlemelerinin ana nedenlerinden biri.

Kalıtım, tarif ettiğiniz gibi kavramsal bir değişime sahip olduğunuzda sizi büyük yeniden yapılandırmaya zorlar.

Yeniden yapılanma 'çok büyük / zor' olduğunda insanlar bundan kaçınmak için yinelenen kod yazarlar.

Kodu miras zincirinin üzerine taşıyarak kopyayı uzaktan yapmak yerine bir yardımcı sınıf veya hizmete taşıyabilir ve sonra bu sınıfı gerektiğinde bir kompozisyonun parçası olarak enjekte edebilirsiniz.

Ortaya çıkan tasarımın OOP olup olmadığı tartışmaya açık

DRY prensibini izleyerek, alakasız modüller arasındaki bağlantıyı artırabilirsiniz. Özellikle büyük yazılım sistemlerinde bu, DRY'yi takip etmemenin daha iyi bir alternatif olabileceği durumlara yol açabilir.

Ne yazık ki, örneğiniz bunu göstermek için uygun değil - orada açıklanan problemler, yanlış mirasın yanlış kullanımındaki klasik hatalardan kaynaklanıyor . Ancak, yukarıda yazdıklarım için, ortak kodu ortak bir temel sınıfa veya yardımcı sınıfa (kompozisyon) yeniden yönlendirmeniz önemli değildir. Her iki durumda da, ortak kodu bir kütüphane L'ye yerleştirmek ve bu kütüphaneye daha önce ilişkilendirilmemiş iki A ve B programından referans vermek zorunda kalabilir.

A ve B'nin daha önce tamamen ilgisiz olduğunu varsayalım, bağımsız olarak sürümlendirilebilir, serbest bırakılabilir ve dağıtılabilirler. Bununla birlikte, ortak bir kod L'ye ortak kod yerleştirilerek, A için yeni gereksinimler L'de değişikliklere neden olabilir, bu da şimdi B'de değişikliklere neden olabilir.

Peki KURU ilkesinden vazgeçmek istemiyorsanız bu durumu nasıl halledebilirsiniz? Buna yaklaşmak için iyi bilinen bazı taktikler var:

1. A, B ve L'yi aynı ürünün bir parçası olarak, tek bir sürüm numarası, ortak bir derleme, bırakma ve dağıtma işlemi ile yüksek derecede otomasyonla tutun

2. veya L'yi kendi başına, küçük sürüm numaraları (uyumsuz değişiklik yok) ve büyük sürüm numaraları (belki de değişiklik değişiklikleri içerebilir) yapın ve A ve B'nin her birinin L'nin farklı bir sürüm satırına referans vermesine izin verin.

3. L'yi mümkün olduğunca SOLID yapın ve geriye dönük uyumluluğa dikkat edin. L'deki modüller daha fazla değişiklik yapılmadan yeniden kullanılabilir (OCP), daha az kırılma değişikliği meydana gelecektir. Ve "SOLID" deki diğer ilkeler bu hedefi desteklemeye yardımcı olmaktadır.

4. Özellikle L için ve aynı zamanda A ve B için otomatik testler kullanın.

5. L'ye ne koyduğunuza dikkat edin. Sistemdeki tek bir yerde bulunması gereken iş mantığı iyi bir adaydır. Sadece "birbirine benzeyen" ve gelecekte farklı olabilecek şeyler kötü adaylardır.

A ve B, farklı, ilgisiz takımlar tarafından geliştirildiğinde, sürdürüldüğünde ve geliştirildiğinde, KURU prensibi oldukça daha az önemli hale gelir - KURU sürdürülebilirlik ve evrimleşme ile ilgilidir, ancak iki farklı ekibin bireysel bakım çabası sağlamasına izin vermek bazen ürünlerini bağlamaktan daha etkili olabilir birlikte biraz yeniden kullanım nedeniyle.

Sonuçta bu bir ödünleşmedir. Daha büyük sistemlerde DRY ilkesini izlemek istiyorsanız, sağlam, yeniden kullanılabilir bileşenler oluşturmak için çok daha fazla çaba sarf etmeniz gerekir - genellikle beklediğinizden daha fazla. Buna değdiğinde ve olmadığında yargınıza güvenmelisiniz.

KURU bir başka yapısal kuraldır. Bu, onu aşırı uçlara götürürseniz, görmezden gelmek kadar kötü olduğu anlamına gelir. İşte sizi yapısal zihin setinden çıkarmak için bir metafor.

İkizlerinizi seviyorum. Klonları öldür.

Klavye yazımını önlemek için körü körüne kopyalayıp yapıştırdığınızda, dikkatsizce klonlar oluşturuyorsunuz. Tabii ne istediklerini yapıyorlar ama sizi tartıyorlar çünkü şimdi bu davranışı değiştirmek çok pahalı.

Aynı davranışı özdeş kodla yeniden oluşturduğunuzda, farklı bir sorumluluk nedeniyle aynı gereksinime sahip olursunuz, ancak bu size farklı değişiklikler yapabilir, zaman geçtikçe birey olarak değişmesi ve büyümesi gereken bir ikiziniz vardır.

DNA'larını (kodlarını) istediğiniz gibi tarayabilirsiniz. Klonların ve ikizlerin, tek yaptığınız şeylere bakmak olup olmadığını söylemek zor. İhtiyacınız olan şey yaşadıkları bağlamı anlamak. Neden doğdukları. Onların nihai kaderinin olması muhtemeldir.

Diyelim ki ABC şirketi için çalışıyorsunuz. A, B ve C olmak üzere üç şirket yöneticisi tarafından yönetiliyor. Hepsi küçük başlamanı istiyor. Şimdilik basit bir mesaj gönderin. Yani "Merhaba Dünya" yazıyorsunuz.

Nefret ediyor, şirket adını oraya koymanızı istiyor.

B onu seviyor, yalnız bırakmanızı ve bir açılış ekranına şirket adını eklemenizi istiyor.

C sadece bir hesap makinesi istiyor ve mesajın başlamanız için sadece bir yol olduğunu düşündü.

Emin olduğunuz bir şey var, bu adamlar bu projenin ne hakkında olduğu konusunda çok farklı fikirlere sahipler. Bazen aynı fikirde olurlar. Bazen sizi farklı yönlere çekerler.

Kodu çoğalttığınız için, bu kodun bağımsız olarak değişebilmesi için bir ikiz oluşturuyorsunuz. Yazmak bir acı olduğu için kodu çoğalttığınızda, kopyalayıp yapıştırmak kolaydır, kötü klonlar yaratırsınız.

A, B ve C, kodunuzun sunması gereken farklı yöneticilerdir. Hiçbir kod satırı uzun süre birden fazla master sunamaz.