SOLID'i takip etmek teknoloji yığınının üstüne bir çerçeve yazmaya yol açar mı?


70

SOLID'den hoşlanıyorum ve geliştirirken kullanmak ve uygulamak için elimden geleni yapıyorum. Ancak yardım edemiyorum ama SOLID yaklaşımı kodunuzu 'çerçeve' koduna dönüştürüyormuş gibi hissediyorum - yani diğer geliştiricilerin kullanması için bir çerçeve veya kitaplık oluştururken tasarlayacağınız kod.

Genelde 2 programlama modu uygulamıştım - gereksinimler ve KISS (tipik programlama) aracılığıyla tam olarak ne isteniyorsa tam olarak ya da diğer geliştiricilerin ihtiyaç duyabileceği esnekliği sağlayan çok genel ve tekrar kullanılabilir bir mantık, hizmetler vb. Oluşturma (çerçeve programlama) .

Eğer kullanıcı gerçekten bir uygulamanın x ve y şeyler yapmasını istiyorsa, SOLID'i takip etmek ve bir sürü soyutlama noktası eklemek için bir anlam ifade eder, hatta bunun başlaması için geçerli bir sorun olup olmadığını bile bilmiyorsanız ile? Bu soyutlama giriş noktalarını eklerseniz, kullanıcıların gereksinimlerini gerçekten karşılıyor musunuz ya da gelecekteki eklemeleri kolaylaştırmak için mevcut çerçevenizin ve teknoloji yığınının üstüne bir çerçeve oluşturuyor musunuz? Hangi durumda müşterinin veya geliştiricinin çıkarlarına hizmet ediyorsunuz?

Bu, Java Kurumsal dünyasında sık görülen, J2EE veya Spring üzerine kendi çerçevenizi tasarlıyormuş gibi hissettiğiniz bir şey mi? Böylece kullanıcı için UX'e odaklanmak yerine, geliştirici için daha iyi bir UX?


12
Kısa programlama kurallarının çoğu ile ilgili problem, yorumlamaya, kenar davalarına ve bazen bu kurallardaki kelimelerin tanımlarına maruz kalmaları, daha yakından inceleme konusunda belirsiz olmalarıdır. Esasen farklı insanlar için çok çeşitli anlamlara gelebilir. Bazı ideolojik olmayan pragmatizmalara sahip olmak, genellikle daha akıllıca kararlar verilmesine izin verir.
Mark Rogers

1
SOLID prensiplerine uymak gibi geliyorsa, bir şekilde büyük bir yatırım, çok fazla iş gerektiriyor. Olmaz, pratik olarak ücretsizdir. Muhtemelen sizi ya da başkalarını gelecekte büyük bir yatırımdan kurtaracaktır, çünkü kodunuzu korumayı ve genişletmeyi kolaylaştırır. "Ödevimizi yapmalı mıyız yoksa müşteriyi mutlu edelim mi?" Gibi sorular sormaya devam edersiniz. Bunlar takas değil.
Martin Maat

1
@MartinMaat Daha katı SOLID formlarının büyük yatırımlar yaptığını düşünüyorum. Yani. Kurumsal yazılım. Kurumsal yazılım dışında, ORM'inizi, teknoloji yığınınızı veya veritabanınızı soyutlamak için çok az nedeniniz olur çünkü seçtiğiniz yığına uyma şansınız çok yüksektir. Aynı şekilde, kendinizi belirli bir çerçeveye, veritabanına veya ORM'ye bağlayarak, KATI ilkelerini çiğniyorsunuz çünkü yığınınıza bağlısınız. SOLID'in bu esneklik seviyesi çoğu işte gerekli değildir.
Igneous01

1
Ayrıca bkz. İç Platform Etkisi .
Maxpm

1
Çoğu kodu bir çerçeve gibi bir şeye dönüştürmek hiç de fena görünmüyor. Sadece aşırı mühendislik yapılırsa korkunç olur. Ancak çerçeveler minimal ve tartışmalı olabilir. Bunun SOLID’i izlemenin kaçınılmaz bir sonucu olup olmadığından emin değilim , ancak bu kesinlikle olası bir sonuçtur ve bence, benimsemeniz gerekir.
Konrad Rudolph

