Nesneye yönelik projeleri nasıl tasarlıyorsunuz? [kapalı]


231

Birçok derse sahip ve genişletilebilir olması gereken büyük bir proje (benim için) üzerinde çalışıyorum, ancak programımı nasıl planlayacağımı ve sınıfların nasıl etkileşim kurması gerektiğini bilmiyorum.

Birkaç sömestr önce bir OOD kursu aldım ve ondan çok şey öğrendim; UML yazma ve gereksinim belgelerini nesnelere ve sınıflara dönüştürme gibi. Dizi diyagramlarını da öğrendik ama bir şekilde dersi ya da bir şeyleri kaçırdım, gerçekten bana yapışmadılar.

Önceki projeler ile ben dersten öğrendim yöntemleri kullanarak denedim ama genellikle "evet aklımdaki gibi bir şey görünüyor" diyebilir en kısa sürede kod eklemek ile eklemek için muck kazma arzusu yok Yeni özellikler.

Steve McConnell'in Code Complete'inin bir kopyasını sürekli duyuyorum, burada ve başka yerlerde inanılmaz. Tasarım bölümünü okudum ve aradığım bilgilerle çıkmadı. Kesik ve kurutulmuş bir süreç olmadığını, çoğunlukla sezgisel tarama temelli olduğunu söylediğini biliyorum, ancak tüm bilgilerini alıp projelerime uygulayamıyorum.

Peki , üst düzey tasarım aşamasında (programlamaya başlamadan önce) ihtiyacınız olan sınıfları (özellikle herhangi bir 'gerçek dünya nesnesine' dayanmayan) belirlemek ve birbirleriyle nasıl etkileşime gireceklerini belirlemek için ne yaparsınız ?

Özellikle kullandığınız yöntemler nelerdir? Nihai ürünü yakından temsil edecek iyi, temiz bir tasarım sunan, takip ettiğiniz süreç nedir?


2
Code Complete'in bu konuda oldukça yararlı olduğunu düşündüm - özellikle 5.3 ve 5.4 bölümleri (bazı daha somut önerilere sahip) ve bölüm 6'nın tamamı. Ancak, aslında büyük bir proje için herhangi bir kod tasarımı yapmadım.
Paul D.Waite

1
Java'da nesneye yönelik tasarım üzerine bir ders almanızı tavsiye ederim. UDEMY udemy.com/mastering-object-oriented-design-in-java/… 'de yayınlanan mükemmel bir tane var . Sanırım bu kesinlikle sana yardımcı olabilir. Bir diğer harika kaynak ise ATM nesne yönelimli problemi denemektir. Bunu Google'da yapabilirsiniz.
Horse Voice

Aslında tasarım yaparken herkese bu soruya geri dönmelerini tavsiye ederim. Burada çok fazla içerik var. Bu şekilde, gerçek tasarımı yaparken hafızanızı hareket ettirebilirsiniz.
Kevin Wheeler

Yanıtlar:


199

İlk tasarım için kullandığım adımlar (bir sınıf diyagramına ulaşmak):

  1. Gereksinimleri toplama. İstemciyle konuşun ve yazılımın hangi işlevselliğe sahip olması gerektiğini tanımlamak için kullanım durumlarını dikkate alın.

  2. Bireysel kullanım örneklerini anlatır.

  3. Anlatımı gözden geçirin ve isimleri (kişi, yer, şey), aday sınıflar ve fiiller (eylemler) olarak, yöntemler / davranışlar olarak vurgulayın.

  4. Yinelenen isimleri atın ve ortak işlevleri dışlayın.

  5. Bir sınıf diyagramı oluşturun. Bir Java geliştiricisiyseniz, Sun'dan NetBeans 6.7, hem diyagram hem de gidiş-dönüş mühendisliğine izin veren bir UML modülüne sahiptir ve ÜCRETSİZDİR. Eclipse (açık kaynaklı bir Java IDE) de bir modelleme çerçevesine sahiptir, ancak bununla ilgili hiçbir deneyimim yok. Ayrıca açık kaynak kodlu bir araç olan ArgoUML'yi de denemek isteyebilirsiniz.

  6. Sınıflarınızı düzenlemek için OOD ilkelerini uygulayın (ortak işlevselliği etkisiz hale getirme, hiyerarşiler oluşturma vb.)


6
Bu gerçekten yararlı bir tekniktir, özellikle sorun etki alanında gerçek bir işleminiz olmadığında. Ancak nadiren optimal bir mimari üretir.
NomeN

1
Java'da nesneye yönelik tasarım üzerine bir ders almanızı tavsiye ederim. UDEMY udemy.com/mastering-object-oriented-design-in-java/… 'de yayınlanan mükemmel bir tane var. Sanırım bu kesinlikle sana yardımcı olabilir. Bir diğer harika kaynak ise ATM nesne yönelimli problemi denemektir. Bunu Google'da yapabilirsiniz.
Horse Voice

1
Bunu nereden öğreniyorsun? Bunun kaynağını verebilir misiniz?
Kanagavelu Sugumar

