Tasarım desenlerinde neden bu kadar çok sınıfa ihtiyacımız var?

Ben yaşlılar arasında küçük geliştiriciyim ve onların düşüncelerini ve akıl yürütmelerini anlama konusunda çok zorlanıyorum.

Etki Alanına Dayalı Tasarım (DDD) okuyorum ve neden ihtiyacımız olduğunu anlamıyorum çok fazla sınıf yarat. Bu yazılım tasarım yöntemini takip edersek, en fazla iki dosya ve 3-4 işlevle değiştirilebilen 20-30 sınıfla bitiririz. Evet, bu karışık olabilir, ama çok daha sürdürülebilir ve okunabilir.

Ne zaman bir tür EntityTransformationServiceImpl ne yaptığını görmek istediğimde, birçok sınıfı, ara yüzü, işlev çağrısını, kurucuyu, yaratıcılığını ve benzeri şeyleri izlemem gerekiyor.

Basit matematik:

  • 60 satır kukla kod vs 10 sınıf X 10 (diyelim ki tamamen farklı bir mantığa sahip diyelim) = 600 satırlık dağınık kod vs. 100 sınıf + biraz daha bunları sarmak ve yönetmek; Bağımlılık enjeksiyonunu eklemeyi unutmayın.
  • 600 satırlık kodun okunması = bir gün
  • 100 sınıf = bir hafta, hangisinin ne yaptığını hala unutma

Herkes bakımı kolay olduğunu söylüyor, peki ne için? Her yeni işlevsellik eklediğinizde, fabrikalar, varlıklar, hizmetler ve değerler içeren beş sınıf daha eklersiniz. Bu tür bir kodun dağınık koddan daha yavaş hareket ettiğini hissediyorum.

Diyelim ki, bir ay içinde 50K LOC karışık kod yazarsanız, DDD işi çok fazla inceleme ve değişiklik gerektirir (her iki durumda da testleri önemsemiyorum). Daha fazla değilse, basit bir ekleme hafta alabilir.

Bir yılda, çok sayıda karışık kod yazarsınız ve hatta birden çok kez yeniden yazabilirsiniz, ancak DDD stilinde, dağınık kodla rekabet etmek için yeterli özelliğiniz yoktur.

Lütfen açıkla. Neden bu DDD stiline ve birçok desene ihtiyacımız var?

UPD 1: I received so many great answers, can you guys please add comment somewhere or edit your answer with the link for reading list (not sure from which to start, DDD, Design Patterns, UML, Code Complete, Refactoring, Pragmatic ,... so many good books), of course with sequence, so that I can also start understanding and become senior as some of you do.

