Nesneye yönelik tasarımda neler yapılması gerektiğini nasıl öğrenebiliriz?


12

İlk olarak bir feragatname: Bu sorunun bu web sitesine uyup uymadığını bilmiyorum, ama yine de sadece benim için değil, yeni başlayanlar için de alakalı bir soru buluyorum. Soru buraya uyacak şekilde geliştirilebiliyorsa, lütfen int yorumlarına dikkat edin. Uygun değilse, bana da bildirin ve mümkünse bunun nerede tartışılabileceğini bana bildirin, çünkü bunun için iyi bir forum bulamadım.

PHP eğitimi aldığım 2009 yılında programlamayı öğrendim. Daha sonra 2012'de C # ve .NET'e geçtim. Her neyse, kodlama sorun değil, algoritmaları yazmak benim sorunum değil. Asıl sorun, bir gereksinimi elde etmek için neyin kodlanması gerektiğini ve nerede kodlanması gerektiğini bilmek .

İnternet üzerinde mevcut orada çoğu kursları mücadele how - nasıl yazma koduna belirli bir dilde vb API'ler, bazı setleri nasıl kullanılacağı Burada değil benim açımdan bu.

Bu yıllarda bir çok şey hakkında çok şey okudum: nesne yönelimli analiz ve tasarım, tasarım kalıpları, etki alanına dayalı tasarım vb. Örneğin, SOLID ilkelerini, DDD'nin bazı temel alanlarını, alan uzmanlarının katılımı, her yerde kullanılabilen bir dilin geliştirilmesi gibi bir şey gibi anlıyorum. En azından makul bir teorik arkaplan olduğumu söylemeye cesaret edebilirim .

Fakat uygulama söz konusu olduğunda felaketmişim gibi hissediyorum. Bir süre önce başka biri tarafından geliştirilen bir finansal sistemin geliştirilmesine devam etmem gerekiyordu. C # ve WinForms ile geliştirilen bu tür "eski sistem". İlk kez gerçek alan karmaşıklığı olan, birçok iş kuralına sahip bir proje seçtim.

İtiraf ediyorum ki çoğu zaman gereksinimleri aldığımda "bu nasıl yeryüzünde yapılabilir?" - Ne yapılması gerektiğini anlamak için gereksinimler üzerinde çalışmaya nasıl başlayacağım konusunda hiçbir fikrim yok. Benim ana kafa karışıklıklarım, neyi kodlamam gerektiği, hangi sınıflar, arayüzler ve her bir mantık parçasının nereye gittiği, her şeyin hangi sınıfta olması gerektiğidir. Sorun şu ki, nereden başlayacağımı bilmiyorum.

Çoğu zaman, oldukça fazla düşünce ile bazı fikirlerle sonuçlanırım, ancak fikrimin doğru olup olmadığını nasıl yargılayacağımı asla bilemiyorum.

Demek istediğim, yazılım mimarisi ve nesne yönelimi hakkında bir sürü şey okuduğumu söylediğim gibi, bunun teorik bir eksiklik olduğunu düşünmüyorum ama pratikte neler yapılması gerektiğini belirlemede çok yardımcı olmadı .

Peki nasıl öğrenebilirim gerçekten yapmak nesne yönelimli tasarım? Ne öğrenmek istiyorum: verilen gereksinimleri, ne yapılması gerektiğini ve her bir kod parçasının ait olduğunu bulmaya yol açan bir süreçte nasıl çalışmaya başlayacağını bilmek. Fikrimin doğru olup olmadığını yargılamayı nasıl öğrenebilirim?

Bunu tam olarak burada bir cevap olarak açıklamanın mümkün olmayacağına inanıyorum. Bununla birlikte, site stiline göre olabileceğim, sadece bir genel bakış veren ve fikirleri genişletmek ve gerçekten bu şeyleri öğrenmek için kullanılabilecek bazı referansları (kitaplar, çevrimiçi kurslar, vb.)


1. Operatör aşırı yüklemesi ile operatör geçersiz kılma arasındaki fark, soyut bir sınıfın ne olduğu ve bir arayüz, kapsülleme, polimorfizm vb. İlk önce bu şeyleri bilmek C # 'daki OO'yu tam olarak anlamak için gereklidir. Bkz. C-sharpcorner.com/technologies/oop-ood .
Robert Harvey