68

Scott Davies'in söylediklerine ek olarak:

  1. Başlamadan önce programınızın neyle ilgili olduğunu bildiğinizden emin olun. Ne olduğunu programınız? Ne olur değil mi? Hangi sorunu çözmeye çalışıyor?

  2. İlk kullanım durumlarınız, programın sonunda yapacağı her şeyin bir çamaşır listesi olmamalıdır. Hala programınızın ne için özünü yakalarsanız bulabileceğiniz en küçük kullanım durumlarıyla başlayın. Bu web sitesi için, örneğin, çekirdek kullanım durumlarını olabilir oturum , soru sormak , bir soruya cevap ve görüş soruları ve cevapları . İtibar, oylama veya topluluk wiki'si hakkında hiçbir şey yok, sadece çektiğiniz şeyin özü.

  3. Potansiyel sınıflar geliştirirken, onları sadece hangi isimleri temsil ettikleri değil, ne gibi sorumlulukları açısından düşünmeyin. Bunu, program yürütme sırasında sınıfların birbirleriyle nasıl ilişkilendiğini anlamada en büyük yardım olarak buldum. "Bir köpek bir hayvandır" veya "bir köpeğin bir annesi vardır" gibi ilişkiler bulmak kolaydır. Nesneler arasındaki çalışma zamanı etkileşimlerini açıklayan ilişkileri anlamak genellikle daha zordur. Programın algoritmaları en azından nesneleriniz kadar önemlidir ve her bir sınıfın işinin ne olduğunu yazdıysanız tasarımı çok daha kolaydır.

  4. En az sayıda kullanım örneği ve nesnesine sahip olduğunuzda kodlamaya başlayın. Çok fazla bir şey yapmasa ve muhtemelen bok gibi görünse de, mümkün olan en kısa sürede çalışan bir şey alın. Bu bir başlangıç ​​noktasıdır ve kağıt üzerinde parlayabileceğiniz soruları yanıtlamaya zorlar.

  5. Şimdi geri dönün ve daha fazla kullanım örneği seçin, nasıl çalışacaklarını yazın, sınıf modelinizi değiştirin ve daha fazla kod yazın. Tıpkı ilk kesiminiz gibi, yine de anlamlı bir şey eklerken olabildiğince az sürün. Durulayın ve tekrarlayın.

Sadece iki sentim. Umarım faydalıdır.


19

Şansım olduğunda normalde "üç iterasyon kuralı" dediğim şeyi kullanıyorum.

İlk yinelemede (veya başlangıçta), model nesnelerine, algoritmalara ve beklenen ( gerçekten beklenen, belki değil) göre uygulamanın genel düzenini tasarlıyorumgelecekteki yönleri. Tasarım belgeleri yazmıyorum, ancak birden fazla kişiyi koordine etmem gerekirse, elbette, bağımlılığın analizi ve ihtiyaç duyulan zamanın tahmini ile birlikte kaba bir prosedür taslağı gereklidir. Benim gibi daha çevik bir yöntemi tercih ediyorsanız bu aşamayı minimumda tutmaya çalışın. Özellikle programınızın mantığı hakkında her şey bilindiğinde ve doğru olduğunda ve kodunuzdaki özellikler arasında çok fazla etkileşim kurmayı planlıyorsanız, güçlü bir tasarım aşamasına ihtiyaç duyulan durumlar vardır. Bu durumda, kullanım senaryoları veya kullanıcı hikayeleri, özellikle GUI uygulamaları için iyi bir üst düzey fikirdir. Komut satırı uygulamaları ve özellikle kütüphaneler için, geliştirmeniz gereken kütüphaneye kod yazdığınız ve nasıl göründüğünü kontrol ettiğiniz "program öyküleri" yazmaya çalışın.

Bu ilk yinelemeden sonra, şeylerin nasıl etkileşime girdiğini, ayrıntıları ve pürüzlü noktaları çıkardığını, tokatlanmış bir koli bandı yamasıyla sorunları çözdüğünü daha iyi anlayacaksınız. Bu deneyimi, büyük olanı iyileştirmek, temizlemek, cilalamak, bölmek, çok parçalı olanları birleştirmek, tasarım kalıplarını tanımlamak ve kullanmak, performans darboğazlarını ve önemsiz güvenlik sorunlarını analiz etmek için kullanmaya hazırsınız. Genel olarak, tüm bu değişikliklerin yazdığınız birim testleri üzerinde büyük bir etkisi olacaktır, ancak fonksiyonel testler üzerinde değil.

Bu ikinci yinelemeyi tamamladığınızda, iyi test edilmiş, iyi belgelenmiş ve iyi tasarlanmış küçük bir mücevheriniz olacak. Şimdi üçüncü yinelemeyi yapmak için hem deneyime hem de koda sahipsiniz. Uygulamanızı geliştirmek için yeni özellikler ekleyecek ve vakaları kullanacaksınız. Kaba noktalar bulacaksınız ve sonunda ikincisine benzer bir dördüncü yinelemeye gireceksiniz. Durulayın ve tekrarlayın.