198
@ user1318496 Bu , yukarıdaki sorunun bir kopyası. Siz aslında ne sorduğunuzu bilmiyorsunuz. Sorunuzun özünün, işlevsel programlama ya da tasarım modellerine karşı OO ile hiçbir ilgisi yoktur ve organizasyonla ilgisi vardır. Aslında bir cevabı istediğiniz soru "Kod neden farklı atomik birimlere ayrılsın?" Dır. Şimdi, birçok geliştirici bunun cevabının kendiliğinden açık olduğunu düşünmesine rağmen, bunun çok geçerli bir soru olduğuna inanıyorum. Pek çok geliştiricinin bir başkasıyla mücadele ettiği, yeni başladıkları sırada.
katma yazar Vassilis, kaynak
“Evet, bu dağınık olabilir, ama çok daha sürdürülebilir ve okunabilir.”. Dağınıksa, nasıl okunabilir ve bakımı nasıl yapılabilir?
katma yazar Bigballs, kaynak
@Jared: "Hangisi daha kolay test edilir?": Her zaman olduğu gibi, bu ne tür bir teste bağlı. 100 önemsiz sınıfınız varsa ve tüm sistem davranışları birbirleriyle nasıl bağlandıkları konusunda ise, genel olarak ortaya çıkan sistemin konuşması, entegrasyon ve KG testlerini yazmak için saf monolitten daha kolay değildir. "Tasarımınızı değiştirmediniz" diyen 100'den fazla birim testiniz var, peki ne olmuş? OP abartmış olabilir ve/veya kod iyi olabilir, ancak oran aynı sorunu çözmek için 6 satır başına bir naif kod başına gerçekten 1 sınıfsa, o zaman aşırı mühendislik yapılmışsa, dikkate alınması gereken nedenler vardır :-)
katma yazar TraumaPony, kaynak
Ve "aynı problemi çöz" derken elbette tamamen çözüyorum, bu da OP'nin bu kod tabanının yazarlarının ne gördüğünü görmekte başarısız olduğu başka bir alan. Çoğu zaman işe yarayan 600 satırlık kod, dışarıda, kodunun gerçekten işe yaradığını kodladığınızı anlayabilmenizi sağlayan faydalı teoremleri ispatlayan bir çerçevede oturan 100 sınıfla aynı değildir!
katma yazar TraumaPony, kaynak
@EricLippert: 100 sınıfındaki kod, yazılım kullanıcısına kolayca açıklanabilecek özelliklere sahipse, naif kodun yapmadığı, o zaman evet bu harika bir benzetmedir. Duvardaki bir delik ile camlı bir pencere arasındaki farkın, "saf çözüm aslında bir çözüm değil, çünkü gerçek kullanıcı gereksinimlerimizi karşılamadığı" olarak sınıflandırılmasının oldukça kolay olduğunu düşünüyorum. Öyleyse, birlikte çalışan kod bir günde çalışırsa, ancak kullanıcının karşılaştığı gerçek hizmetlerinizi çalıştıran yazılım yığına entegre edilemezse, bu daha fazla sınıf yazmak için örnek bir smaç argümanı olur.
katma yazar TraumaPony, kaynak
@Jared: Zaten 100 sınıfın test edilmesinin monolitten daha kolay olduğu konusunda zaten bahse girmiştin. Sadece bu iddiaya cevap veriyordum. Kodu değiştirmenin kolaylığı, monolitlere karşı tamamen farklı bir argümandır :-)
katma yazar TraumaPony, kaynak
OOP'nin evrensel bir en iyi araç olmadığı, bu nedenle sorunun her kısmının (özellikle mirasla birlikte) daha fazla sınıf ekleyerek çözülmesinin kötü, gereksiz yere karmaşık tasarımlara yol açabileceği ve yol açtığı unutulmamalıdır. Sorun, iyi bir tasarımın ortaya çıkmasının zaman ve deneyimli bir geliştirici gerektirmesi ve her ikisinin de maliyeti yüksek olmasıdır. İş, şu anda çalışırsa, dağınık bir tasarıma sahip olmak için genellikle sorun yoktur.
katma yazar Rorick, kaynak
Java yapmazsan, yapmazsın. Sahip olduğun tek şey Java olduğunda, her şey bir sınıfa benziyor.
katma yazar Krzysztof Klimonda, kaynak
Basitçe söylemek gerekirse, daha zor ve zarif kodlar yazmak daha uzun sürüyor, bu nedenle insanlar yapışkan olmayan ancak yüksek yapılandırılmış kodlar kullanıyor.
katma yazar Mr Rogers, kaynak
katma yazar innaM, kaynak
@Polygnome: Aynı yorumu yazmak üzereydim. Genç geliştiricilerin bir diğer seçenek yorumu ise, "Bu tür bir kodun dağınık koddan daha yavaş hareket ettiğini hissediyorum." Zamanınızın yarısını duvarlara dökerek geçirirseniz, olabildiğince hızlı koşmanız iyi olmaz! Yavaş pürüzsüz, pürüzsüz hızlı.
katma yazar CodeCharming, kaynak
Bu soru, "neden bir pencere oluşturmak için bu kadar çok parçaya ihtiyacımız var?" bir matkap alın, duvara bir delik açın, bitti. Pencere üreticileri neden bu kadar basit yapabileceğimde her şeyi bu kadar karmaşık hale getirmek istiyorlar? ”
katma yazar CodeCharming, kaynak
Genel olarak sınıflar hakkında user1318496 ile aynı şekilde hissetmeye başladım. Belki de kişisel tercihlerden başka bir şey değil.
katma yazar Graham, kaynak
@Graham Dilinin özellikleri belli bir derecede kişisel tercihi olmakla birlikte bu soruya diktir. İşlevsel kod, kolay oluşturma ve kolay değiştirme için yazılabilir.
katma yazar R. Schmitz, kaynak
@ 9000 Ben neden bahsettiğini COP - "Sınıf odaklı programlama" denir düşünüyorum? Gerçekten nesnelere sahip olma konusunda bir şey vermeden ders ekliyorsanız, OOP yapmıyorsunuzdur ...
katma yazar R. Schmitz, kaynak
Onlara gerçekten ihtiyacımız yok ...
katma yazar Vector, kaynak
Basit bir problemi çözmek için EntityTransformationServiceImpl s ile 20-30 sınıf kullanmanın belki de aşırı derecede mühendislik olduğunu düşünen sadece ben miyim? Sanırım, kültürü tasarım desenlerine, kod temeli anlaşılmaz olana kadar tasarım desenleri atmak olan Java'dan bahsediyorsunuz.
katma yazar Solomonoff's Secret, kaynak
Bence burada iyi bir soru var ama bu abartma ve hayal kırıklığının ardında saklanıyor. @ user1318496, sorunuzu bir miktar yeniden düzenlemekten faydalanabilirsiniz.
katma yazar Warpspace, kaynak
@jamesqf Belki de bunu dini bir dönüşüm olarak görüyorsunuz. Bunu Din -> Din türündeki bir işlev olarak görüyorum.
katma yazar Chad, kaynak
Bu cevapların ve yorumların bazıları birbirinden geçmiş. İki farklı soru düşünmenin yardımcı olabileceğini düşünüyorum, örneğin; " genel olarak " basit "kod yerine neden DDD/tasarım desenleri/vb." Kullanın (test edilebilirlik, ayrıştırma, vb.) Ve Beklediğimden çok daha fazla ders mi? " (fazla mühendislik, dile özgü geçici çözümler (örneğin, lambdas yok), modası geçmiş stil (örneğin, Java artık lambdalara sahiptir), kargo danışmanlığı, teknik borç vb.)
katma yazar Warbo, kaynak
Matematiğin kod satırları ve onların anlaşılır olmalarının oldukça komik olduğunu düşünüyorum. Gerçekten kullandığınız sayıların ardındaki sebeplerinizi ayrıntılı olarak görmek isterim.
katma yazar Euphoric, kaynak
Msgstr "600 satırlık kod okunuyor = bir gün". Bu yanlış ... Bir dersi okumamın zamanı üssel olarak artıyor, tüm dallanma ve dallanma yanlış tahminleri vs ... 600 satırda, rahatlık bölgemin kenarındayım. 1000'de normalde sınıfı tam olarak anlamak bir ay kadar sürer.
katma yazar ArTs, kaynak
F22 Raptor, bir IKEA armatür deposunu alıp uçak şeklinde bir kalıba dökerek inşa edilmedi.
katma yazar ArTs, kaynak
Alanınızda var olan bu sınıflar kavramları mı? Eğer değilse, neden varlar? Eğer öyleyse, o zaman işletme değeri, değil mi? Etki alanı kavramlarını temsil eden 20-30 sınıflara karşılık 600 satırlık karışık kod yazarsanız hangi esnekliği kaybedersiniz?
katma yazar Rob Crawford, kaynak
OOP genellikle bir anti-kalıptır ve saf OOP neredeyse her zaman bir anti-kalıptır. OOP, kodunuzdaki her türlü yere, özellikle de test edilebilirliğe kanama eğilimindedir. Tasarım desenleri, OOP'un aşırı kullanımıyla saçıldığınız tüm bu tırnakları sürmek için çekiçten (OOP) faydalanır. Sağlayıcı , Varlık veya İşlemci adında bir sınıfınız varsa, büyük olasılıkla OOP kullanıyorsanız, ancak kesinlikle çok fazla kişi bulabilirsiniz. O çiviyi nasıl kullanacağını bilen var.
katma yazar Rich Remer, kaynak
Kod yazmanın bu özel biçiminin, kalıplarla değil, kod yazarken insanlarla ilgili bir sorun olduğunu unutmayın. Çok desen ve zengin bir yazılım ve belki de 40 veya 50 sınıf yazabilirsiniz; kolay. Fakat bir şeyleri zorlarsanız ... o zaman, 3 sınıfla veya 4 ila 5 usule ilişkin fonksiyonla yapılabilecek bir şey için 20 sınıfla bitirdiniz. Önemli beceri, bir sınıfın bir tanrı sınıfı haline gelmemesi için onu parçalamak için çok büyük olduğu zaman tanımaktır.
katma yazar marstato, kaynak
OP'lerin savunmasında, neye atıfta bulunabileceğinin güzel bir örneği, 3 veya 4 düşük değerli koşulların üzerindeki basit anahtarları her yerde Devlet modeliyle değiştirmek. Bunun olduğunu gördüm ve sonuç gerçekten de yüzlerce satırlık kod yerine yüzlerce sınıf olabilir. Bakım da tehlikeye atıldı.
katma yazar Sentinel, kaynak
Hiç kimsenin Genel Sorumluluk İlkesi (eğer onu izlerseniz sayısız sınıfın üretimine öncülük eder) ve SOLID ilkelerine değinmediğine inanamıyorum.
katma yazar sizzlecookie, kaynak
@ user1318496 - Endişelenmenize gerek yok, fikirlerinizi paylaşan birçok başarılı şirket var. Ve her zaman işe alıyorlar, çünkü hızlı bir şekilde yazılan kodu korumak için daha fazla geliştiriciye ihtiyaç duyuyorlar :)
katma yazar Fabio, kaynak
Onlarca yıl önce DOS 2.0'dan DOS 3.0'a yükselttiğimiz bir mağazada çalıştım. İlk versiyonda, içinde her şey bulunan tek bir dizin vardı. İkincisi, alt klasörler tanıtıldı. Patronum, "Neden tüm bu alt klasörlere ihtiyacımız var? Neden her şeyi tek bir klasöre koyamıyorum ki nerede bulacağımı biliyorum?" İyi zamanlar. :)
katma yazar David Lang, kaynak
Tasarım desenleri sadece sürdürülebilirlikle ilgili değil, aynı zamanda yeniden kullanılabilirlikle de ilgilidir.
katma yazar Randy E, kaynak
Dilinizi emmek çünkü ayak parmaklarına basma riski altında. Bunu, olduğundan daha fazla kullanmayın: emici bir dil, çeşitli nedenlerden dolayı çoğu zaman doğru teknik seçimdir, ancak bu, onu emersiz kılmaz. Asıl sorunuza gelince, doğruluk okunabilirlikten daha önemlidir. Ya da biraz daha farklı bir ifadeyle: okunabilirlik, doğruluk hakkında muhakeme yapılmasına olanak sağladığı sürece önemlidir. Peki hangisini test etmek daha kolay, 100 sınıfınız mı yoksa monolitik tanrı sınıfınız mı? 100 basit sınıfla bahse giriyorum.
katma yazar Sujan, kaynak
@SteveJessop evet, sistemi test etmek her iki durumda da aynı şekilde karmaşıktır. Birden çok sınıf durumunda belki daha da fazla. Aradaki fark şudur: yekpare ile bir değişiklik yapmak için nerede bulmak daha kolay olabilirken, bunu yapmaktan kaçabilecek şeyleri sabitlemek için sınırsız bir zaman olabilir. Ayrılmış kod tabanında doğru kod parçasını bulmak daha zor ancak bilinen bir miktardır ve değişikliği yapmak önemsizdir. Zar atmak yerine kendime güvenmeyi tercih ederim ama YMMV ve bir beden hepsine uymuyor. 10k çizgiden daha az olan herhangi bir şey için, monitopu alabilirim . Olabilir.
katma yazar Sujan, kaynak
@Theodoros Chatzigiannakis: Bu sadece dini bir dönüşüm. Sorun, bir yazılım geliştirme metodolojisinin düşünülemeyen ibadetidir. Sadece ilahiyi değiştiriyorsunuz, ancak düşüncesiz kalmayı ritüellere bağlı tutmak.
katma yazar Ruks, kaynak
@Rob Crawford: Re "... 20-30 sınıfa karşılık 600 satırlık karışık kod ...", burada iki alakasız şey var. 600 satırlık net, iyi yorumlanmış bir kod yazmak mükemmel bir şekilde mümkün, tıpkı bunu 20-30 dağınık sınıfa dönüştürmek mümkün.
katma yazar Ruks, kaynak

10 cevap

Bu bir optimizasyon problemi

İyi bir mühendis, optimizasyon sorunununun hedef olmadan anlamsız olduğunu anlıyor. Sadece optimizasyon yapamazsınız, için bir şeyi optimize etmeniz gerekir. Örneğin, derleyici seçenekleriniz hız için optimizasyon ve kod boyutu için optimizasyon içerir; bunlar bazen zıt hedeflerdir.

Karıma, masamın ekler için optimize edilmiş olduğunu söylemek istiyorum. Bu sadece bir yığın ve eşya eklemek çok kolay. Karım, alım için optimize edilmiş olsaydı, bir şeyler bulabilmem için eşyalarımı biraz düzenledi. Bu elbette eklemeyi zorlaştırıyor.

Yazılım aynı. Ürün yaratımı için kesinlikle en iyi duruma getirebilirsiniz - bir ton monolitik kodunu en kısa sürede oluşturabilirsiniz , örgütlenme konusunda endişelenmeden. Daha önce fark ettiğiniz gibi, bu çok çok hızlı olabilir. Alternatif, bakım için optimize etmektir - bir dokunuş yaratmayı daha zor hale getirir, ancak değişiklikleri daha kolay veya daha az riskli hale getirir. Yapısal kodun amacı budur.

Başarılı bir yazılım ürününün yalnızca bir kez yaratılacağını, ancak birçok kez değiştirileceğini öneririm. Deneyimli mühendisler, yapılandırılmamış kod tabanlarının kendi yaşamlarını sürdüğünü ve büyük bir risk yaratmadan çok küçük değişiklikler yapmak çok zor olana kadar boyut ve karmaşıklıkta büyüyen ürünler haline geldiğini gördüler. Kod yapılandırılmışsa, risk bulunabilir. Bu yüzden bu kadar belaya giriyoruz.

Karmaşıklık, unsurlardan değil ilişkilerden gelir