Yanıtlar:


84

Gözlemin doğrudur, SOLID ilkeleri yeniden kullanılabilir kütüphanelerle veya çerçeve koduyla yapılan IMHO'dur. Hepsini kör bir şekilde takip ettiğinizde, mantıklı olup olmadığını sormadan, sisteminize muhtemelen gereğinden fazla daha fazla efor sarf etme ve yatırım yapma riskini alıyorsunuz.

Bu bir takastır ve ne zaman genelleştirileceği ve ne zaman olamayacağı konusunda doğru kararlar vermek için biraz tecrübe ister. Buna olası bir yaklaşım, YAGNI ilkesine bağlı kalmaktır - kodunuzu SOLID yapmayın "sadece durumunda" - veya, kelimelerinizi kullanmak için:

Diğer geliştiricilerin esneklik sağlar olabilir gerek

bunun yerine, diğer geliştiricilerin ihtiyaç duydukları anda , ancak daha önce değil, gerçekte ihtiyaç duydukları esnekliği sağlayın .

Bu yüzden, ne zaman kodunuzda bir işlev veya sınıf varsa, yeniden kullanılıp kullanılamayacağından emin değilsiniz, onu şu anda çerçevenize koymayın. Yeniden kullanım ve refactor için "bu durumda yeterince SOLID" olması için gerçek bir vakanın olmasını bekleyin . Daha fazla yapılandırılabilirlik (OCP'den sonra) veya soyutlama giriş noktalarını (DIP kullanarak) gerçekten gerçek yeniden kullanım durumu için ihtiyaç duyduğunuz bir sınıfa uygulamayın. Yeniden kullanım gereksinimi gerçekte orada olduğunda bir sonraki esnekliği ekleyin.

Elbette, bu çalışma şekli her zaman mevcut çalışma kodu tabanında bir miktar yeniden düzenleme gerektirecektir. Otomatik testlerin burada önemli olmasının nedeni budur. Bu nedenle, kodunuzu baştan sona test edilebilir hale getirmek için yeterince SOLID yapmak, zaman kaybı değildir ve bunu yapmak YAGNI ile çelişmez. Otomatik testler, "kod yeniden kullanımı" için geçerli bir durumdur, çünkü söz konusu kod üretim kodundan ve testlerden kullanıldığından. Ancak unutmayın, sadece testlerin çalışmasını sağlamak için ihtiyaç duyduğunuz esnekliği ekleyin, daha az değil, daha fazla değil.

Bu aslında eski bilgeliktir. Uzun zaman önce SOLID terimi popüler hale gelmeden önce, bir kullanıcı yeniden kullanılabilir kod yazmaya çalışmadan önce , kullanılabilir kod yazmamız gerektiğini söyledi . Ve hala bunun iyi bir öneri olduğunu düşünüyorum.


23
Ekstra çekişme noktaları: Kodunuzu yeniden kullanmak üzere yeniden düzenlemeden önce, aynı mantığı gördüğünüz 3 kullanım durumunun olmasını bekleyin. 2 parça ile yeniden düzenlemeye başlarsanız, değişen gereksinimlerin veya yeni bir kullanım durumunun yaptığınız soyutlamayı kırdığı bir durumda sona ermek kolaydır. Ayrıca refactors'ı aynı kullanım durumuyla sınırlı tutmaya devam edin: 2 bileşen aynı koda sahip olabilir, ancak tamamen farklı şeyler yapabilir ve bu bileşenleri birleştirirseniz, satırın ilerleyen bölümlerinde sorunlara yol açacak olan bu mantığı birbirine bağlarsınız.
Nzall

8
Genel olarak buna katılıyorum, ancak "tek seferlik" uygulamalara çok fazla odaklandığını hissediyorum: Kodu yazıyorsunuz, işe yarıyor, gayet iyi. Ancak, "uzun süre desteği" olan birçok uygulama var. Bir kod yazabilir ve 2 yıl sonra, iş gereksinimleri değişir, böylece kodu ayarlamanız gerekir. O zamana kadar birçok başka kod buna bağlı olabilir - bu durumda, SOLID ilkeleri değişikliği kolaylaştırır.
R. Schmitz

3
"Yeniden kullanılabilir kod yazmaya çalışmadan önce, kullanılabilir kod yazmalıyız" - Çok akıllıca!
Graham

10
Gerçek bir kullanım durumunuz olana kadar beklemenin SOLID kodunuzu daha iyi hale getireceğini unutmayın , çünkü varsayımlarda çalışmak çok zor ve gelecekteki ihtiyaçların ne olacağını yanlış tahmin etmeniz muhtemeldir. Projemiz ... işler KATI ve gelecekteki ihtiyaçları için esnek olacak şekilde tasarlanmıştır düzenlenen olguların numarası vardır gelecekteki ihtiyaçları anda kimse düşünce şeyler olduğu ortaya çıktı, bu yüzden her iki gözden geçirmeniz gereken haricinde ve ekstra esneklik vardı biz yine de gerekmedi - ki bunlar yeniden ateşleme karşısında tutulmalı ya da hurdaya çıkarılmış olmalı.
KRyan

2
Ayrıca, genellikle somut uygulamalardan testlere geçmek için ilk bir soyutlama katmanına sahip olmak anlamına gelen test edilebilir bir kod yazmanız gerekecektir.
Walfrat

49

Deneyimime göre, bir uygulama yazarken, üç seçeneğiniz var:

  1. Sadece gereklilikleri yerine getirmek için kod yazınız,
  2. Mevcut gereklilikleri yerine getirmenin yanı sıra gelecekteki gereksinimleri öngören genel kodu yazın,
  3. Yalnızca mevcut gereksinimleri karşılayan, ancak daha sonra diğer ihtiyaçları karşılamak için kolayca değiştirilebilecek bir kod yazın.

İlk durumda, birim testlerinden yoksun sıkıca bağlı bir kodun ortaya çıkması yaygındır. Elbette yazması hızlı, ama test etmesi zor. Gereksinimler değiştiğinde daha sonra değişmesi de kraliyet acısıdır.

İkinci durumda, gelecekteki ihtiyaçları öngörmeye çalışmak için çok fazla zaman harcanır. Ve çoğu zaman bu beklenen beklentiler asla gerçekleşmez. Bu açıkladığınız senaryo gibi görünüyor. Bu çoğu zaman bir çaba kaybıdır ve beklenmeyen bir gereksinim ortaya çıktığında değişmesi zor olan gereksiz yere karmaşık bir kodla sonuçlanır.

Son durum benim görüşüme göre amaçlanacak olandır. Kodunuzu ilerledikçe test etmek için TDD veya benzeri teknikleri kullanın; gevşek bir şekilde birleştirilmiş kodla biteceksiniz, bu da kolayca değiştirilebilecek ancak yazması kolay. Mesele şu ki, bunu yaparak doğal olarak SOLID ilkelerinin birçoğunu takip ediyorsunuz: küçük sınıflar ve işlevler; arayüzler ve enjekte edilen bağımlılıklar. Ve Bayan Liskov da genellikle mutlu tutulur, çünkü tek sorumlulukları olan basit sınıflar, oyuncu değiştirme ilkesine nadiren düşmektedir.

Burada gerçekten geçerli olmayan SOLID'in tek yönü açık / kapalı prensibidir. Kütüphaneler ve çerçeveler için bu önemlidir. Kendi kendine yeten bir uygulama için, çok değil. Gerçekten de " SLID " i izleyen bir kod yazma durumu: yazması kolay (ve okunması), test edilmesi kolay ve bakımı kolay.


bu sitede en sevdiğim cevaplardan biri!
TheCatWhisperer

Bunun nasıl sonuçlanacağından emin değilim 1) 3'ten daha test etmek daha zor. Değişiklik yapmak daha zor, elbette, ama neden test edemiyorsunuz? Herhangi bir şey varsa, tek fikirli bir yazılımın gereksinimlere karşı test edilmesi daha genel olandan daha kolaydır.
Bay Lister,

