Gevşek bağlı tasarımlar oluşturmak için ne kadar çaba harcamalıyım?

Şu anda tasarım kalıplarını öğreniyorum.

Çoğu insanın bu kalıpların harika araçlar olduğu konusunda hemfikir olacağını düşünüyorum, ancak her şeyin cevabı olarak ılımlılıkla kullanılmalı. Bunları çok fazla kullanmak, uygulamayı çok az fayda ile aşırı karmaşık hale getirecektir. Desenler sadece en iyi çözüm olabilecekleri veya iyi bir çözümün oluşturulmasında yardımcı olabilecek yerlerde kullanılmalıdır (kabul ediyor musunuz?).

Bu düşünceyle birlikte:

Okuduğum kitap (Baş İlk Tasarım Desenleri) sık sık gevşek bağlantının önemini vurgulamaktadır . Bu gevşek bağlantı, 'bir uygulamaya değil, bir arayüze program' ve 'neyin değiştiğini kapsüle etme' gibi ilkeleri takip eder.

Temel olarak, şimdiye kadar öğrendiğim çoğu desen çoğunlukla tasarımların gevşek bir şekilde birleştirilmesine ve dolayısıyla daha esnek olmasına izin vermek için var.

Gevşek bağlantının önemini ve faydalarını anlıyorum.

Ama sorum şu ki, gevşek bağlanmış, esnek tasarımlar yaratmak için gerçekten ne kadar çaba harcanmalı?

Tasarım kalıplarına karşı çıkanlar, bu kalıpları kullanma maliyetlerinin genellikle faydalardan daha ağır bastığını söylüyor. Gerçek bir şekilde - gevşek bağlantı, 'bir uygulamaya değil, bir arayüze programlama' ve tüm bu ilkelerin o kadar da önemli olmayabileceği bazı kalıpları kullanarak gevşek bir şekilde bir tasarım oluşturmak için çok zaman harcıyorsunuz.

Bilmek istediğim, gerçekte ek soyutlama ve tasarım seviyeleri oluşturmak için ne kadar çaba harcamam gerektiğidir, sadece uygulamamın gevşek bağlantı, bir arayüze programlama vb.Gibi OO ilkelerini izlemesine izin vermek gerçekten değer mi? o? Bunun için ne kadar çaba harcamalıyım?

Yorgun cevap: ne kadar çok yaparsanız, o kadar az çaba harcar.

Temel olarak, gevşek bağlı kod oluşturmak gerçekten çok zor değil. Zihninizi gevşek bağlantı açısından düşünmek için eğitmek ise. Ve, buna tamamen değer olduğuna inanıyorum.

Son 20 yılda herkes tarafından önerildiği gibi, yazılım geliştirmede yinelemeli bir yaklaşım kullanan bir iş yaptığınızı varsayalım. Yineleme 1'de güzel çalışan bir şey inşa edersiniz. Yineleme 2'de bunun üzerine inşa edersiniz, bazı yeni özellikler eklersiniz ve yinelemenize uymadıklarında bir veya iki şeyi biraz bükersiniz. . Şimdi yineleme 3 geliyor ve gereksinimlerinizi temel mimarinizi yeniden düşünmenizi talep ediyorsunuz. Kodunuzu nasıl parçalara ayırırsınız ve kareye geri dönmeden nasıl yeniden inşa edersiniz?

Bu olur. Çok. Ya projeleri geciktirir ya da daha sonraki yinelemelerde yapılması gerekeni yapmaktan herkesi çok korkutur. En iyi durumda, Büyük bir Çamur Topu alırsınız. Gevşek bağlantı ve tek sorumluluk prensibi gibi şeyler bu sorunları büyük ölçüde azaltır. Bu yüzden SOLID ilkeleri lanse edilir - gerçekten yardım ederler.

Ve kemerinizin altında birkaç gevşek bağlı tasarımınız olduktan sonra, doğal olarak gelmeye başladığını göreceksiniz. Desenler, insanların kendileri için işe yaradığını buldukları şeylerdir, bu yüzden onları belgelediler. Zamanla doğal olarak gelen kullanışlı araçlardır.

Gereken çaba miktarı size her zaman yeterli değildir; Bence daha iyi bir önlem, getiri çabası olacaktır. Ancak getirinin ne olabileceğini anlamak her zaman kolay ve hatasız değildir.

Esnekliği artıran desenlerle akılda tutulması gereken şey, onları yerleştirmek için biraz çaba sarf etmesi ve neden onlara tam olarak ihtiyaç duyduğunuzu görmüyorsanız, kodda bir komplikasyona sahip olabilirsiniz, ancak asla kullanmazsınız. Esneklik asla esnemezse, orada da olmayabilir.