Analizinizde miktarlara, kod miktarına, sınıf sayısına, vb. Baktığınızı fark ediyorum. Bunlar ilginç olsa da, asıl etki, kombinasyonlar halinde patlayan elementler arasındaki ilişkilerden geliyor. Örneğin, 10 işleviniz varsa ve hangisine bağlı olduğuna dair hiçbir fikriniz yoksa, endişelenmeniz gereken 90 olası ilişkiniz (bağımlılıklar) var - on işlevden her biri diğer dokuz işlevden herhangi birine bağlı olabilir ve 9 x 10 = 90. Hangi fonksiyonların hangi değişkenleri veya verinin nasıl aktarıldığını değiştirdiğini hiçbir fikriniz olmayabilir, bu nedenle kodlayıcıların belirli bir sorunu çözerken endişelenecek bir sürü şeyi olabilir. Buna karşılık, eğer 30 sınıfınız varsa fakat akıllıca düzenlenmişlerse, en az 29 ilişki kurabilirler; eğer bir tabakaya katmanlı veya düzenlenmişse.

Bu, ekibinizin verimliliğini nasıl etkiler? Daha az bağımlılık var, sorun çok daha fazla izlenebilir; Kodlayıcılar, her değişiklik yaptıklarında kafasında zillion bir şeylerle uğraşmak zorunda kalmazlar. Bu yüzden bağımlılıkları en aza indirmek, bir problemi ustalıkla yapma yeteneğiniz için büyük bir destek olabilir. Bu yüzden şeyleri sınıflara veya modüllere bölüp değişkenleri olabildiğince sıkı bir şekilde kapsamalı ve KATI ilkeleri.