@ MrLister İki el ele, 1. test etmek daha zor. Çünkü tanım, "daha sonra diğer ihtiyaçları karşılamak için kolayca değiştirilebilecek bir şekilde" yazılmış olmadığını ima ediyor.
Mark Booth

1
+ 0; IMVHO, 'O' (açık-kapalı) çalışma biçimini yanlış yorumluyorsunuz (genel olarak da olsa). Bkz. Örneğin codeblog.jonskeet.uk/2013/03/15/… - küçük kod tabanlarında bile, bağımsız olarak test edilebilecek ve eklenebilecek kod birimlerinin (ör. Sınıflar, modüller, paketler, her neyse) olduğu bir kodlama hakkında Gerektiğinde çıkar / kaldırılır. Bu tür bir örnek, bir paket kullanım yöntemi olabilir - onları birleştirme şeklinize bakılmaksızın, 'kapalı', yani kendi kendine yeten ve 'açık' olmalı, yani bir şekilde genişletilebilir olmalıdır.
vaxquis 29:18

BTW, hatta Bob Amca bile bir noktadan böyle devam ediyor: “Açık [kapalı] demek, davranışınızı beklenen şekilde değiştiğinde, süpürme yapmak zorunda kalmayacak şekilde kodunuzu bir pozisyona getirmeye çalışmanız gerektiğidir. sistemin tüm modüllerinde değişiklik yapar. İdeal olarak, yeni kodu yeni kod ekleyerek ve çok az eski kod değiştirerek veya değiştirmeyerek ekleyebileceksiniz. ” <- açıkça değiştirilmeleri veya düzeltilmeleri isteniyorsa (ve IMVHO, bu genellikle durumdur, özellikle kıkırdama düzeltmeleri ile ilgili olduğunda )
vaxquis 29:18 '