Bu benim yazılım tasarımına genel yaklaşımım. Sorunları öğrenmenizi ve yazılımınızı ve uygulama alanını tanımanızı sağlayan, kısa, üç aylık yinelemeler ve Çevik gelişim unsurları ile spiral tasarıma benzer. Tabii ki, bu uygulama geliştiricileri yüzlerce işler biraz daha karmaşık bundan daha vardır dahil etmek çok büyük olduğu eğer öyleyse, ölçeklenebilirlik meselesi, ama sonunda ben fikri hep aynı, sanırım bölmek et impera .

Özetle:

  1. Birincisi, bir tat alırsınız ve öğrenirsiniz
  2. İkinci aşamada, ürününüzü temizler ve geleceğe hazırlarsınız
  3. Üçüncü aşamada, yeni özellikler eklersiniz ve daha fazla bilgi edersiniz
  4. Git 2

16

Bu konuda bildiğim en ilginç kaynak, Nesne Yönelimli Yazılım İnşaatının D Bölümü , Bertrand Meyer tarafından 2. Baskı .

Bölüm D: Nesneye yönelik metodoloji: yöntemi iyi uygulama

19: Metodoloji üzerine, 20: Tasarım deseni: çok panelli interaktif sistemler, 21: Miras vaka çalışması: interaktif bir sistemde "geri al", 22: Sınıflar nasıl bulunur , 23: Sınıf tasarım ilkeleri, 24: Mirasın iyi kullanılması , 25: Faydalı teknikler, 26: Bir stil duygusu, 27: Nesneye yönelik analiz, 28: Yazılım oluşturma süreci, 29: Yöntemin öğretilmesi

İlginç bir şekilde, bölüm 22. Dersleri nasıl bulabilirim ?


12

Çoğu zaman tekrarlanır, ancak tamamen doğrudur - verilerinizi anlayın.

OOP için sınıflarınız göze çarpan bilgi parçalarını ve nasıl etkileştiklerini tanımlamalıdır.

Verilerin davranışını ve ömrünü iyi açıklayan zihinsel bir modeliniz varsa, sınıflarınızı düzenlemek için kolay bir sürüşe sahip olursunuz.

Bu sadece bir uzantısıdır: Tam olarak ne yapmaya çalıştığınızı bilin.


12
Nesne davranışı veriden daha önemlidir. Bu, kapsüllemenin doğrudan bir sonucudur: nesne yönelimli programlamanın kalbi. Verilere maruz kalma (C ve Pascal gibi dillerden), sistemdeki başka hangi yerin verileri değiştirdiğini asla bilmediğiniz için bakımı zor olan (geliştiren ve hata ayıklayan) sistemlere yol açar. OOP verilerle ilgili değildir; OOP davranışla ilgilidir. Bu önemli bir ayrım.
Dave Jarvis

Bu önemli bir ayrımdır, ancak davranışın verilerden daha önemli olduğu anlamına gelmez.
johnny

OOD için, genellikle gereksinimleri netleştirdikten sonra Model tasarımından başlıyorum, bu da bana kurumların aralarındaki ilişkinin nasıl organize edilmesi gerektiği konusunda temel bir fikir veriyor. Aynı zamanda, her bir kuruluşta gerçekleşebilecek operasyonlar hakkında temel bir fikrim var. Modellerle ilgili taslak bir resimden sonra, gereksinimleri gözden geçirebilir ve bir şey eksik olup olmadığımızı kontrol edebiliriz. Ve sonra sınıf seviyesine ve kontrolör seviyesine geri dönmek daha kolay olacaktır.
Joshua

10

Davranış odaklı geliştirmeyi kullanmayı deneyin. Eski alışkanlıklarınızı kırmak zor olacak, ama gerçek dünyada gelişmek söz konusu olduğunda BDD'nin gerçekten en iyi bahsiniz olduğunu gördüm.

http://behaviour-driven.org/


1
+1 Test / davranış / etki alanı güdümlü geliştirmeyi kullanarak, sorunlu geniş ön tasarım şelale yönteminden kaçınmanız için sınıflar oluşturmanıza olanak tanır.
Halvard

8

Büyük projelerde sorun, bileşenler arasındaki tüm etkileşimleri denetleyememenizdir. Bu nedenle, projenin karmaşıklığını azaltmak önemlidir. Sınıf ve Sıra diyagramları tasarımın bu aşaması için çok ayrıntılıdır.

Önce daha yüksek bir soyutlama seviyesinden düşünmeye çalışın. Başlıca bileşenleri ve sorumluluklarını (diğer bileşenlerle ara yüzleri) düşünün, ilham almak için bazı mimari kalıplara bakın (hayır, tasarım kalıpları değil, bunlar çok düşük düzeydir! MVC ve Çok Katmanlı mimari kalıp örnekleridir). Oldukça büyük projeler için böyle bir görüşün yaklaşık 3-5 bileşeni olmalıdır.