323
katma
@ jpmc26 En az sayıda sınıf kullanan ve bakımı ve okunması kolay olan önemsiz bir OOP programının (örneğin> 10k loc) bir örneği olabilir mi? Ayrıca kodu okumanın karmaşıklığına da katılmam gerekecek. Kodu bir IDE'ye yüklemeden bile, RestoreRunner.RunAsync ile RestoreCommand öğelerini takip etmek oldukça kolaydır. Sanırım sorun, NuGets'in basit bir liste değil, bugünlerde PackageReference olan bir ağaç olduğunu ve bu da zihinsel modelinize bir anahtar getiren bir ağaç olduğunu özlemiş olmanız.
katma yazar Kyle Hodgson, kaynak
@Holger Peki Mozilla, tarayıcılarını tamamen yeniden yazmak için ne zaman Firefox'a yeni özellikler eklemeyi bıraktı? Yapmadılar. Elbette kodun bölümlerini değiştirebildiğinizden ve doğal bir evrim geçirdiğinizden emin olabilirsiniz ancak tam bir yeniden yazma zehirdir (IE6 ile 8 arasında MS yapan diğer firma .. Netscape'ten daha iyi çalışmadı)
katma yazar Kyle Hodgson, kaynak
@Holger Bugün "yalnızca sıfırdan yazılmış veya o kadar uzun süredir bulunmayan tarayıcıları" iddia ediyorsunuz. Bu açıkça yanlıştır. Sıfırdan yeniden yazılmış ve daha önce olduğu kadar başarılı olan herhangi bir popüler ürünü bulacağınızdan şüpheliyim (bahsettiğiniz örnek doğru olmadığından, daha iyisini bildiğinizden şüpheliyim). Netscape'ten beri benzer bir şey yapan tek tarayıcı satıcısı IE6'dan sonra Microsoft'du. Ve% 90 çoğunluğundan küçük bir oyuncuya geçtiler ve tarayıcıyı gezegendeki en popüler işletim sistemi ile bir araya getirmelerine rağmen ... büyük bir başarı.
katma yazar Kyle Hodgson, kaynak
Sıfırdan ve ikinci sistem sendromundan yeniden yazmak, bir ürünü öldürmenin kesin bir yoludur, bu yüzden hala etrafta kimse bunu yapmıyor. Yaptığınız şey, yeni özellikleri uygularken mevcut kodu iyileştirmektir. Veya uygulamanın küçük parçalarını ihtiyaç bazında yeniden yazmaya karar verebilirsiniz (genellikle güvenlik veya performans, çok nadiren bakım kolaylığı). Ama sıfırdan bir yeniden yazma? Joel makalesi, bunun bu kadar kötü bir fikir olmasının birçok nedeni var.
katma yazar Kyle Hodgson, kaynak
Bununla birlikte, fazla sayıda sınıf ve dolaysızlığın NOR bakımının anlaşılmasında yardımcı OLMADIĞINI not ederim. Ve kıvrılmış kontrol akışları da (aka, geri arama cehennemi).
katma yazar Owen, kaynak
"Alternatif, bakım için optimize etmektir - bir dokunuş yaratmayı daha zor hale getirir, ancak değişiklikleri daha kolay veya daha az riskli hale getirir. Yapısal kodun amacı budur." Daha fazla sınıf = daha fazla sürdürülebilirlik olduğu fikrine kapılıyorum. Özellikle, birçok sınıfa saçılma mantığı çoğu zaman kodda genel olarak mantıksal kavramları bulmayı zorlaştırır (özellikle kavramların görünür olmasını sağlamak için çok kasıtlı bir göz olmadan).
katma yazar jmibanez, kaynak
Bunun için Go-to örneğim yakın zamanda NuGet'in geri yükleme komutu . Geri yüklemenin üç temel adımı vardır: paket listesini okuyun, indirin ve ardından diske çıkartın. Bu adımların her birinin kesinlikle karmaşıklığı olmasına rağmen, kısmen göreceli olarak çok sayıda nesne nedeniyle ve kısmen de bu kavramların ortaya çıkmadığı gerçeğinden dolayı, kodda bunların nerede uygulandığını bulmak oldukça zor. adlandırma ve organizasyonda bir öncelik olmuştur.
katma yazar jmibanez, kaynak
@Voo Komutu hangi nesnenin başlattığını bulmakta zorlandım; hepsi komut satırı ayrıştırma OO yaklaşımı ile karıştırdı. Bunun RestoreRunner olduğunu anladığınızda, "isteklerinin" nasıl oluşturulduğunu izlemeye çalışırsınız; bu, okuyorsam, bir sağlayıcı nesnesine yapılan çağrıda sonuçlanan yaklaşık 4 yöntem çağrısı ile sizi yönlendirir. O doğru. Bir ağaç bulmak şaşırtıcı değildir, ancak sadece onu bulmak çok fazla katman içerir. Zeki değilim Arkasındaki niyetini ortaya çıkarmak için özenle hazırlanmış kodu seviyorum ve buradaki nesne merkezli yaklaşım zayıf soyutlamaları daha da şiddetlendiriyor.
katma yazar jmibanez, kaynak
@JohnWu NuGet modüler olmakta oldukça zorlanıyor. Yan kütüphaneleri ( NuGet.Frameworks gibi) Tamamen belgesiz (Yapımlarının kaynağını bile bulamadım.), komut satırı aracı VS eklentisinin işlevselliğinin çoğunu kaçırıyor ve koda bakarak sadece çok fazla nesne oluşturma gereği duyuyor tek parça çalışabilmek için, herhangi birisini kullanmak için tüm kod tabanını çok geniş bir şekilde anlamanız gerekir. Zaten etkili bir şekilde monolitik, bu yüzden tartışmanızı almıyorum.
katma yazar jmibanez, kaynak
@JohnWu Bunun dışında, yaygın kalıplara yönelik görünüm. DI dini olarak kabul edilir. Hiçbir DI destekçisi, "DI'nin çözmenin neye benzediği gibi bir problem var" diyor, "OO kodunu yazmalısın ve bu, DI'nin olması gerektiği anlamına geliyor. Ve oh, btw, SOLID ilkelerini izlemelisin. ." Neredeyse hiç kimse bu fikirlerin gerçekte çözmesi gereken sorunlardan bahsetmiyor. Onlar sadece sözde her zaman geçerli kurallar olarak teklif edilir.
katma yazar jmibanez, kaynak
@ R.Schmitz Gerçekten iyi programcılar her şeyden önce kurallar açısından düşünmüyorlar. Problem çözme açısından düşünüyorlar. Daha da önemlisi, iyi programcılar diğer programcıların zaten o zihniyette düşünmediğini ve kuralları belirtmek yerine, ona doğru itmediğini fark eder.
katma yazar jmibanez, kaynak
@ R.Schmitz Gerçekten de iyi programcıların düşünceyi tersine çevirdiğini söylüyorum. "Kodunuzu okunabilirlik için optimize etmelisiniz" diye düşünmüyorlar. "Zamanla veya diğer geliştiriciler tarafından değişiklik yapmak için kodu anlayabilme sorununu çözmemiz gerekiyor" diyorlar. İlki, sorunu açıklamadan bir çözüm getirmektedir. İkincisi, sorunu belirtir ve farklı çözümlere açık kalır ve başardığınızda ya da başaramadığınızda daha net olduğu bir amacı vardır (hala öznel olsa da).
katma yazar jmibanez, kaynak
Kombinatoryal için tam 10 × 10 = 100'ü seçerdim: bu fonksiyonlar özyinelemede açıkça değil, özyinelemeli ve özellikle kötü kodda olabilir.
katma yazar LessIsMore, kaynak
İyi yazılmış, ancak "bir kez yaratıldı, ancak birçok kez değiştirildi" nin neden önemli olduğu belki de eksik mi? (Kodun tamamı EntityTransformationServiceImpl konumundaysa, düzeltmeden önce her şeyin nasıl çalıştığını öğrenmek zorunda kalırsınız - ancak örneğin biçim ve Formatter sınıfı, yalnızca bu parçanın nasıl çalıştığını öğrenmeniz gerektiğini öğrenmeniz gerekir. Ayrıca, ~ 3 ay sonra kendi kodunuzu okumak yabancının kodunu okumak gibidir.) Bilinçaltımızda bunu düşündük, ama bu deneyim yüzünden olabilir. Bundan% 100 emin değil.
katma yazar R. Schmitz, kaynak
@Holger Hayır, çünkü yeni kod eklerken, önceki kod yazma standartlarınız kadar önemli değildir. Yazılım , kod eklemeyi çok pahalı yaparsa, bu sadece karışık koddur. Mükemmel bir modüler projeye sahip olabilirsiniz ancak bazı hızlı ve kolay kodlar ekleyebilirsiniz. Ayrıca, tek bir tanrı sınıfında bütün bir programa sahip olabilirsiniz, ancak daha sonra eklemenizi nasıl sürdürüleceği konusunda biraz düşünün. Bahsettiğiniz şirketler ile ilgili olarak, yalnızca bir tane duydum ve Netscape olarak adlandırıldı .
katma yazar R. Schmitz, kaynak
@Holger Bir şirket bir kod tabanını yeniden yazmayan yeni bir ürün yaratıyorsa, ilk etapta yaratıyor . Aksi taktirde, bugünün AutoCAD ve 3DSMax vb .lerinin 1968 UNISURF ve Call of Duty: Modern Warfare 3'ün sadece "yeniden yazıldığını" iddia ediyorsunuz. Ayrıca bunun olmayacağını da söylemiyorum, sadece bu durumlarda olmasa daha iyi sonuçlanabileceğini.
katma yazar R. Schmitz, kaynak
@Holger Söylediklerimin yanı sıra bir yeniden yazmanın yanlış olduğu hakkındaki yorumlarınız. Duty Call, DOOM'un bir yeniden yazımı değil . Tamamen farklı bir geliştirici tarafından tamamen farklı bir ürün. Elbette, her kod parçasının sadece yazılmış ilk kodun sadece bir tekrarı olduğunu söyleyebilirsiniz, ancak kelime herhangi bir pratik anlamını kaybeder ve muhtemelen buraya bir soru gönderin .
katma yazar R. Schmitz, kaynak
@Holger Look, Firefox 2004 yılında 14 yıl yayınlandı; 2007 yılında Android, bu 11 yıl. BT'de, bu sadece eski değil, eski . Teorinize göre, Firefox'un "modası geçmiş, yamalı" (aynı zamanda), 2006 yılına kadar kullanılamaz bir karmaşa ya da 2010 civarında Android olması gerekirdi. hemen hemen her açıdan - güvenlik, kullanılabilirlik, özellik kümesi, siz adlandırın. Korunabilir koda karşı kişisel bir gündeminiz var gibi gözüküyor.
katma yazar R. Schmitz, kaynak
@ jpmc26 Çünkü iyi programcılar tüm "kuralların" pragmatik olarak uygulanması gerektiğini biliyorlar; tüm kurallar otomatik olarak "sonunda gerçekten iyi bir nedeniniz varsa" hariç . Pragmatik yerine dogmatik olan insanlarla çalışıyorsanız, herhangi bir kuralı için bu kötü olacaktır.
katma yazar R. Schmitz, kaynak
@Holger Yine yanlış, ilk açıklamanız " yazılımı yaratmayı korkunç derecede pahalı kılacak şekilde tasarlandı, bu yüzden bu tamamen eski, yamalı karışıklığın ölmesi gereken noktaya ulaşana kadar saklamak ve sürdürmek zorundayız. "Bağlandığım makale, yeniden yazmanın neden ilgileniyorsanız neden kötü olduğu konusunda size daha fazla bilgi verebilir. İlk açıklamanızın Firefox ve Android tarafından yanlış olduğu kanıtlandı. Ondan sonraki her şey, sadece yorumlar için olmayan bir tartışmadı, bu yüzden şimdi burada duralım.
katma yazar R. Schmitz, kaynak
@Holger [A] önemli olabilir çünkü [B] [C] 'ye neden olabilir. Bu sizin "uygulayabileceğiniz" şeydir. Sahip olduğunuz teori, [B] 'nin [C]' ye sebep olduğudur. Hızla uygulanmadığı iki büyük örnek, [B] 'nin [C]' ye yol açmadığını kanıtlar. Amacınız başka bir şeyse, o zaman bunu ispat etmedim ve yalnızca sizin bulunduğunuz yerlerden birinin yanlış olduğunu gösterdim.
katma yazar R. Schmitz, kaynak
@ jpmc26 "Kurallar" ı tırnak içine koydum, çünkü bunlar kurallar . Bir kural "Yapmalısınız" ile başlayamaz. Eğer biri " kodunuzu okunabilirlik için optimize etmelisiniz " veya " gibi, ekibinizin kod kurallarını takip etmelisiniz " gibi temel kurallara uymuyorsa bile "Yapmamak için gerçekten iyi bir nedeniniz varsa"), o zaman bir " gerçek programcı "" gerçekten iyi bir programlayıcı "dan.
katma yazar R. Schmitz, kaynak
@ jpmc26 Yeterince adil, ancak 5 neden "soruyu takımın kod sözleşmelerine uyman gerekir" dendikten sonra sormak kariyerin için iyi değil. Bazen her zaman açıklama eklemek çok açık.
katma yazar R. Schmitz, kaynak
@ jpmc26 "Daha fazla sınıf = daha fazla bakım olabilir = 'kavramına dikkat ediyorum." Elbette, "daha" ın işleyişinin ne olduğuna bağlı. Bu durumda, "50K LOC karışık kod" dür. Bu yüzden, OP'nin görevinin özel bağlamında hemfikir olduğuma emin değilim.
katma yazar John Wu, kaynak
Nuget muhtemelen mükemmel bir örnek değil, çünkü modülerliği, mimarın aşırı istekliliğinden ziyade dış gereksinimler tarafından yönlendirilebiliyor çünkü sonuçta, Visual Studio eklentisinde PowerShell komut dosyası olarak çalışan genişletilebilir çerçeveleri yönetmek için genişletilebilir bir çerçeve. Şimdi düşünüyorum da, eğer bütün bu şeyler monlitik yazılmışsa, Nuget bile olamazdı.
katma yazar John Wu, kaynak
@Holger Gönderimde iki olası optimizasyon hedefini tartışıyorum. Kesinlikle diğer hedefler için de optimizasyon yapabilirsiniz. "yeniden yazma sayısını en aza indirgeme" (bu, bakım kolaylığı için optimizasyona çok benzer) veya ürün oluşturma kolaylığı için optimizasyona benzeyen ancak aynı olmayan (yeniden yazma uyumluluğu için optimizasyonla aynı olmayan) özellik paritesi). Bir hedef yazmıyorum, sadece dikkatlice tasarımın gerekçesini açıklamanın bir aracı olarak, farklılıkları vurgulamak istiyorum.
katma yazar John Wu, kaynak
@Talqu "tasarım kalıplarını her şekilde ve her ne pahasına olursa olsun bulmak." Bir tasarım kararı (çıktı) gibi değil, bir tasarım hedefi (girdi) gibi geliyor. İstediğiniz çıktıları bir optimizasyon girişine önceden yüklerken, işlem fazla değer katmıyor (endojenlik testinde başarısız oluyor), a.k.a. Mimarınız, "Her zaman kötü olan bir" Evcil Hayvan NFR "gibi bir şeye sahip.
katma yazar John Wu, kaynak
@JohnWu bu açıklama okuduğumdan birisini anlamanın en iyi ve kolay yolu.
katma yazar Les H, kaynak
İlk önce kodlamayı öğrendiğimde, bir sınıf içinde bir program yazdım, iyi çalıştı, ancak basit bir değişiklik yapmanın düzeltmem birkaç gün sürecek 4 veya 5 hata getireceği noktasına geldi. Tasarımı araştırmaya başladım ve her şeyi yaklaşık 10 sınıfa ayırdım ve bakım problemlerim ortadan kalktı. Bu yansıtıcıdan sonra ortaya çıkan 0 hata ile birçok değişiklik yaptım. Bunun bir dersin neden buna değer olduğunu gerçekten anlamanın zor yolunu öğrenmek zorunda olduğunu düşünüyorum.
katma yazar reggaeguitar, kaynak
@En az sayıda sınıf tanımına dayanan voo. Binlerce sınıftan oluşan bir uygulamamız var, yine de, yaygın olarak kullanılan bazı çerçeveleri kullanıp kullanmadığımızı ve “en iyi uygulamaların” yirmi katı olduğunu biliyoruz…
katma yazar Holger, kaynak
@ R.Schmitz bu ilginç bir nokta. “Bir kez yaratıldı, ancak birçok kez değiştirildi” önemli olabilir çünkü yazılım çok pahalı bir şekilde üretilebilecek şekilde tasarlandı, bu nedenle, tamamen bu noktaya ulaşana kadar saklamamız ve sürdürmemiz gerekiyor modası geçmiş, yamalı karışıklık ölmek zorunda. Bu modeli herkes takip etmiyor. Yeni sürümün geliştirilmesinin başladığı, sıfırdan yazılmış, önceki sürümün geliştirilmesinden öğrenilen tüm derslerin yanı sıra yeni gelen teknolojilerin kullanıldığı bir yazılımın piyasaya sürüldüğü şirketler de her zaman vardır.
katma yazar Holger, kaynak
@ R.Schmitz, o zamanın tüm tarayıcılarının, örneğin; Internet Explorer, hala var olanı adlandırmak için? Sizce, bugünün tarayıcılarından kaçının hala buna dayandığını düşünüyorsunuz? Bugün, o zamandan beri sıfırdan (birden fazla kez) yeniden yazılmış ya da o kadar uzun süredir bulunmayan tarayıcılar var. Bir teori dünyasında, ilk tarayıcı modüler, genişletilebilir, geleceğe dönük bir şekilde, geleceğin getireceği değişiklikler için hazır olarak yazılmış olabilirdi. Gerçekte değil. Gereksinimler ve teknolojiler çok fazla değişiyor.
katma yazar Holger, kaynak
@ R.Schmitz, eğer daha iyi olacağını söylüyorsunuz, eğer "Görevin Görevi: Modern Savaş 3", Doom'un kaynak koduna dayanıyorsa ve bunun, Doom'un kötü yazılım tasarımının bir işareti olduğunu gösteriyorsa 't? Yoksa eski yazılımın yenisiyle değiştirileceğini, eski yazılımın sonsuz bir şekilde güncellenmesi bir yanılsama olacağına dair bir fikrim var mı?
katma yazar Holger, kaynak
@Voo Tüm yazılım geliştiricilerin bunu yaptığını iddia ettiğim yeri göremiyorum. Belki de haklısınız ve Firefox Netscape için yeniden tasarlanandan başlayarak yeniden hayatına başladıktan sonra sıfırdan yeniden tasarlanmamıştır. Belki de bu, Firefox'un ne kadar iyi tasarlandığının bir işaretidir. Ya da belki de, Firefox’un kalitesi gerçekten tartışmalı olarak algılandığından, bir alev ateşine başlamak üzeresiniz. Solucan konservesini açmayın.
katma yazar Holger, kaynak
@ R.Schmitz, bu noktayı tamamen kaçırmışsınız gibi görünüyor. Yeni yazılımın eski bir ürünün tamamen yeniden yazılması veya tamamen yeni bir ürün olması sorun değil. Mesele şu ki, eskisinin bakımının ne kadar kolay olduğu önemli olmayan, yeni bir yazılımdır. Şimdi anladın mı? Eski yazılım ölecek. Eski yazılım yenisiyle değiştirilecektir. Bu kaçınılmaz bir gerçek. Yalnızca yenisinin sizin mi yoksa rakiplerinizin mi olduğunu etkileyebilirsiniz. Ancak, yazılımınızı bakım için optimize edebilir, yeni yazılım geliştirmeyi pahalılaştırabilir ve sonsuza dek yenisini yazmaktan kaçınmayı deneyebilirsiniz…
katma yazar Holger, kaynak
@Voo tam olarak, Microsoft tarayıcılarını sıfırdan baştan yazan tek kişiydi. Şimdi, o sırada varolan (Netscape 4 veya daha önceki) Microsoft'tan, bugün hala varolan (büyük bir yeniden yazma yapılmadan, başka bir deyişle, yine de Mozaik koduna dayanan), herhangi bir tarayıcıyı adlandırın. Aslında, Netscape de bir yeniden yazma yaptı ancak bunu Firefox'un geliştirilmesine neden olan Mozilla vakfına yaptırdı. Böylece yeniden yazmak ürünü öldürdü, çünkü yenisini doğurdu. Eski kodu temel alan bir Netscape tarayıcısının bugün hala mevcut olabileceğini düşünüyor musunuz? Mozilla aynı fikirde değildi.
katma yazar Holger, kaynak
@JohnWu optimizasyonu tarif etme şekliniz, değişen hedeflerin bir fonksiyonunun çok iyi olması, buna itiraz etmiyorum. Bu gerçekten iyi bir cevap.
katma yazar Holger, kaynak
@ R.Schmitz, Firefox’un ana sponsoru bir keresinde, Firefox’a dayalı değil, Chrome adlı kendi tarayıcısını yazmaya karar verdi. Firefox eskidir. Ancak, neyi kanıtlamak istiyorsunuz? İlk açıklamam bugün, hiçbir tarayıcının Mosaic'e dayanmadığıydı, çünkü mevcut tüm tarayıcılar ya o zamandan beri tamamen yeniden yazılmış ya da bundan çok daha küçüklerdi. Mosaic’in 1993’ten beri olduğu düşünülürse, Firexfox bundan çok daha gençtir. Yani beni yanlış kanıtlamadın. Bunun yanında, korunabilir bir koda karşı değilim, bunu asla söylemedim. Aksine, yalnızca büyümeyi bilen koda karşıyım.
katma yazar Holger, kaynak
@ R.Schmitz, bu cümleyi bağlam dışına çıkarıyorsunuz. Cümle “ once bir zamanlar yaratıldı ama birçok kez değiştirildi”, önemli olabilir çünkü yazılım çok pahalı bir şekilde yaratmayı sağlayacak şekilde tasarlandı… ”. Yazılım projelerinin bir miktarına uygulanabilecek bir model hakkında bir spekülasyon. Kiraz toplama yazılımı hakkında bir tartışma açarak, ölmüş tüm milyarlarca yazılımı yok sayarak, çok uzun süredir korunan iki örnek IIRC'yi şimdiden kaçırdınız. Bu spekülatif ifadenin sadece iki örnekle “yanlış olduğu kanıtlanmamıştır”.
katma yazar Holger, kaynak
Harika cevap ama ..: Alternatif bakım için optimize etmektir , bunun sadece bir OP olduğunu ve OP'nin şikayetçi olduğu anlamına gelir. Ayrıca, tasarım modellerini her şekilde ve her ne pahasına olursa olsun bulmak için optimizasyon vardır . Anahtar kelime akıllı ve yalnızca çok sayıda sınıf oluşturarak verilen bir şey değil. DI, bilge bir insanın yazdığı gibi, 100 dolarlık kelimeler için 50 c'lik bir konsept elde ettiğiniz harika/korkunç bir örnektir.
katma yazar pong, kaynak
İyi bir cevap, ancak göz ardı edici bir ihmal ile: "600 satırlık karışık kodun" doğru bir şekilde test edilememesi ve OP'nin savunuculuğu yaklaşımı için tek başına bir anlaşma kırıcı olması muhtemeldir.
katma yazar Nath, kaynak