2
2. Winforms ile yazılmış daha eski uygulamalar, uygun şekilde tasarlanmadıkça büyük çamur toplarına dönüşme eğilimindedir. Endişelerin ayrılması her şeyden önemlidir. Bkz. Winformsmvp.codeplex.com
Robert Harvey

1
Gerçekten bir süreç yok. Tasarım çoğunlukla deneyimle birlikte nasıl organize edileceğini bilmekle ilgilidir. SOLID ilkeleri iyi bir başlangıçtır, ancak yeterli değildir ve insanlar SOLID'de kaybolma ve ilkelerin neden var olduğunu unutma eğilimindedir.
Robert Harvey

1
Biraz başla. Gereksinimler problemdir. Bir sorun "Bir sonraki Stackexchange sitesini geliştirmek istiyoruz" veya "bir sonraki Stackexchange'in giriş yapmasını istiyoruz" kadar büyük olabilir. Büyük bir problemi çok ama daha küçük olanlara dönüştürün. Genel olarak, kendinize ilk önce işleri "yanlış" yapma ve zamanla gelişme şansı verin.
LAIV

1
Ben aynı anda bunu vtc ve vtc istiyorum ...
svidgen

Yanıtlar:


21

Peki, nesne odaklı tasarım yapmayı nasıl öğrenebilirim? Ne öğrenmek istiyorum: verilen gereksinimleri ne yapılması gerektiğini ve her kod parçasının ait olduğunu bulmak için yol açan bir süreçte onları çalışmaya başlamak için biliyorum. Fikrimin doğru olup olmadığını yargılamayı nasıl öğrenebilirim?

Her şeyden önce, nesne odaklı tasarımı doğru düşünmeyi bırakın. İngilizceyi doğru olarak düşünmek gibi.

Nesneye yönelik paradigma doğru değil. Bazı avantajları ve dezavantajları vardır. Bir idealdir. Sadece bizim değil. Hiç yoktan iyidir ama kesinlikle her şey değildir.

On yıllardır kod yazıyorum. Fikirleri var olduğu sürece bu şeyleri inceledim. Hala ne anlama geldiğini öğreniyorum. Uzmanlar hala ne anlama geldiğini öğreniyorlar. Tüm alanımız 100 yıldan daha eski.

Bu nedenle, bir yığın gereksinim alıp onları tatmin eden kodu açtığınızda, yazdığınız kodun yalnız olmadığınız trajik bir karışıklık olduğunu hissedersiniz. Çalışma kodu sadece büyük kod için ilk adımdır. Sadece çalışan değil, diğerlerinin de kolayca okuyabildiği ve anlayabileceği kod. Gereksinimler değiştiğinde hızla uyarlanabilen kod. Arkanıza yaslanıp "Vay canına, bu çok basit" demek istemenizi sağlayan kod.

Sorun şu ki, tüm bunları yapmak için para almıyoruz. Tüm bunları yapıyoruz çünkü biz profesyoneliz. Bunları patron bakmadığında yapmalıyız çünkü her zaman bir son teslim tarihi vardır. Ama 5 yıl içinde geri dönüp yeni başlayanlara şunu söylemek istiyoruz: "Ah evet, bunu yazdım. Hala çalışıyor ha? Harika."

Oraya nasıl gidersin? Uygulama. İnanç üzerine HERHANGİ bir tasarım fikrini kabul etmeyin. Birisi, olay güdümlü tasarımın bu tasarımı nasıl basitleştireceğini düşünmeyecek mi? Haklı olup olmadıklarından emin değil misiniz? Gözlemci desenini kullanan evde kendi oyuncak projenizi oluşturun. Onunla uğraş. Yardım etmediği şeyleri bulmaya çalışın.

Okuyun. Soru. Ölçek. Tekrar et.

Bunu hayatınızın% 80'i için yaptığınız noktaya geldiğinizde, benim kadar kafanız karışır.

İtiraf ediyorum ki çoğu zaman gereksinimleri aldığımda "bu nasıl yeryüzünde yapılabilir?" - Ne yapılması gerektiğini anlamak için gereksinimler üzerinde çalışmaya nasıl başlayacağım konusunda hiçbir fikrim yok. Benim ana kafa karışıklıklarım, neyi kodlamam gerektiği, hangi sınıflar, arayüzler ve her bir mantık parçasının nereye gittiği, her şeyin hangi sınıfta olması gerektiğidir. Sorun şu ki, nereden başlayacağımı bilmiyorum.