Ancak o zaman belirli bir bileşene yakınlaşırsınız ve bunu tasarlamaya çalışırsınız. Şimdi tasarım kalıpları ve sınıf diyagramları seviyesindeyiz. Projenin bu kısmına odaklanmaya çalışın, diğer bileşenlerden birine sorumluluk eklemeniz gerekiyorsa, bunu dokümantasyon / yapılacaklar listenize ekleyin. Bu noktada çok hızlı değiştikleri etkileri düşünerek zaman kaybetmeyin, tasarımın daha sağlam olduğunu gözden geçirin.

Uygulanmamış bileşenler arabirimini uygulayan ve basit ama kullanışlı yanıtlar üreten bir kod parçasına sahip olmanız akıllıca olsa da, bu noktada her bileşeni tam olarak tasarlamanız gerekmez. Bu şekilde, her seferinde bir bileşen geliştirmeye başlayabilir (ve tasarlayabilirsiniz) ve makul derecede test edebilirsiniz.

Tabii ki, yeni bileşenler tamamlandığında, devam etmeden önce birbirleriyle nasıl entegre olduklarını (ve eğer) test etmelisiniz.

Kısaca: OO ve bilgi gizleme prensibini alın ve başka bir seviyeye çıkarın!


PS: Tasarlarken çok fazla eskiz yapın, tıpkı gerçek mimari gibi!

PPS: Konuya farklı açılardan yaklaşmaya çalışın, kutunun dışında düşünün (kutu gitmek için bir yol olsa da), akranlarla tartışmak bunun için çok yararlı olabilir ... ve öğle yemeğinde konuşacak bir şeyiniz var.


7

Gerçek projelerde makul başarı ile kullandığım teknik, Wirfs-Brock'un kitabından esinlenen Sorumluluk Odaklı Tasarım.

Üst düzey kullanıcı hikayeleriyle başlayın ve meslektaşlarınızla bir beyaz tahtada, ima ettikleri üst düzey etkileşimleri çizin. Bu size büyük modüllerin ne olduğu hakkında ilk fikri verir; ve bir yineleme veya oynatma gibi yüksek seviyeli iki CRC kartı, ana bileşenlerin listesini, yaptıklarını ve nasıl etkileştiklerini stabilize etmeliydi.

Daha sonra, sorumluluklardan herhangi biri büyük veya karmaşıksa, üst düzey etkileşimler tarafından tanımlanan büyük işlemlerin her biri için modül içindeki etkileşimleri oynayarak, nesne olacak kadar küçük ve basit şeyler olana kadar bu modülleri rafine edin .

Ne zaman durulacağını bilmek bir yargı meselesidir (sadece deneyimle birlikte gelir).


Beyaz tahta için +1, olağanüstü bir şey: DI, beyaz tahtanın önünde oturan sorunların% 80'ini çözüyor, sadece ona bakıyor ve 'en iyi ne olurdu' diye düşünüyor.
usoban

7

Tasarım desenleri

Yaratıcı Tasarım Desenleri

Tekton - Bir sınıfın yalnızca bir örneğinin oluşturulduğundan emin olun ve nesneye genel erişim noktası sağlayın.

Fabrika (Fabrika Yönteminin Basitleştirilmiş sürümü) - Örnekleme mantığını istemciye maruz bırakmadan nesneler oluşturur ve ortak bir arabirim aracılığıyla yeni oluşturulan nesneyi ifade eder.

Fabrika Yöntemi - Nesneler oluşturmak için bir arabirim tanımlar, ancak alt sınıfların hangi sınıfın örnekleneceğine karar vermesine izin verir ve ortak bir arabirim aracılığıyla yeni oluşturulan nesneyi ifade eder.

Abstract Factory - Sınıflarını açıkça belirtmeden ilgili nesnelerin bir ailesini oluşturmak için arabirim sunar.

Oluşturucu - Nesne oluşturmak için bir örnek tanımlar, ancak alt sınıfların hangi sınıfın örnekleneceğine karar vermesine izin verir ve inşaat süreci üzerinde daha iyi bir denetime izin verir.

Prototip - Prototip bir örnek kullanarak oluşturulacak nesne türlerini belirtin ve bu prototipi kopyalayarak yeni nesneler oluşturun.

Davranışsal Tasarım Kalıpları

Sorumluluk Zinciri - Gönderenin alıcısına bir talebin eklenmesini önler, bu şekilde diğer nesnelere de talebi işleme imkanı verir. - Nesneler bir zincirin parçaları haline gelir ve nesnelerden biri onu ele geçirinceye kadar istek zincirden bir nesneden diğerine gönderilir.

Komut - Bir nesnedeki isteği kapsül içine alır, Farklı isteklere sahip istemcilerin parametreleştirilmesine izin verir ve istekleri bir kuyruğa kaydetmeye izin verir.