Öncelikle, okunabilirlik ve bakım sürdürebilirlik genellikle bakanın gözündedir.

Size okunabilir olan şey komşunuza olmayabilir.

Bakım kabiliyeti genellikle keşfedilebilirliğe (kod tabanında keşfedilen bir davranış veya kavram ne kadar kolay) azalır ve keşfedilebilirlik başka bir öznel şeydir.

DDD

DDD'nin geliştirici ekiplerine yardım etmesinin yollarından biri, kod kavramlarınızı ve davranışlarınızı organize etmenin özel (henüz öznel) yöntemini önermektir. Bu sözleşme bir şeyleri keşfetmeyi ve dolayısıyla uygulamayı sürdürmeyi kolaylaştırır.

  • Etki alanı kavramları, Varlıklar ve Toplamlar olarak kodlanır
  • Etki alanı davranışı Varlıklar veya Etki Alanı Hizmetlerinde bulunur
  • Tutarlılık Toplam Kökler tarafından sağlanır
  • Kalıcılık endişeleri Depolar tarafından ele alınmaktadır

Bu düzenlemenin nesnel olarak yapılması kolay değildir. Ancak, herkes DDG bağlamında çalıştıklarını anladığı zaman bakımı ölçülebilir bir şekilde daha kolaydır.

Sınıflar

Sınıflar help with maintainability, readability, discoverability, etc... because they are a well known convention.

In Object Oriented settings, Sınıflar are typically used to group closely related behaviour and to encapsulate state that needs to be controlled carefully.

Kulağa çok soyut geldiğini biliyorum ama bu şekilde düşünebilirsiniz:

With Sınıflar, you don't necessarily need to know how the code in them works. You just need to know what the class is responsible for.

Sınıflar allow you to reason about your application in terms of interactions between well defined components.

Bu, uygulamanızın nasıl çalıştığını düşünürken bilişsel yükü azaltır. 600 satır kodun ne yaptığını hatırlamak zorunda kalmak yerine, 30 bileşenin nasıl etkileşimde bulunduğunu düşünebilirsiniz.

Ayrıca, bu 30 bileşen muhtemelen uygulamanızın 3 katmanını kapsar, muhtemelen her biriniz bir seferde yaklaşık 10 bileşen düşünmeniz gerekir.

Bu oldukça yönetilebilir görünüyor.

özet

Temel olarak, kıdemli devlerin yaptıklarını görüyorsunuz:

They are breaking down the application into easy to reason about Sınıflar.

Daha sonra bunları katmanlar hakkında kolay anlaşılır olarak düzenliyorlar.

They are doing this because they know that, as the application grows, it becomes harder and harder to reason about it as a whole. Breaking it down into Layers and Sınıflar means that they never have to reason about the entire application. They only ever need to reason about a small subset of it.