Ben de aynı şekilde hissederdim. Sonra yeniden düzenleme sevincini keşfettim. Kod yazarken tasarımları uyarlamaya istekli olun. Kağıt üzerinde her şeyi önceden çözmeye çalışmak bunu yapmanın zor yoludur. Yanlış kanıtlanabilecek kodu yazın, yanlış olduğunu kanıtlayın ve düzeltin.


2
Bu harika bir cevap. 15 yıldır program yapıyorum ve Yazılım Mühendisliği'nin (mesleğim) tüm alanının "bulanık" olduğunu ekleyeceğim - bu sanat ve işlevin bir karışımı ve geliştiriciye bağlı olarak diğerinden daha fazla. Kağıt üzerinde bir mimari için bir fikir bulabilirim, ancak kire girene, etrafı karıştırıp neyin işe yarayıp neyin yaramadığını bulana kadar OO tasarımının ayrıntılarını asla çözemiyorum.
jropella

Cevap için teşekkürler! Demek istediğin: Bir gereksinimi uygulamak için en az bir çözümümüz olduğunda ve işe yaradığında, bunu uygularız ve daha sonra diğer kod ve diğer gereksinimlerle nasıl ilişkili olduğunu gördüğümüzde, onu daha iyi hale getirmek için yeniden düzenliyoruz? Ancak hala bazı gereksinimler aldığım durumlar var ve nasıl başlayacağım konusunda hiçbir fikrim yok. Bu durumlarda, nasıl başlayacağınız konusunda tavsiyeleriniz var mı? Bazen en iyinin gereksinimleri ve olası uygulamaları tartışmak olduğuna inanıyorum, ama yalnız çalışıyorum. Bu tür tartışmaların hoş karşılandığı bir forum var mı?
user1620696

2
Öncelikle, yalnız çalışmayı bırak. Bir şeyi açıklamak için sizi yavaşlatan clueless bir acemi bile daha iyi. İkincisi, bir gereksinimi parçalara ayırmayı öğrenin. Çekiş yapabileceğiniz yönetilebilir bir şey olana kadar bunu yapmaya devam edin. Gerekirse konsept kodunun kanıtını tamamen farklı bir ortama yazın. Sadece neyin gerekli olduğuna dair anlayışınızı ifade eden bir şey yapın. Ardından bu ifadeyi test edin. Sen benim bulduğum şey kötü varsayımlar yaptı. Bu iyi. Onları değiştirmeye istekli olun.
candied_orange

1

Yazılım geliştirme, tüm kabul kriterlerinizi karşılarken, çalışan yazılımın zamanında ve bütçeye uygun şekilde teslim edilmesini sağlar. Bunu başardığınızı varsayarsak, kodun veya yapısının algılanan kalitesi ikincil bir sorundur.

Sorun şu ki, yeni yeni yeşil alan kodu yazmak, eski kodu korumaktan çok daha ucuz ve daha kolay olma eğilimindedir, bu nedenle kod kalitesi veya mimariye çok fazla asılmak yerine, gerçek probleminizin sürdürülebilirlik olduğunu unutmayın.

Bu kodun değiştirilmesi ile ilişkili maliyetler, zaman ve riskler, hataların düzeltilmesi veya gereksinimlere değişikliklerin uygulanmasının hala maliyet-etkin olduğu ve bu değişiklikleri uygulayarak bir "ölüm sarmalı" "kod entropisinin.

Tersine, hiçbir şeyin bozulmamasını sağlamak için ciddi bir şey kırma veya aşırı zaman / para harcama riski olmadan güvenle değiştiremediğiniz veya yeniden düzenleyemediğiniz durumlarda kod sürdürülemez olarak kabul edilir - yani, bu kodla çalışmak için gereken zaman, maliyet ve risk değişiklik yapmanın yararları ile karşılaştırıldığında orantısız olarak yüksek (yani işvereniniz veya müşteriniz yeni özellikler ekleyerek, hataları düzelterek para kaybetmiyor)

Kendinizi kırılma değişikliklerine karşı korumak için yeterli şartlar varsa , en şeytani spagetti karışıklığının bile potansiyel olarak sürdürülebileceğini unutmayın (bu tür durumlar nadir olsa da). Bir spagetti karmaşası ile ilgili sorun, onu kırılma değişikliklerine karşı korumanın oldukça pahalı ve verimsiz olma eğiliminde olmasıdır - özellikle geriye dönük olarak yapıyorsanız.