Tercüman - Bir dil verildiğinde, dilbilgisi için bir temsili tanımlayın, ayrıca dilde cümleleri yorumlamak için temsili kullanan bir tercüman / Bir alanı bir dile, bir dilbilgisine bir dil ve hiyerarşik bir nesne tabanlı tasarıma dilbilgisini eşleyin

Yineleyici - Birleştirilmiş nesnenin öğelerine, temel temsilini göstermeden sırayla erişmek için bir yol sağlar.

Arabulucu - Bir nesne kümesinin nasıl etkileştiğini kapsayan bir nesne tanımlayın. Arabulucu, nesnelerin birbirinden açıkça bahsetmesini engelleyerek gevşek bağlantıyı destekler ve etkileşimlerini bağımsız olarak değiştirmenize olanak tanır.

Gözlemci - Nesneler arasında bire çok bağımlılık tanımlayın, böylece bir nesne durumu değiştiğinde tüm bağımlıları otomatik olarak bildirilir ve güncellenir.

Strateji - Bir algoritma ailesi tanımlayın, her birini kapsülleyin ve değiştirilebilir yapın. Strateji, algoritmanın onu kullanan istemcilerden bağımsız olarak değişmesine izin verir.

Şablon Yöntemi - Bir işlemdeki algoritmanın iskeletini tanımlayın, bazı adımları alt sınıflara erteleyin / Şablon Yöntemi, alt sınıfların algoritmanın yapısını değiştirmelerine izin vermeden bir algoritmanın belirli adımlarını yeniden tanımlamasına olanak tanır.

Ziyaretçi - Bir nesne yapısının elemanları üzerinde gerçekleştirilecek bir işlemi temsil eder / Ziyaretçi, üzerinde çalıştığı elemanların sınıflarını değiştirmeden yeni bir işlem tanımlamanızı sağlar.

Null Object - Belirli bir türde nesnenin bulunmaması için bir nesne olarak bir nesne sağlar. / Null Nesne Kalıbı, akıllı çalışanların hiçbir şey yapmamalarını sağlar ve ortak çalışanlarının ayrıntılarını gizler.

Yapısal Tasarım Desenleri

Bağdaştırıcı - Bir sınıfın arabirimini istemcilerin beklediği başka bir arabirime dönüştürün. / Bağdaştırıcı sınıfların birlikte çalışmasına izin verir, aksi takdirde uyumsuz arabirimler nedeniyle yapılamaz.

Köprü - Kısmi bütün hiyerarşileri temsil etmek için nesneleri ağaç yapılarına dönüştürün. / Kompozit, müşterilerin münferit nesnelere ve nesnelerin bileşimlerine eşit muamele etmesine olanak tanır.

Kompozit - Kısmi bütün hiyerarşileri temsil etmek için nesneleri ağaç yapılarına dönüştürün. / Kompozit, müşterilerin münferit nesnelere ve nesnelerin bileşimlerine eşit muamele etmesine olanak tanır.

Dekoratör - bir nesneye dinamik olarak ek sorumluluklar ekleyin.

Flyweight - devletin diğer bölümünün değişebileceği yerlerde, ortak durumlarının bir parçası olan çok sayıda nesneyi desteklemek için paylaşımı kullanın.

Memento - kapsüllemeyi ihlal etmeden ve böylece gerektiğinde nesneyi başlangıç ​​durumuna geri döndürmek için bir araç sağlamadan bir nesnenin iç durumunu yakalayın.

Proxy - bir nesneye referanslarını kontrol etmesi için bir “Yer Tutucu” sağlayın.


2
Desenler bazı insanlar için faydalıdır. Gereksinimlerdeki kalıpları görmek önemli bir deneyime ihtiyaç duyduğunu düşünüyorum. Ve muhtemelen bunları belgelemeniz gerekir. Desenlerin soyut bileşen kütüphanelerinden başka bir şey olmadığını düşünmeye meyilliyim.
CyberFonic

5

Kullanmak size öneriyoruz BlueJ nesneler üzerinde anlayış bir iyi değerlendirip geliştirmek da öğrenmek ve ayrıca ActiveWriter ve. Önerilen kitap da güzel bir kaynak.

Gönderen Vikipedi :

alternatif metin

BlueJ, temel olarak eğitim amaçlı geliştirilmiş, ancak küçük ölçekli yazılım geliştirme için de uygun olan Java programlama dili için bir Entegre Geliştirme Ortamıdır.

Ek olarak UML kullanıyor ve benim için nesneleri modelleme hakkında birkaç şeyi anlamak iyi bir kaynaktı.

alternatif metin http://www.ryanknu.com/ryan/bluej.png

ActiveWriter , varlıkları ve ilişkileri modellemek için bir araçtır, aynı zamanda kod üretir ve değişiklik yapmak kolaydır. Size zaman kazandıracak ve çevik gelişim için çok uygundur.

alternatif metin
(kaynak: altinoren.com )


1
Mavi J kullandım ... kesinlikle yararlı ama sınıfları ve ilişkilerini tasarlamama nasıl yardımcı oluyor?
Victor