64
katma
Küçük sınıfların yanı sıra değiştirilmesi/refaktörü kolaydır.
katma yazar Pieter, kaynak
"Sınıflar ile, içlerindeki kodun nasıl çalıştığını bilmek zorunda değilsin. Sadece sınıfın neden sorumlu olduğunu bilmen gerekiyor." Sınıflar kesinlikle bunu başarmanın tek yolu değildir, ancak bazı durumlarda yararlı bir yol olabilirler. Daha önemlisi, buna rağmen, bunu sağlayan sınıfları kullanmıyor, bunu yapan bir geliştirici tarafından iyi tasarım seçenekleri . Sınıflar, size bunu yayan bir büyü sosu değildir.
katma yazar jmibanez, kaynak
“Düşüncelerini, akıl yürütmelerini düşünmekle çok mücadele eden” OP'ye göre, mantıklı olması kolay bir kod oluşturmanın arkasındaki mantığın mantıklı olması kolay değil gibi görünüyor.
katma yazar Erb, kaynak
Evet, aşırı mühendislik yapmak kötü. Yani yavru öldürüyor. Buradaki hiç kimse ikisini de savunmuyor. logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/169/ ve hellip;
katma yazar Warpspace, kaynak
Ayrıca, yazılım mühendisliği bağlamında "şıklık" genellikle bir Gelincik Sözüdür. en.wikipedia.org/wiki/Weasel_word
katma yazar Warpspace, kaynak
Aynı kural düzenleme için herhangi bir yaklaşım söylenebilir. Her şey bakım ekibine bağlı olarak kodun neden bu kadar organize olduğunu anlar. Bu, iyi kurulmuş ve anlaşılmış sözleşmeler kullanmanın esas noktasıdır.
katma yazar Warpspace, kaynak
@ jpmc26 Kabul ediyorum, sınıflar sihir değil. Bununla birlikte, kapsülleme ve kamu sözleşmeleri gibi konularda genellikle dil düzeyinde destek sunarlar.
katma yazar Warpspace, kaynak
@ icc97, deneyim, bağlam ve sözleşmelerin ve kalıpların bilgisinin, çok büyük bir fark yarattığını söylemiş gibi görünüyor. Ve küçük bir devin, bu şeyleri göz önünde bulundurarak, bu şeylerle yazılmış kuralları yazmasını zorlaştırabilir.
katma yazar Warpspace, kaynak
Aşırı mühendislik, iddia ettiğiniz şeye rağmen, tam tersi bir şekilde değil daha sürdürülebilir veya anlaşılabilir bir kod verir. Sorunu daha zarif bir şekilde çözebildiğiniz zaman kime bir AddressServiceRepositoryProxyInjectorResolver gerekir? Tasarım desenleri uğruna tasarım kalıpları sadece gereksiz karmaşıklığa ve ayrıntılara neden olur.
katma yazar Ian Yates, kaynak
Mükemmel cevap! Seninle aynı fikirde olmayan yorumlara şaşırdım
katma yazar reggaeguitar, kaynak
Eğer önce onu sınıflara bölüştürüyorlarsa ve sonra bu sınıfları katmanlara birleştiriyorlarsa, işlerin dağınık olması şaşırtıcı değildir. Bunu tersi yönde yapmak istersiniz (ayrıca, başlamak için sınıfları tanıtmak istersiniz).
katma yazar Clearer, kaynak
ve sonra tüm kalıbı kırmak için sadece bir İngiliz anahtarı gerekir
katma yazar user2890248, kaynak

Lütfen bana açıklayın, neden bu DDD stiline, bir çok Desene ihtiyacımız var?

Birincisi, not: DDD'nin önemli kısmı kalıpları değil, geliştirme çabalarının işletme ile uyumlaştırılmasıdır. Greg Young, mavi kitaptaki bölümlerin yanlış sipariş içinde olduğunu belirtti.

Fakat sizin özel sorunuza göre: beklediğinizden çok daha fazla sınıf olma eğilimindedir, (a) çünkü alan davranışını sıhhi tesisattan ayırt etmek için çaba harcanmaktadır ve (b) çünkü bu kavramları sağlamak için fazladan çaba sarf edilmektedir. etki alanı modelinde açıkça ifade edilir.

Açıkça, etki alanında iki farklı kavramınız varsa, aynı şeyi bellek temsilinde paylaşsalar bile modelinde farklı olmalıdırlar .

Aslında, bir iş alanı uzmanının ona bakabilmesi ve hataları tespit edebilmesi için modelinizi işletme dilinde tanımlayan bir alana özgü dil oluşturuyorsunuz.

Additionally, you see a bit more attention paid to separation of concerns; and the notion of insulating consumers of some capability from the implementation details. See D. L. Parnas. The clear boundaries empower you to change or extend the implementation without the effects rippling throughout you entire solution.

Buradaki motivasyon: Bir işletmenin temel yetkinliğinin bir parçası olan bir uygulama için (rekabet avantajı elde ettiği bir yer anlamına gelir), etki alanı davranışını daha kolay ve ucuz bir şekilde değiştirerek daha iyi bir çeşitliliğe sahip olmak isteyeceksiniz. Aslında, programın hızlı bir şekilde gelişmesini istediğiniz (zaman içinde durumun nasıl geliştiği) ve yavaşça değiştirmek istediğiniz diğer kısımların (durumun nasıl kaydedildiği); Ekstra soyutlama katmanları yanlışlıkla bir diğerine birleşmekten kaçınmaya yardımcı olur.

Adalet içinde: bir kısmı da Nesneye Yönelik Beyin Hasarı. Başlangıçta Evans tarafından açıklanan desenler, 15+ yıl önce katıldığı Java projelerine dayanıyor; durum ve davranış, bu tarz ile sıkı sıkıya bağlantılıdır; bu, kaçınmayı tercih edebileceğiniz komplikasyonlara yol açar; Stuart Halloway tarafından Algı ve Eylem başlıklı konuya veya bkz. href = John Carmack tarafından "http://number-none.com/blow/john_carmack_on_inlined_code.html" rel = "noreferrer"> Inlining Code .

Hangi dilde çalışıyor olursanız olun, işlevsel bir tarzda programlama fayda sağlar. Uygun olduğunda ne yapmalı ve ne zaman uygun olmadığı konusunda karar vermeyi düşünmelisiniz. Carmack, 2012

29
katma
Bence buradaki en iyi cevap bu. DDD'de hiçbir şekilde satılmadığım halde, bu cevap kesinlikle en azından hiçbir şey ifade etmeyen ortak pratiklere başvurmak yerine, gerçekte ne olduğunu ve bunun için gerçek bir motivasyonu açıklıyor.
katma yazar jmibanez, kaynak
John Carmack harika bir örnek IMO, çünkü hem temiz hem de anlaşılması kolay ve aynı zamanda iyi bir performans gösteren kod yazması ile tanınıyor. Bu, özellikle ilerleyen teknolojilerle kodunu takip ettiğinizde görülebilir - daha iyi CPU'lar ve belleğe sahip, "bu gerçekten ciddiyetli olmak zorunda" dır. ". Tanıdığım en pragmatik programcılardan biri :)
katma yazar Luaan, kaynak
Bunu okuyana kadar kendi cevabımı ekleyecektim. İlk paragrafı vurgulamak isterim; amaç, yazılımı iş gereksinimlerine uygun hale getirmek için iş kavramlarını yazılımda modellemektir. Adil olmak gerekirse, projeyi yürüten analist teslimat süresinin ne kadar sürdüğünü de ifade etmeli ve kod/test kalitesi veya tamlığı buna göre ayarlanmalıdır.
katma yazar Sentinel, kaynak

Diğer cevaplarda birçok iyi nokta var, ancak yaptığınız önemli bir kavramsal hatayı kaçırdıklarını veya vurgulamadıklarını düşünüyorum:

Tüm programı anlama çabasını karşılaştırıyorsunuz.

Bu, çoğu programda gerçekçi bir iş değildir. Basit programlar bile o kadar çok koddan oluşuyor ki, her şeyi kafanın içinde herhangi bir zamanda yönetmek imkansızdır. Tek şansınız, elinizdeki görevle ilgili bir programı bulmak (bir hatayı düzeltmek, yeni bir özellik uygulamak) ve bununla çalışmak.

Programınız çok büyük fonksiyonlardan/yöntemlerden/sınıflardan oluşuyorsa, bu neredeyse imkansızdır. Bu kod grubunun sorununuzla ilgili olup olmadığına karar vermek için yüzlerce kod satırını anlamanız gerekir. Verdiğiniz tahminlerle, üzerinde çalışmanız gereken kod parçasını bulmak için bir hafta harcamak kolaylaşır.

Bunu, belirli bir mantık parçasını nerede bulacağınızı/koyacağınızı açıklığa kavuşturan, paketler/ad alanları şeklinde adlandırılmış ve düzenlenmiş küçük işlev/yöntemler/sınıflarla bir kod tabanına karşılaştırın. Pek çok durumda, probleminizi çözmek için doğru yere doğru atlayabilirsiniz ya da en azından hata ayıklayıcınızı ateşlemenizin bir kaç şerbetle sizi doğru noktaya getireceği bir yere atlayabilirsiniz.

Her iki sistemde de çalıştım. Fark, karşılaştırılabilir işler ve karşılaştırılabilir sistem boyutu için performanstaki iki büyüklük derecesi kolayca olabilir.

Bunun diğer faaliyetler üzerindeki etkisi:

  • test, daha küçük ünitelerle daha kolay hale gelir
  • daha az birleştirme çakışması çünkü iki geliştiricinin aynı kod parçasında çalışma şansı daha küçük.
  • daha az çoğaltma, çünkü parçaları yeniden kullanmak daha kolaydır (ve parçaları ilk etapta bulmak).
26
katma

Çünkü test kodu kod yazmaktan daha zor

Bir çok cevap, geliştiricinin bakış açısından iyi bir akıl yürütme sağladı - kodu, ilk etapta yazmaya daha yorucu hale getirme pahasına, bakım azaltılabilir.

However, there is another aspect to consider - testing can only be fine-grained as your original code.