Her zaman (ya da makul olarak alabildiğiniz kadar yakın) yapmanız gereken bir şey vardır: yazılımınızın bireysel bileşenlerini (OOP için nesneler, fonksiyonel veya prosedürel programlama işlevleri) kara kutulara yapmak. Kara kutu, içerilerini (uygulamalarını) bilmediğimiz veya umursamadığımız bir şeydir.

Nasıl çalıştığını bilmiyor veya umursamıyorsak, arayüzden başka bir şey kullanmayacağız, bu yüzden uygulama arayüzü değiştirmeden değişirse, bu sadece kara kutunun içinde önemlidir - bunun dışında hiçbir şey etkilenebilir. Ayrıca program hakkında düşünmeyi kolaylaştırır, çünkü tüm programın her ayrıntısını kafanızda tutmak zorunda değilsiniz. Meşru bir şekilde unutabileceğiniz ayrıntılar, önemli ayrıntılar için kafanızda daha fazla yer vardır.

Bence tasarım modellerine yönelik itirazları yanlış anladınız; Ben onların hayranı değilim, ama bir arayüze gevşek bağlantı ve programlama ilkesini çok seviyorum. Onlara karşı en güçlü itirazım, onların arkalarındaki ilkeleri anlamayı teşvik etmeyen, daha ziyade detayların ezberlenmesini teşvik eden hazır ambalajlı bir çözüm olarak sunulmalarıdır. Onları incelememenizi tavsiye etmeyeceğim, ancak bunu yaptığınızda, onların arkasındaki prensipleri anlamanın belirli bir modelin özelliklerinden daha önemli olduğunu unutmayın.

Desen tasarlama itirazlarından biri 'açık' olmaları veya 'Onları duymadan önce onları kullanıyordum, sadece bu isimle değil'. İnsanların bu itirazları yapabilmelerinin ya da tasarım desenlerinin yaratıcılarının ilk etapta onlarla ortaya çıkabilmelerinin nedeni, arkalarındaki ilkeleri anlamalarıdır.

Kara kutuları kullanmak, kodunuzu aklı başında bir şekilde düzenler ve genellikle çok pahalıya mal olmazlar (herhangi bir şey varsa); onları her yerde kullanın. Bir tasarım deseni veya bir soyutlama katmanı ekleyen veya işleri karmaşıklaştıran başka bir teknik kullanmanın bir maliyeti vardır; onları sadece güzel ya da temiz ya da akıllı oldukları için kullanmayın; problemi uygun hale getirdiklerinde kullanın ve fayda elde etmek için maliyet ödemeye değer.

Sorunuz gevşek bağlantıyı Tasarım Desenleriyle eşitliyor gibi görünüyor, ancak bunlar gerçekten ayrı, ancak ilgili şeyler.

Gevşek kuplaj, programlamada temel bir konudur. Makine kodundan uzaklaştıkça ve sembolik dillere geçer geçmez, programlar yürütmeleriyle gevşek bir şekilde birleşti. Vb.

OO'nun kendisi temel olarak gevşek bağlı bileşenler oluşturmak için bir modeldir. Kapsülleme, nesnelerin iç kısımlarını diğer nesnelerle gevşek bir şekilde birleştirir. Fonksiyonel programlama daha da fazla olabilir, çünkü fonksiyon yürütme, aşırı uçtaki diğer fonksiyonların yürütülmesi ile gevşek bir şekilde birleştirilir.

Neredeyse tanım gereği, yaptığınız herhangi bir tasarım gevşek bağlantıyı içerecektir. İşlerin istemeden sıkıca birleştirilmesini sağlamanın yolları vardır, ancak birisinin aslında bir sistemi daha sıkı bir şekilde bağlanmak için tasarladığı birkaç durum gördüm .

(Arada sırada gelecekteki geliştiricilerin, belirli çerçeve yapay nesnelerine statik referanslar yerleştirerek, kullanımlarını zorlayarak - tasarım seçimleri yapmasını engellemek isteyen biriyle çalışıyorum. Ama bu gerçekten istisna. ve birçok bağlamda yeniden kullanabilirsiniz.)

Desenler sadece en iyi çözüm olabilecekleri veya iyi bir çözümün oluşturulmasında yardımcı olabilecek yerlerde kullanılmalıdır (kabul ediyor musunuz?).