1
Sınıfların nasıl tanımlanacağı ve görsel olarak nasıl ilişkilendirileceği hakkındaki tüm resmi görmemi netleştirdiğimi düşünüyorum, ilk adımlarda nesnelerin kod temsili nasıl ve nesnelerde nasıl düşünüleceğini anladım. "Bir" ve "bir" var ve UML mükemmel bir yardım olduğunu anlamaya zaman ayırdığımı hatırlıyorum. O zamandan beri bu görsel araçları nesnelerimi tasarlamak için kullanıyorum ve ActiveWriter'ı keşfettiğimde çok memnun kaldım çünkü BlueJ'nin kod üretimi yok ve bu araç sadece argümanımı uygulamak için görsel olarak bir çözüme daha geniş bir yaklaşımınız olduğunu düşünüyorum.
Nelson Miranda

4

Her şeyden önce - tasarım ruhunuzdan gelmelidir. Bunu her lifinizle hissetmelisiniz. Genellikle bir şey yapmaya başlamadan önce iki ya da üç ay boyunca yürürüm, sadece sokaklarda yürürken (gerçekten). Ve düşünmek. Yürümek iyi bir meditasyondur, bilirsiniz. Böylece iyi konsantre olmanızı sağlar.

İkinci olarak - OOP ve sınıfları yalnızca doğal bir nesne hiyerarşisinin olduğu yerlerde kullanın. Bunu yapay olarak 'vidalamayın'. Sıkı bir hiyerarşi yoksa (çoğu iş uygulamasında olduğu gibi) - yordamsal / işlevselliği tercih edin veya en azından nesneleri yalnızca yalıtılmış erişimli veri kapları olarak kullanın.

Ve son - bunu okumaya çalışın: Yaratıcı Düşünme Algoritması


4

Sadece alıntı http://www.fysh.org/~katie/computing/methodologies.txt

Ve RUP'un merkezinde OO tasarım yeteneklerini kullanmanız gereken küçük bir alan var ... eğer sahip değilseniz, 100m'yi çalıştırmak için bir metodolojiye sahip olmak gibi.

"Adım 1: gerçekten hızlı koşma hakkında yaz. Adım 2: Git ve yarış pistinin bir planını çiz. Adım 3: git ve gerçekten sıkı likra şort satın al. Adım 4: gerçekten, gerçekten, gerçekten hızlı koş. Adım 5: önce çapraz "

Bu zor adım 4 adımı. Ancak 1,2,3 ve 5'e çok fazla vurgu yaparsanız, kimse fark etmeyebilir ve muhtemelen 100 metrelik bir "sır" olduğunu düşünen sporcular olmak için metodolojiyi satarak çok para kazanabilirsiniz. koşmak


4

Birçok yazarın kitap yazmak için kullandığı soru sordunuz. Birkaç metodoloji vardır ve size "en güzel" gibi görünen bir yöntem seçmelisiniz. Eric Evans tarafından "Domain Driven Design"
adlı kitabı tavsiye edebilirim . Ayrıca, dddcommunity.org sitesini kontrol edin .


3

Buradaki cevabın , soran adamın gerçek dünya deneyimine bağlı olarak çok farklı olması gerektiğini düşünüyorum .

Sadece bir ya da iki yıllık iş tecrübeniz varsa, şu noktaya gitmelisiniz: verilerinizi gerçekten bildiğiniz noktaya nasıl ulaşırsınız ve ne yapmaya çalıştığınızı tam olarak anlarsınız?

Evet, gerçek dünyada 5 yıldan fazla bir süredir çalışıyorsanız, birçok yazılım geliştirme süreci modeli veya tekniği arasından seçim yapabilirsiniz.

Ancak sadece kitap okuyarak deneyim kazanmazsınız. İyi bir liderlik altında iyi bir grupta çalışarak öğrenmelisiniz.

Bu mümkün değilse, sadece kendiniz yapmalısınız. Muhtemelen çok kötü bir kod parçasını kodlayarak, hatalarınızı öğrenerek, hepsini dökerek, daha iyi bir kod yazarak vb. Yinelemeye başlayın.

Kod tabanınız hakkında çok şey öğreneceksiniz. Aletler alettir, size hiçbir şey öğretmezler.


3

Projede alan adı uzmanlığınız varsa, bankacılık gibi çalışacaksınız. Nesnelerinizi yapılandırmak kolaydır ve bu geliştirmelerin her geçen gün nasıl geldiğini bilirsiniz.

Bu uzmanlığa sahip değilseniz, bu uzmanlığa sahip biriyle çalışın ve bu fikirleri teknik detaylara dönüştürün.

Proje tasarımınızı nasıl yapılandıracağınız konusunda kafanız karıştıysa. KESİNLİKLE "pragmatik programcı" kitabını takip edin. Daha önce aynı durumdaydım, o kitaptan bir bölüm okumayı deneyin. farkı göreceksiniz, bir yazılım geliştiricisi olarak düşünme şeklinizi değiştirecektir.