8

Sahip olduğunuz bakış açısı kişisel deneyimlerle çarpıtılabilir. Bu, bireysel olarak doğru olan gerçeklerin kaygan bir eğimidir, ancak ortaya çıkan çıkarım, ilk bakışta doğru gibi görünse bile değildir.

  • Altyapıların kapsamı küçük projelerden daha büyüktür.
  • Kötü uygulamaların daha büyük kod tabanlarında başa çıkması oldukça zordur.
  • Bir çerçeve oluşturmak (ortalama olarak) küçük bir projeyi oluşturmaktan daha yetenekli bir geliştirici gerektirir.
  • Daha iyi geliştiriciler daha iyi uygulamaları (SOLID) takip eder.
  • Sonuç olarak, çerçeveler, iyi uygulama için daha yüksek bir ihtiyaç ve daha yakından iyi uygulama ile deneyimli geliştiriciler tarafından oluşturulan olma eğilimindedir.

Bu, çerçevelerle ve daha küçük kütüphanelerle etkileşime girdiğinizde, etkileşime gireceğiniz iyi uygulama kodunun daha büyük çerçevelerde bulunacağı anlamına gelir.

Bu yanlışlık çok yaygındır, örneğin tedavi ettiğim her doktor kibirliydi. Bu nedenle tüm doktorların kibirli olduğu sonucuna varıyorum. Bu yanlışlıklar her zaman kişisel deneyimlere dayanarak battaniye çıkarımı yapmaktan muzdariptir .

Sizin durumunuzda, daha küçük kütüphanelerde değil, daha büyük çerçevelerde ağırlıklı olarak iyi uygulamalar deneyimlemiş olmanız mümkündür. Kişisel gözlemin yanlış değil, ancak fıkra niteliğinde bir kanıt ve evrensel olarak geçerli değil.


2 programlama modu - gereksinimler ve KISS (tipik programlama) aracılığıyla tam olarak ne isteniyorsa o kadar fazla veya daha az yaratma veya diğer geliştiricilerin ihtiyaç duyabileceği esnekliği sağlayan çok genel ve tekrar kullanılabilir bir mantık, hizmetler vb. Oluşturma (çerçeve programlama)