Her şeyi monolitte yazarsanız, yazabileceğiniz tek etkili test "bu girdiler verildiğinde çıktı doğru mu?" Olur. Bu, bulunan herhangi bir hatanın "o devasa kod yığınında bir yere" dahil edildiği anlamına gelir.

Tabii ki, daha sonra bir geliştiricinin bir hata ayıklayıcıyla oturmasını ve sorunun tam olarak nerede başladığını ve bir düzeltme üzerinde çalışmasını sağlayabilirsiniz. Bu çok fazla kaynak gerektirir ve geliştiricinin zamanının kötü kullanılmasıdır. Şimdiye kadar gördüğünüz en küçük hatanın, tüm programın tekrar hata ayıklanmasına ihtiyaç duyan bir geliştirici ile sonuçlandığını hayal edin.

Çözüm: Her biri belirli, potansiyel bir başarısızlığı tespit eden birçok küçük test.

Bu küçük testler (örneğin Ünite Testleri), kod tabanının belirli bir alanını kontrol etme ve sınırlı bir kapsam dahilinde hataları bulmaya yardım etme avantajına sahiptir. Bu sadece bir test başarısız olduğunda hata ayıklamayı hızlandırmakla kalmaz, aynı zamanda tüm küçük testleriniz başarısız olursa - daha büyük testlerinizde arızayı daha kolay bulabileceğiniz anlamına gelir (yani belirli bir test edilmiş fonksiyonda değilse, etkileşimde olmalıdır). onların arasında).

Net olması gerektiği gibi, daha küçük testler yapmak, kod tabanınızın daha küçük test gruplarına ayrılması gerektiği anlamına gelir. Bunu yapmanın yolu, büyük bir ticari kod tabanında, genellikle çalıştığınız şeye benzeyen bir kodla sonuçlanır.

Tıpkı bir not olarak: Bu, insanların "fazla uzağa" bir şey almayacakları anlamına gelmez. Ancak, kod tabanlarını daha küçük/daha az bağlantılı parçalara ayırmanın meşru bir nedeni var - makul şekilde yapılırsa.

19
katma
Cevabınız sadece test ve test edilebilirliği ele alırken, diğer cevapların bazılarının tamamen göz ardı ettiği en önemli konu budur + 1.
katma yazar Nath, kaynak

Lütfen bana açıklayın, neden bu DDD stiline, bir çok Desene ihtiyacımız var?

Birçoğumuz (çoğu ...) çoğumuzun onlara gerçekten ihtiyacı yok . Teorisyenler ve çok gelişmiş, deneyimli programcılar, çok sayıda araştırmanın ve derin deneyimlerinin bir sonucu olarak teoriler ve metodolojiler hakkında kitaplar yazar - bu, yazdıkları her şeyin günlük programlarında her programcı için geçerli olduğu anlamına gelmez.

Küçük bir geliştirici olarak, bakış açınızı genişletmek için bahsettiğiniz kitap gibi kitapları okumak ve sizi belli konulardan haberdar etmek iyidir. Ayrıca, kıdemli meslektaşlarınız aşina olmadığınız terminolojiyi kullandığında sizi utandırmaktan ve aldatmaktan kurtaracaktır. Çok zor bir şey bulursanız ve mantıklı görünmüyor veya yararlı görünmüyorsa, bunun için kendinizi öldürmeyin - sadece kafanızda böyle bir kavram veya yaklaşımın olduğunu gösterin.

Günlük gelişiminizde, akademik değilseniz, işiniz uygulanabilir, sürdürülebilir çözümler bulmaktır. Bir kitapta bulduğunuz fikirler bu hedefe ulaşmanıza yardımcı olmazsa, o zaman çalışmanız tatmin edici olduğu sürece şu an için endişelenmeyin.

Okuduğunuz bazı şeyleri kullanabileceğinizi ancak ilk başta "alamadım" veya belki kullanamadığınızı keşfedeceğiniz bir zaman olabilir.

17
katma
20 yıllık tecrübenizde, hiçbir zaman bir problemin parçası olarak kendisine aynı çözümü sunmadığını mı söylüyorsunuz? Her zaman birbirinizle etkileşime giren iki sınıfınız olduğunda tamamen yeni bir çözüm yarattınız mı? Oldukça iyi, herkes tekrar tekrar kalıplar kullanıyor, kitaplar sadece orada, bu yüzden onlar hakkında konuştuğumuzda onları aynı şekilde adlandırıyoruz.
katma yazar Rob Hunter, kaynak
Saf düzeyde bu doğru olsa da DDD gibi geliyor ve diğer Desenler sadece teori. Onlar değil. Okunabilir ve korunabilir kod elde etmek için önemli araçlardır.
katma yazar Moogie, kaynak
@vikingsteve OP, genel tasarım kalıplarının aşırı kullanımı hakkında yorum yapan bir programlama gurusu değildir. OP bir çıraktır ve dükkanında aşırı kullanıldığını düşünüyor . . Biliyorum ki acemi-ben bugünlerde yazdığım kod hakkında da aynı şeyi düşünürdüm, ama acemi-çok fazla kişisel proje başarısız oldu, çünkü çok karmaşık bir hale geldiler.
katma yazar R. Schmitz, kaynak
@Vektör Bu düzenlemelerin ne kadar iyi olduklarından biraz şaşırdım. Bu benim için kesinlikle "+ 1 gibi görünüyor" ve "% 100 hemfikir" olarak kabul edildi!
katma yazar R. Schmitz, kaynak
@Luaan Zaten iyi tasarlanmış, organize edilmiş, yapılandırılmış, OOP umurunda olsaydın, o acemi-seni zorlukla çağırırdım, ama evet, aşırı kullanım kötüdür. Bununla birlikte, soru, OP'nin bu sorunların hangi sorunları çözdüğünü gerçekten nasıl anlamadığı ile ilgilidir. Sebebini bilmiyorsanız, sebebi yok gibi görünüyor - ama aslında, henüz bilmiyorsunuz.
katma yazar R. Schmitz, kaynak
@JensSchauder - Yorumunuz ışığında cevabı değiştirdim. Basitçe "teori" olarak adlandırmanın genelde yanlış olduğunu kabul ediyorum. "Metodoloji" çok daha uygundur.
katma yazar Vector, kaynak
@ R.Schmitz - Yorumları okudum ve dilimin gerçekten doğru olmadığını ve konumumun biraz aşırı olduğunu anladım.
katma yazar Vector, kaynak
@PeteKirkham OP’lerin ikilemi, tasarım modellerinin aşırı kullanımıdır . Gerçekten bir AccountServiceFacadeInjectResolver (işyerinde yeni bir sistemde bulduğum gerçek örnek) ihtiyacınız var mı - cevap muhtemelen hayır.
katma yazar Ian Yates, kaynak
@ R.Schmitz Dedi ki, başlangıçta bana birçok kişisel proje başarısız oldu, çünkü iyi tasarlanmış, organize, yapılandırılmış, OOP gibi şeyler yapmak için çok çaba harcadılar. Bunların hepsi araç. Düzgün bir şekilde anlaşılmaları ve kullanılmaları gerekir ve vidalamada fakir olduğu için kırıcıyı zorlukla suçlayabilirsiniz. Şaşırtıcı bir şekilde, bu basit şeyi anlamak için çok fazla içgörü ve deneyim gerekiyor gibi görünüyor :)
katma yazar Luaan, kaynak
Tecrübelerime göre garip olan şey, AccountServiceFacadeInjectResolver tipindeki nesneleri DDD kullanmayan kodda daha sık rastlamak. Yay tabanlı uygulamalar neredeyse tamamen tamamen problem alanıyla değil, çerçeveyle doldurma ile ilgisi olan sınıflar gibi görünmektedir.
katma yazar Rob Crawford, kaynak

Sorunuz çok fazla temeli olduğu için, birçok varsayımla birlikte, sorunuzun konusunu açıklayacağım:

Tasarım desenlerinde neden bu kadar çok sınıfa ihtiyacımız var

Biz değil. Tasarım desenlerinde çok fazla sınıf olması gerektiğini söyleyen, genel olarak kabul edilmiş bir kural yoktur.

Kodu nereye koyacağınıza ve görevlerinizi farklı kod birimlerine nasıl keseceğinize karar vermeniz için iki ana yol vardır:

  • Uyum: herhangi bir kod birimi (bir paket, bir dosya, bir sınıf veya bir yöntem olabilir) birbirine ait olmalıdır . Yani, herhangi bir özel yöntemin bir görevi olması ve bunu iyi bir şekilde yapması gerekir. Herhangi bir sınıf, bir daha büyük olan konudan (ne olabilirse) sorumlu olmalıdır. Yüksek uyum istiyoruz.
  • Birleştirme: herhangi iki kod birimi mümkün olduğunca az birbirine bağlı olmalıdır - özellikle dairesel bağımlılıklar olmamalıdır. Düşük eşleşme istiyoruz.