2
  1. çalışma ve usta Tasarım Desenleri.
  2. Ardından, Etki Alanına Dayalı Tasarım hakkında bilgi edinin
  3. Bundan sonra, gereksinim toplamayı öğrenin

Birkaç sömestr önce bir OOD kursu aldım ve ondan çok şey öğrendim; UML yazma ve gereksinim belgelerini nesnelere ve sınıflara dönüştürme gibi. Dizi diyagramlarını da öğrendik ama bir şekilde dersi ya da bir şeyleri kaçırdım, gerçekten bana yapışmadılar.

  1. 3. adımı biliyorsunuz. Ustalaşmanız gerekiyor. Demek istediğim, onu ikinci doğanız haline getirmek için bir çok uygulama ile. Çünkü öğrendiğiniz yöntem basitçe eskisi gibi. Bu yüzden gerçekten ustalaşmanız gerekiyor. Aksi takdirde, kendinizi her zaman orijinal şeylerinize geri dönerken bulacaksınız. Bu bir şekilde bir çok java geliştiricisinin birkaç denemeden sonra vazgeçtiği Test Tahrikli Süreç gibidir. Tamamen ustalaşmadıkları sürece, bu sadece onlara bir yük

  2. Özellikle alternatif kurslar için kullanım durumlarını yazın. Alternatif kurs, geliştirme süremizin% 50'sinden fazlasını kaplar. Normalde PM'niz size bir görev atadığında, örneğin bir giriş sistemi oluşturduğunda, bunun doğrudan ileri olduğunu düşünür, bitirmek için 1 gün sürebilir. Ama dikkate almanız gerektiğini asla dikkate almayın, 1. ne kullanıcı şifre yanlış şifre, 2. ne kullanıcı şifre 3 kez yanlış şifre, 3. kullanıcı kullanıcı adı yazmaz vb. Bunları listelemeniz ve Başbakanınıza göstermeniz, son tarihi yeniden planlamasını istemeniz gerekir.


2

Korkarım bu insanların duymaktan hoşlandığı bir cevap değil . Her neyse, fikrimi söyleyeyim.

OOP, üstün paradigma olarak değil, paradigmalardan biri olarak görülmelidir. OOP, GUI kütüphanesi geliştirmek gibi belirli sorunları çözmek için iyidir. Ayrıca, genellikle büyük yazılım şirketleri tarafından takip edilen yazılım geliştirme stiline de uyar - seçkin bir tasarımcı veya mimar ekibi , yazılım tasarımını UML diyagramlarında veya başka benzer bir ortamda ve daha az aydınlanmış bir geliştiriciler ekibine bırakırbu tasarımı kaynak koduna çevirir. OOP tek başına veya çok yetenekli programcılardan oluşan küçük bir ekiple çalışıyorsanız çok az fayda sağlar. Daha sonra, birden fazla paradigmayı destekleyen ve hızlı bir prototip bulmanıza yardımcı olacak bir dil kullanmak daha iyidir. Python, Ruby, Lisp / Scheme vb. İyi seçimlerdir. Prototip tasarımınızdır. Sonra bunu geliştirirsin. Sorunu çözmek için en iyi paradigmayı kullanın. Gerekirse, sıcak noktaları C veya başka bir sistem dilinde yazılmış uzantılarla optimize edin. Bu dillerden birini kullanarak, genişletilebilirlik de elde edersinizyalnızca programcı düzeyinde değil, kullanıcı düzeyinde de ücretsiz olarak sunulur. Lisp gibi diller dinamik olarak kod oluşturabilir ve yürütebilir, yani kullanıcılarınız yazılımın kodlandığı dilde küçük kod parçacıkları yazarak uygulamayı genişletebilir! Veya programı C veya C ++ 'da yazmayı seçerseniz, Lua gibi küçük bir dil için bir tercüman gömmeyi düşünün. İşlevleri bu dilde yazılmış eklentiler olarak gösterin .

Bence, çoğu zaman OOP ve OOD, aşırı tasarımın kurbanı olan yazılımlar yaratıyor.

Özetlemek gerekirse, yazılım yazmanın tercih ettiğim yolu:

  1. Dinamik bir dil kullanın.
  2. Tasarımı (prototip) o dilin kendisine yazın.
  3. Gerekirse, C / C ++ kullanarak belirli alanları optimize edin.
  4. Uygulama dilinin tercümanı aracılığıyla genişletilebilirlik sağlamak.

Son özellik, yazılımın belirli kullanıcı (ben dahil!) Gereksinimlerine kolayca uyum sağlamasını sağlar.


Bu tasarım hakkında pek tavsiye değil
NomeN