Tasarım kalıplarını kesinlikle uygulama detayları olarak görüyorum. Herkese açık API'larınızı ve programınızı bu dokümantasyona belgelendirirseniz, genel olarak tasarım modellerinizin nerede olduğu önemli değildir (veya sizi çok fazla etkiler). Yani, "Burada bir köprü modelim var ve üstüne bir ziyaretçi uygulayacağım". Bunun yerine, "bu sınıfın çeşitli işletim sistemleri üzerinde farklı uygulamaları olacaktır, bu yüzden bir köprü deseni kullanılarak uygulanacaktır". Daha sonra, onu kullandığınızda, köprü olarak uygulanmasına kayıtsız kalırsınız - çünkü bir köprü modeline değil, genel API'ye bakarsınız.

gevşek bağlanmış, esnek tasarımlar yaratmak için ne kadar çaba harcanmalıdır?

Gevşek bağlantı basit bir dizi kural izlenerek elde edilebilir. Bunlara saygı duyarsanız, kodunuz yazarken (daha fazla) gevşek bir şekilde birleştirilir (yani herhangi bir çaba zaten geliştirme sürecinin bir parçasıdır).

Kurallar arasında (kapsamlı bir liste değil):

• arabirimlerinizi, sınıfın ne yapacağını değil (yani uygulama için değil, arabirim için tasarım) düşünerek (veya sınıfın nasıl kullanılacağını) düşünerek (veya yazarak)
• "söyle, sorma"
• önceden oluşturulmuş parçalardan nesneler oluşturma
• kullanacağınız gerçek nesneleri kurucuya iletin (üyeler için fabrikalar değil, parametrelerin fabrikaları için parametreler veya bunun gibi herhangi bir şey).
• KURU (iki yerde aynı sırada görünen iki satırınız varsa, bunları ayrı bir işleve çıkarın vb.).
• Bir nesnenin oluşturulması daha karmaşık bir işlemse, ara parçaların oluşturulmasını fabrika yöntemi / sınıfı olarak uygulayın (örn. Yapıcı gövdesinde değil).
• YAGNI (daha önce değil, ihtiyacınız olan şeyleri yaratın).

Bu kurallar dile, geliştirme metodolojisine ve ardından ekibinize (örneğin TDD), zaman bütçesi kısıtlamalarına vb. Bağlı olarak farklı şekilde uygulanır.

Örneğin, Java'da, arayüzünüzü bir olarak tanımlamak interfaceve bunun üzerine istemci kodu yazmak iyi bir uygulamadır (daha sonra arayüzü bir uygulama sınıfıyla başlatın ).

Öte yandan C ++ 'da arabirimleriniz yoktur, bu nedenle arabirimi yalnızca soyut bir temel sınıf olarak yazabilirsiniz; C ++ 'da kalıtım yalnızca güçlü bir gereksiniminiz olduğunda kullanıldığından (ve dolayısıyla gereksiz sanal işlevlerin ek yükünden kaçının), muhtemelen arabirimi ayrı olarak tanımlamazsınız, yalnızca sınıf üstbilgisini tanımlarsınız).

Tasarım kalıplarına karşı çıkanlar, bu kalıpları kullanma maliyetlerinin genellikle faydalardan daha ağır bastığını söylüyor.

Bence yanlış yapıyorlar. Gevşek olarak bağlanmış (ve DRY) kod yazarsanız, tasarım desenlerini içine entegre etmek çok az çaba gerektirir. Aksi takdirde, kodunuzu bir tasarım deseni uygulamak için uyarlamanız gerekir.

Bir tasarım deseni uygulamak için çok fazla değişiklik yapmanız gerekiyorsa, sorununuz tasarım deseni değildir - kod tabanınız monolitik ve sıkıca bağlıdır. Bu kötü / yetersiz bir tasarım problemidir, tasarım kalıpları problemi değildir.

Bilmek istediğim, gerçekte ek soyutlama ve tasarım seviyeleri oluşturmak için ne kadar çaba harcamam gerektiğidir, sadece uygulamamın gevşek bağlantı, bir arayüze programlama vb.Gibi OO ilkelerini izlemesine izin vermek gerçekten değer mi? o? Bunun için ne kadar çaba harcamalıyım?

Sorularınız, (bağlanmamış) varsayımını gevşetmenin tek faydasının tasarım desenlerini kolayca uygulayabilme yeteneği olduğunu varsaymaktadır. O değil.

Gevşek kuplajın faydaları arasında:

• yeniden düzenleme ve yeniden tasarım esnekliği
• daha az harcanan çaba
• test edilebilirlik
• kodu tekrar kullanma olasılığı arttı
• tasarım basitliği
• hata ayıklayıcıda daha az zaman harcanması

... ve şu an aklıma gelmeyen birkaç kişi daha.