Bunu burada bir şekilde onaylıyorsun. Bir çerçevenin ne olduğunu düşünün. Bu bir uygulama değil. Başkalarının her türlü başvuruyu yapmak için kullanabileceği genelleştirilmiş bir "şablon" dur. Mantıksal olarak, bu, herkes tarafından kullanılabilir olması için bir çerçevenin çok daha soyutlanmış bir mantıkta inşa edildiği anlamına gelir.

Çerçeve üreticileri kısayol alamazlar çünkü sonraki uygulamaların gerekliliklerinin ne olduğunu bile bilmiyorlar. Bir çerçeve oluşturmak, kodlarını başkaları için kullanılabilir hale getirmek için doğal olarak teşvik eder.

Bununla birlikte, uygulama geliştiricileri, bir ürünü teslim etmeye odaklandıkları için mantıksal verimden ödün verme yeteneğine sahiptir. Temel amacı, kodun çalışması değil, kullanıcının deneyimidir.

Bir çerçeve için, son kullanıcı kodunuzla etkileşime girecek olan başka bir geliştiricidir. Kodunuzun kalitesi son kullanıcınız için önemlidir.
Bir uygulama için, son kullanıcı kodunuzla etkileşime girmeyen geliştirici değildir. Kodunuzun kalitesi onlar için önemli değildir.

İşte bu nedenle bir geliştirme ekibinin mimarlarının çoğu zaman iyi uygulamanın uygulayıcıları olarak hareket etmesinin nedeni budur. Ürünün tesliminden bir adım kaldılar; bu, uygulamanın kendisinin teslimine odaklanmak yerine koda objektif olarak bakma eğiliminde oldukları anlamına gelir.


Bu soyutlama giriş noktalarını eklerseniz, kullanıcıların gereksinimlerini gerçekten karşılıyor musunuz ya da gelecekteki eklemeleri kolaylaştırmak için mevcut çerçevenizin ve teknoloji yığınının üstüne bir çerçeve oluşturuyor musunuz? Hangi durumda müşterinin veya geliştiricinin çıkarlarına hizmet ediyorsunuz?

Bu ilginç bir nokta ve (benim tecrübeme göre) insanların hala iyi uygulamalardan kaçınmaya haklı göstermeye çalışmasının temel nedeni.

Aşağıdaki hususları özetlemek için: İyi uygulamaların atlanması ancak, gereksinimleriniz (şu anda bilindiği gibi) değiştirilemezse haklı gösterilebilir ve kod tabanında hiçbir değişiklik / ekleme yapılmayacaktır. Spoiler uyarısı: Nadiren böyle olmaz.
Örneğin, belirli bir dosyayı işlemek için 5 dakikalık bir konsol uygulaması yazdığımda iyi bir uygulama kullanmıyorum. Çünkü sadece bugün uygulamayı kullanacağım ve gelecekte güncellenmesi gerekmeyecek (tekrar ihtiyacım olursa farklı bir uygulama yazmak daha kolay olur).

Diyelim ki 4 hafta içinde bir uygulama oluşturabilir ve 6 hafta içinde uygun bir şekilde oluşturabilirsiniz. İlk bakışta, ayakkabılı bina daha iyi görünüyor. Müşteri uygulamalarını daha hızlı alır ve şirketin geliştirici ücretlerine daha az zaman harcaması gerekir. Kazan / kazan, tamam mı?

Ancak, bu önceden düşünmeden verilen bir karardır. Kod temeli kalitesi nedeniyle, ayakkabılı yapıya yapılan değişikliklerde büyük bir değişiklik yapılması 2 hafta sürecek ve aynı yapıya uygun yapılanma yapı değişikliği 1 hafta sürecektir. Gelecekte ortaya çıkan bu değişikliklerin çoğu olabilir.

Ayrıca, beklenmedik bir şekilde yapılan değişikliklerde, başlangıçta kurban kodlu kod tabanlarında düşündüğünüzden daha fazla iş gerektirme eğilimi vardır , bu nedenle gelişim zamanınızı iki yerine üç haftaya kadar zorlayabilirsiniz.