2
Ben de benzer bir yaklaşım kullanıyorum. Karmaşıklık yüzünden bunalmaktan kaçınmak için helikopter görünümü ile başlayın. 8-20 işlevli bir çizimi seviyorum. Daha fazlasını almaya başlarsam alt sistemlere nasıl bölümleneceğime bakarım. Bu üst düzey görünüme sahip olduğumda, her işlevi 8-20 alt işlev, vb. Olarak ayrıştıracağım. Bu işlevlerin neyi manipüle ettiğine bakarak üst düzey sınıfları alıyorum. İşte o zaman Python'da iskelet sistemini yerleştirmeye başladım, yani yürütülebilir sahte kod. Bu yorum blokları ile birlikte benim 'yürütülebilir özellik' olduğunu ve daha sonra aşamalı olarak rafine olur.
CyberFonic

2

Test Odaklı Tasarım (TDD) kullanıyorum. Önce testi yazmak aslında temiz ve doğru bir tasarıma götürmenize yardımcı olur. Bkz. Http://en.wikipedia.org/wiki/Test-driven_development .


2
TDD başlangıçta örnek girişi ve çıkışı ile sisteminizi kara kutu olarak görselleştirmeye yardımcı olur. Ama kendi başına sistemin tasarımını bulmanıza yardımcı olmaz. Ünite testi için öncelikle test etmek için sınıf arayüzünü bulmanız gerekiyor
Vicente Bolea

2

Tasarım kalıplarını öğrenir . OOP konusunda son iki yıldır kişisel devrimim oldu. Bir kitap al. Size bunu tavsiye ederim:

İlk Tasarım Desenleri

Java'dadır, ancak herhangi bir dile genişletilebilir.


1

Dürüst olmak gerekirse, iyi bir adım geri dönüp akış şeması ve dizi diyagramına bakmak olacaktır. Bunu nasıl yapacağınızı gösteren bir sürü iyi site var. Programın ne girdiğini, hesaplandığını ve çıktısını tam olarak bilmesi gerektiğini ve her adımın programın bir bölümüne bölünebileceğini bildiğim için, bir programı sınıflara nasıl ayırmak istediğime bakarken çok değerli olduğunu düşünüyorum.


1
Bir sorunla karşılaştığımda akış şemalarını seviyorum. Bazen problemi farklı bir şekilde düşünmeme yardımcı oluyor.
user133018

Akış şemaları yerine veya şemalar yerine, "Veri Akış Şemaları" (DFD'ler) çok daha yüksek seviyelidir: daha çok bir UML dağıtım şeması gibidir ve sistem işlevselliğine (ör. Sistemin veri girişi ve veri çıkışı, dahili ve harici veri depolama ve veri işleme) ve mimari. Akış şemaları, if-then-else deyimleriyle tek bir fonksiyonun modellenmesi kapsamına (IMHO) daha yakındır.
ChrisW

Evet, çoğu zaman genellikle Akış şemaları genellikle belirli bir sorunu çözmeye çalıştığım zamanlar için kullanıyorum.
user133018

Swimlanes kullanmak, akış şemalarıyla ilgili birçok sorunu çözer. Senaryo başına bir dizi diyagramı kullanmanın en iyi sonucu bulduğunu gördüm. Her senaryo, karar ağacında belirli bir yolu kapsar, böylece akışta IF'ler olmaz. Tüm akışla birlikte tek bir diyagrama sahip olmak istiyorsanız, karar noktalarını eklemeniz gerekir, ancak özellikle sorumluluk atamasını eklemek istiyorsanız, hızlı bir şekilde dağınık hale gelir.
Kelly


1

Yararlı bir teknik, benzersiz sorun tanımınızı gerçek dünyada bulabileceğiniz bir şeyle ilişkilendirmektir. Örneğin, dünyayı fırtınaya uğratacak karmaşık bir sağlık sistemi modelliyorsunuz. Bunu modellemek için kolayca çağırabileceğiniz örnekler var mı?

Aslında. Yan eczanenin nasıl çalışacağını veya doktorun odasını gözlemleyin.

Alan adı sorununuzu sizin için anlaşılabilir bir şeye indirin; ilişkilendirebileceğiniz bir şey.

Sonra etki alanı içinde "oyuncular" bir kez bariz görünmeye başlar ve size kod modelinin "sağlayıcı" dır, yani bir yaklaşım modelleme bir "sağlayıcı tüketiciye" için kodunuzu, opt modellemek için başlatın ve sen "tüketici olan ".

Etki alanına ilişkin ve onu yüksek düzeyde anlamak, herhangi bir tasarımın anahtar parçasıdır.


1

Sınıf yapıları tasarlama maceralarım sırasında, bazı sahte kodlar yazmanın çok yararlı olduğunu fark ettim. Bunun anlamı: Uygulamanın kodunun bazı genel parçalarını en üst düzeyde “yazmaya” başlıyorum, onunla oynuyorum ve görünen unsurları - aslında, bir programcı olarak - kullanmak istediğim unsurları keşfediyorum. Modüllerin genel yapılarını ve etkileşimlerini tasarlamak için çok iyi bir başlangıç ​​noktasıdır. Birkaç tekrardan sonra, tüm yapı daha çok tam bir sınıf sistemine benzemeye başlar. Kod parçalarını tasarlamak için çok esnek bir yol. Buna programcı odaklı bir tasarım diyebilirsiniz.

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.