Bu ikisi neden önemli olmalı?

  • Uyum: çok fazla şey yapan bir yöntem (örneğin, GUI, mantık, DB erişimi vb. uzun bir kod karışıklığında tümüyle eski moda bir CGI betiği) hantallaşır. Yazarken, düşünce treninizi uzun bir yönteme koymak çok caziptir. Bu işe yarar, sunması kolay ve böyle bir şey olabilir. Sorun daha sonra ortaya çıkıyor: birkaç ay sonra, yaptıklarınızı unutabilirsiniz. Tepedeki bir kod satırı, alttaki bir satırdan uzakta birkaç ekran olabilir; tüm detayları unutmak kolaydır. Yöntemin herhangi bir yerinde herhangi bir değişiklik, karmaşık şeyin herhangi bir davranışını bozabilir. Yöntemin bölümlerini yeniden incelemek veya yeniden kullanmak oldukça zor olacaktır. Ve böyle devam eder.
  • Eşleştirme: bir kod birimini her değiştirdiğinizde, ona bağlı olan diğer tüm birimleri potansiyel olarak kırabilirsiniz. Java gibi katı dillerde, derleme süresi boyunca (örneğin, parametreler, bildirilen istisnalar vb. Hakkında) ipuçları alabilirsiniz. Ancak birçok değişiklik bu gibi (yani davranışsal değişiklikler) tetikleyici değildir ve diğer, daha dinamik olan dillerde böyle olanaklar yoktur. Bağlantı ne kadar yüksek olursa, herhangi bir şeyi değiştirmek o kadar zorlaşır ve bir hedefe ulaşmak için tam bir yeniden yazmanın gerekli olduğu yerde durma noktasına gelebilirsiniz.

Bu iki yön, herhangi bir programlama diline ve herhangi bir paradigmaya (sadece OO'ye değil) herhangi bir “nereye koyacağına” herhangi bir seçim için temel “sürücüler” dir. Herkes açıkça bunlardan haberdar değildir ve bunların yazılımları nasıl etkilediğine dair gerçekten kökleşmiş, otomatik bir his edinmeleri zaman alır, genellikle yıllar alır.

Açıkçası, bu iki kavram size aslında ne yapılacağı hakkında hiçbir şey söylemez. Bazı insanlar çok fazla, bazıları çok az. Bazı diller (burada size bakmaksızın, Java) dilin kendisinin son derece statik ve bilgiçlik yapısından dolayı birçok dersi tercih etme eğilimindedir (bu bir değer ifadesi değildir, ancak olduğu gibidir). Bu özellikle dinamik ve daha anlamlı dillerle, örneğin ruby ile karşılaştırdığınızda farkedilir hale geliyor.

Diğer bir husus ise, bazı insanların yalnızca şu anda gerekli olan kodunu yazmanın çevik yaklaşımına ve gerektiğinde yoğun bir şekilde yeniden refaktöre abone olmalarıdır. Bu geliştirme tarzında, yalnızca bir uygulayıcı sınıfınız olduğunda bir arayüzü oluşturmazsınız. Sadece somut sınıfı uygularsınız. Daha sonra ikinci bir sınıfa ihtiyacınız olursa, yeniden yönlendirici olursunuz.

Bazı insanlar bu şekilde çalışmıyor. Daha genel olarak kullanılabilecek her şey için arayüzler (veya daha genel olarak soyut temel sınıflar) oluştururlar; bu hızla bir sınıf patlamasına yol açar.

Yine, aleyhte ve aleyhte argümanlar vardır ve hangisini tercih ettiğimin önemi yok. Yazılım geliştirici olarak hayatınızda, uzun spagetti yöntemlerinden, aydınlanmış, yeterince büyük sınıf tasarımlarına, çok fazla incelenmiş inanılmaz derecede gelişmiş sınıf şemalarına kadar tüm uç noktalarla karşılaşacaksınız. Daha fazla tecrübe kazandıkça, "mimari" rollere doğru daha fazla büyüyeceksiniz ve bunu istediğiniz yönde etkilemeye başlayabilirsiniz. Kendiniz için altın bir orta bulacaksınız ve ne yaparsanız yapın birçok insanın sizinle aynı fikirde olmaya devam edeceğini göreceksiniz.

Bu nedenle, açık fikirli olmak, buradaki en önemli kısımdır ve bu, benim için en önemli tavsiyem olacak, konuyla ilgili çok fazla acı çekmiş gibi görünmek, sorunuzun geri kalanını değerlendirmek ...

8
katma

Deneyimli kodlayıcılar şunları öğrendi:

  • Çünkü bu ufacık programlar ve clases, özellikle başarılı olanları büyümeye başlar. Basit bir seviyede çalışan bu basit modeller ölçeklendirilmez.
  • Çünkü her ekleme/değiştirme için çeşitli eserler eklemek/değiştirmek zorunda kalmak zor görünebilir, ancak ne ekleyeceğinizi biliyorsunuzdur ve bunu yapmak kolaydır. 3 dakikalık yazım, 3 saatlik akıllı kodlamayı geçer.
  • Pek çok küçük sınıf "dağınık" değildir, çünkü ek yükün neden iyi bir fikir olduğunu anlamıyorsunuzdur
  • Etki alanı bilgisi eklenmeden, 'bana açık' kodu genellikle ekip arkadaşlarım için gizemlidir ... ayrıca gelecekteki ben.
  • Kabile bilgisi, ekip üyelerini hızlı ve verimli bir şekilde üretebilmeleri için ekip üyelerini eklemeyi inanılmaz derecede zorlaştırabilir.
  • Adlandırma, bilgisayardaki iki zor sorundan biridir, hala doğrudur ve birçok sınıf ve yöntem, çoğu kişinin büyük bir yararı olduğunu belirten adlandırmada yoğun bir alıştırmadır.
7
katma
@vikingsteve Yapılandırılmış kodun genel olarak kötü bir fikir olduğunu kanıtlayacağını umarak hatalı bir uygulamanın tek bir örneğine atıfta bulunuyorsunuz. Bu sadece izlemiyor.
katma yazar Warpspace, kaynak
@Clearer Buradaki herkesin yapısal kodun varsayımsal yanlış uygulanmasının kötü bir şey olduğu konusunda hemfikir olduğuna eminim. OP onların Junior olduğunu söylüyor. İşte bu yüzden insanlar, yapılandırılmış kodun yararlarını bilmediğini ve yinelendiğini varsayıyor.
katma yazar Warpspace, kaynak
Ancak genel gider gerekli mi? Gördüğüm birçok durumda, tasarım desenleri aşırı kullanılıyor. Aşırı esnekliğin sonucu, kodu anlama, sürdürme, test etme ve hata ayıklama zorluğunun artmasıdır. Basit bir hizmet sınıfının (az önce gördüğüm gerçek bir örnek) etrafında 12 sınıf ve 4 maven modülünüz olduğunda, düşündüğünüzden daha kolay yönetilemez hale gelir.
katma yazar Ian Yates, kaynak
@ MetaFight OP yapı kodundan bahsetmiyor. Çok fazla soyutlama olarak gördüğü şeyden bahsediyor. Çok fazla soyutlamanız varsa, iddia ediyorum ki, çok hızlı bir şekilde çok yapılandırılmamış kodlar ve hemen hemen aynı parçalar elde edersiniz, çünkü insanlar başa çıkmak zorunda oldukları şeylerle başa çıkamazlar.
katma yazar Clearer, kaynak

Kullanım başına daha fazla sınıf ve işlev yapmak, sorunları gelecekte çözülmesine yardımcı olacak belirli bir şekilde çözmek için mükemmel bir yaklaşım olacaktır.

Birden çok sınıf, temel çalışmaları olarak tanımlanmasına yardımcı olur ve herhangi bir zamanda herhangi bir sınıf çağrılabilir.

Bununla birlikte, eğer birçok sınıf ve getable adından fonksiyonlarsanız, arama ve yönetmeleri kolaydır. Buna temiz kod denir.

4
katma
Üzgünüm ama ne diyorsun?
katma yazar Shizam, kaynak
Bu cevabın, daha net İngilizce olarak sunmayı iddia ettiği fikrini/fikirlerini sunması gerekir. Cevaptaki temel fikir, her biri iyi tanımlanmış bir işlevselliğe sahip olan küçük sınıfların iyi bir fikir olduğu görünüyor, ancak korkunç dilbilgisi bunu neredeyse imkansız hale getiriyor. Ayrıca, kendi başına bu iddia yeterli olmayabilir.
katma yazar Stefan Kendall, kaynak
@Deduplicator, kalıtımları için jframes thread ve sınıfları kullanıyorsak, java'da bir örnek verelim. Sadece bir sınıftan bazı java eserlerini tasarım için kullanamıyoruz, bu yüzden daha fazla ders yapmamız gerekiyor.
katma yazar David Farrell, kaynak

Şimdiye kadarki cevaplar, hepsi iyi, danışanın da kabul ettiği bir şeyin eksik olduğu varsayımıyla başladı. Ayrıca, askerin temelde haklı olması da mümkündür ve bu durumun nasıl ortaya çıktığını tartışmaya değer.

Tecrübe ve uygulama güçlüdür ve eğer yaşlılar olayları kontrol altında tutmanın tek yolunun bol miktarda EntityTransformationServiceImpl ile olduğu büyük, karmaşık projelerde deneyimlerini kazanırlarsa, tasarım ile hızlı ve rahat olurlar desenleri ve DDD'ye yakınlık. Küçük programlar için bile hafif bir yaklaşım kullanarak daha az etkili olurlar. Garip olanı olarak, uyum sağlamanız gerekir ve bu harika bir öğrenme deneyimi olacaktır.

Yine de adapte olurken, tek bir yaklaşımı derinlemesine öğrenme arasındaki dengede bir ders olarak almalısınız, her yerde çalışmasını sağlayabileceğiniz bir noktaya kadar, çok yönlü kalmak yerine ve her hangi bir konuda uzman olmadan, hangi araçların mevcut olduğunu bilmek. Dünyada her ikisine de ihtiyaç duyulan avantajlar var.

2
katma