Ve daha sonra böcek aramak için zaman harcamak gibi bir eğilim var. Bu genellikle, zaman kısıtlamaları ya da uygulama isteksizliği nedeniyle kayıtsız kalmanın dikkate alınmadığı projelerde söz konusudur.

Hatta büyük bir güncelleme olması gerekmez. Mevcut işverenimde, hızlı ve kirli inşa edilmiş ve gereksinimlerdeki bir yanlış anlaşılmadan dolayı en ufak bir hata / değişiklik yapılması gerektiğinde, modülden sonra refaktör modülüne ihtiyaç duyulması zincir reaksiyonuna yol açan birkaç proje gördüm. . Bu projelerden bazıları ilk versiyonlarını piyasaya sürmeden önce çöktü (ve sürdürülemez bir karmaşayı geride bıraktı).

Kısayol kararları (hızlı ve kirli programlama) yalnızca gereksinimlerin tam olarak doğru olduğunu ve hiçbir zaman değişmesi gerekmeyeceğinin kesin olarak garanti edilmesi durumunda yararlıdır . Tecrübelerime göre, bunun doğru olduğu bir projeyle hiç karşılaşmadım.

Ekstra zamanı iyi uygulamalara yatırmak geleceğe yatırım yapmaktır. Gelecekteki hatalar ve değişiklikler, mevcut kod temeli iyi uygulamalara dayandığında çok daha kolay olacaktır. Sadece iki veya üç değişiklik yapıldıktan sonra zaten temettü ödeyecek.


1
Bu iyi bir cevap, ancak şunu açıklamalıyım ki, iyi uygulamaları bıraktığımızı söylemiyorum, ama hangi seviyede 'iyi uygulamaları' sürdürüyoruz? ORM'nizi her projede soyutlamak iyi bir uygulama mı çünkü daha sonra başka bir tane ile değiştirmek zorunda kalabilirsiniz. Öyle sanmıyorum, kabul etmeye istekli olduğum bazı bağlaşma seviyeleri var (yani, seçilen çerçeveye, dile, ORM'ye, veritabanına bağlıyım). SOLID'i aşırı uç derecesine kadar takip edersek, gerçekten sadece kendi çerçevemizi seçilen yığının üstüne mi uyguluyoruz?
Igneous01

OP'nin deneyimini "yanlışlık" olarak inkar ediyorsun. Yapıcı değil.
max630

@ max630 Ben inkar etmiyorum. OP'nin gözlemlerinin neden geçerli olduğunu açıklayan cevabın iyi bir kısmını harcadım.
Flater

1
@ Igneous01 SOLID bir çerçeve değil. SOLID, bir çerçevede daha sık rastlanan bir soyutlamadır. Herhangi bir soyutlamayı (SOLID dahil) uygularken, her zaman makul bir çizgi vardır. Sadece soyutlama uğruna soyut olamazsın, yaşlarını çok fazla genelleşmiş ve takip etmesi zor bir kodla gelip geçirirdin. Sadece makul bir şekilde şüphelendiğiniz şeyleri soyutlayın gelecekte sizin için yararlı olacaktır. Bununla birlikte, örneğin mevcut veritabanı sunucunuzla bağlı olduğunuzu varsayma tuzağına düşmeyin. Yarın hangi yeni veritabanının yayınlanacağını asla bilemezsiniz.
Flater

@ Igneous01 Başka bir deyişle, her şeyi soyutlamak istemeyerek doğru fikre sahipsiniz, ancak o yöne doğru çok hafifçe yaslandığınız hissine kapılıyorum. Geliştiricilerin mevcut gereksinimlerin taştan oluştuğunu varsaymaları ve daha sonra bu (arzulanan) varsayıma dayalı mimari kararlar almaları çok yaygındır.
Flater

7