Bakımlı kod yazmanızı sağlamanın belki de en güvenilir yolu, (makul olarak mümkün olduğunda) aynı anda yeterli bir otomatik test paketini yazmaktır (aynı zamanda mevcut olabilecek diğer statik analiz araçlarından da tam olarak yararlanmak).

Refactor yapabilmeniz için yeterli otomatik testlerle sonuçlanmak için TDD / BDD gibi katı bir geliştirme metodolojisini takip etmenize gerek yoktur; Sadece ihtiyaç yeterli Gelecekte yanlışlıkla kırma değişikliklerine karşı kodu korumak.

Kodunuz otomatik testler kapsamındaysa, bu testlerin kapsamında olduğunuzu bilerek tasarımı ve yapısı hakkında rahatlayabilirsiniz; daha sonraki bir tarihte agresif bir şekilde yeniden düzenleme yapabilir, hatta atabilir ve yeniden başlayabilirsiniz.

Bu, kolayca test edilebilir kodun nasıl yazılacağı sorusunu akla getirir; bu tipik olarak SOLID ilkelerini takip etmek için ana argümandır; aslında, SOLID ilkelerine uyan kodun ayırt edici özelliği, birim testleri yazmanın kolay ve zaman / maliyet etkin olmasıdır.

Tabii ki, bazen de birim testleri yazmak için zamanınız olmayabilir; ancak tüm kodunuzu "Bunun için otomatik testleri nasıl yazarım?" (bu testleri gerçekten uygulamasanız bile), muhtemelen makul düzeyde sürdürülebilir bir tasarım bulmayı başardınız.


1
otomatik testler yazmak için asla vaktimiz yok ama her zaman tekrar tekrar manuel testler yapıyoruz ...
Nick Keighley

Benzer şekilde, kodu ilk kez "doğru" ve "temiz" olarak yazmak için asla zamanımız yoktur, ancak sunulan yanlış yönlendirilmiş ancak çok yaygın zihniyet nedeniyle geri dönüp onu düzeltmek için sonsuz zamanımız var gibi görünüyor. bu gönderi.
Dunk

@ Kod Kod beklemenin gerçekçi olmadığını asla değiştirmemeli veya tekrar gözden geçirilmemeli. Birim test uygulamaları ve SOLID yönergeleri, kaçınılmaz olduğunda meydana gelmesi kolay ve ucuz bir kodla sonuçlanan uygulamaları teşvik etmekle ilgilidir - örneğin, birisi geliştiricinin o zaman dikkate almadığı gerçekten garip belirsiz bir hata bulur veya müşteri çözüm ve gereksinimleri değiştirir, hatta orijinal kod bile hatalar içeriyordu çünkü geliştiriciler sadece insan; ya da geliştirici gereksinimleri yanlış anlamış ya da daha önce bilinmeyen teknik sınırlamaları keşfetmiştir ...
Ben Cottrell

1
@BenCottrell - Tamamen katılıyorum. Kod her zaman yeniden gözden geçirilmelidir. Ancak, bu nedenle, insanların "açık tasarım" yapmak için zaman ayırmaya ve bir tür başarısızlık olarak bir şekilde "temiz kod" yazmaya işaret etmesine yol açar. Kötü kod / tasarımı haklı çıkarmak için "zamanında" ve "bütçede" mantra kullanırlar. İstediğiniz tüm "uygulamaları" kullanabilirsiniz ancak başlamak için iyi bir tasarıma ve nispeten "temiz kod" olmadan değiştirmek kolay ve ucuz olan "kodu satın almayacak". İyi bir tasarım ve "temiz kod", zamanında ve bütçeye uygun hedefe ulaşmanın yan ürününe sahip olacaktır.
Dunk

@Dunk Pek çok geliştiricinin kod kalitesini umursamadığını söylüyorsunuz, ki genellikle böyle olduğuna inanmıyorum. Gerçekte bence iki büyük sorun var - birincisi, geliştiriciler bütçe ve son tarih için bir tahmin sağlayanlar olsa da, tahminler kolayca yanlış olabilir. İkincisi, proje paydaşları zaman / maliyet konusunda son sözü alırlar, bu da risklerin, bütçelerin ve son tarihlerin teknik endişeleri geçersiz kıldığı anlamına gelir. "Kesinlikle geç / aşırı bütçe" veya "potansiyel olarak kötü kod" arasında bir seçim yapıldığında, paydaşların ikincisini sık sık seçtiğini görüyorum.
Ben Cottrell
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.