SOLID basit kodu çerçeve koduna nasıl çevirir? Herhangi bir şekilde SOLID için bir stand değilim ama burada ne demek istediğinizi açık bir şekilde anlayamıyorum .

  • KISS, S ingle Sorumluluk İlkesinin özüdür .
  • Hiçbir şey yok Ç kalem / Kapalı İlke (anlıyorum en azından olarak görülmesi Jon Skeet iyi bir şey yapmak için kod yazma aykırı olduğunu). (Aslında kod ne kadar sıkı odaklanırsa “kapalı” kısım o kadar önemlidir.)
  • L iskov değişikliği İlke İnsanların senin sınıfları alt sınıfı izin vermek zorunda söylemez. O takdirde diyor sen senin sınıfları alt sınıfı, alt sınıfınız kendi üst sınıfı sözleşme yerine getirmelidir. Bu sadece iyi OO tasarımı. (Ve herhangi bir alt sınıfınız yoksa, geçerli değildir.)
  • KISS da özüdür ben nterface Ayrışma İlkesi.
  • D ependency Inversion Prensibi ben uzaktan uygulayarak görebilen tek olduğunu, ama yanlış bilinen ve abartılı olduğunu düşünüyorum. Bu her şeyi Guice veya Spring ile enjekte etmeniz gerektiği anlamına gelmez. Bu sadece uygun olan yerlerde soyut yapmanız ve uygulama detaylarına bağlı olmamanız anlamına gelir.

Kendimi SOLID terimleriyle düşünmediğimi itiraf ediyorum, çünkü Bob Martin okulundan değil, Gang of Four ve Josh Bloch programlama okullarından geçtim . Ancak, eğer “SOLID” = “teknoloji yığına daha fazla katman ekleyerek” düşünürseniz, yanlış okuduğunuzu düşünüyorum.


Not: “Geliştirici için daha iyi UX” in yararlarını kısa satmayın. Kod yaşamının çoğunu bakımda geçirir. Bir Geliştirici Sizsiniz .


1
SRP ile ilgili olarak - yapıcı olan herhangi bir sınıfın SRP'yi ihlal ettiği söylenebilir, çünkü bu sorumluluğu bir fabrikaya aktarabilirsiniz. OCP ile ilgili olarak - bu gerçekten çerçeve düzeyinde bir sorundur, çünkü tüketim için dış kullanım için bir arayüz yayınladığınızda, onu değiştiremezsiniz. Arabirim yalnızca projeniz içinde kullanılıyorsa, sözleşmeyi değiştirmek mümkündür, çünkü sözleşmeyi kendi kodunuzda değiştirme yetkiniz vardır. ISS ile ilgili olarak - bir kişi her bir eylem için (dolayısıyla SRP'yi koruyarak) bir arabirim tanımlanması gerektiğini ve dış kullanıcılar ile ilgili olduğunu iddia edebilir.
Igneous01

3
1) biri olabilir, ama dinlemeye değecek birisinin sahip olduğundan şüpheliyim. 2) bir projenin iç arayüzleri serbestçe değiştirmenin kötü bir fikir haline geldiği bir boyuta ne kadar çabuk büyüdüğünü görünce şaşırabilirsiniz. 3) bkz. 1) ve 2). Her üç ilkeye de fazla okuduğunuzu düşünüyorum. Ancak yorumlar, gerçekten bu argümanları ele almanın yeri değil; Her birini ayrı bir soru olarak ortaya koymanızı ve ne tür cevaplar aldığınızı görmenizi öneririm.
David Moles,

4
@ Igneous01 Bu mantığı kullanarak, alıcılar ve ayarlayıcıları bırakabilirsiniz, çünkü her değişken ayarlayıcı için ayrı bir sınıf ve her alıcı için ayrı bir sınıf oluşturabilirsiniz. IE: class A{ int X; int Y; } class A_setX{ f(A a, int N) { a.X = N; }} class A_getX{ int f(A a) { return X; }} class A_setY ... etc.Fabrika talebinizle çok meta bakış açısıyla baktığınızı düşünüyorum. Başlatma, etki alanı sorununun bir yönü değildir.
Aaron

@Aaron Bu. İnsanlar kötü argümanlar yapmak için SOLID kullanabilir, ancak bu kötü şeyler yapmak anlamına gelmez = “SOLID'den sonra”.
David Moles
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.