Kodlamadan önce bir OOP sistemi tasarlamak için basit bir süreç nedir?


10

Ne zaman bir proje inşa etmem gerekiyorsa, onu her zaman inşa etmeyi başardım, önceden bir plan ya da tasarım tasarlamıyordum, ama önce gerekli olan bir sınıfı yazdıktan sonra, aşağıdan yukarıya doğru inşa ederek tüm projeyi temizledim. Şimdi bunun yazılım oluşturmak için uygun bir yol olmadığını biliyorum, ama kafamı Nesneye Dayalı Analiz ve Tasarım olarak adlandırmak için kolay değil. Yukarıdan aşağıya prosedürel tasarımı daha kolay anlayabiliyorum, çünkü sadece görevleri alt görevlere, meslektaşları kodda olan şeylere, işlevlere ayırmaktan ibarettir. Ancak Nesneye Dayalı Analiz ve Tasarım Kolayca anlayamıyorum, çünkü nasıl kodlayacaklarını bilmedikleri sürece hangi sınıflara ihtiyaç duyacaklarını ve nasıl etkileşime gireceklerini nasıl anlayacağımı anlamıyorum.

Bir kez sınıf ve nesne kavramını tasarım sürecine dahil ettik, artık yukarıdan aşağıya tasarım yapamayız, çünkü artık problemlerimizi prosedür olarak uygulanabilecek şeylere bölmüyoruz. Bunun yerine, konuyla ilgili okuduğum şeye göre, hangi sınıfların gerekli olduğunu belirlemeli ve yazılımı uygularken kullanabileceğimiz Birleşik Modelleme Dili'nde çeşitli eserler oluşturmalıyız. Ama bu tür bir tasarım sürecini anlamıyorum. Zaten bütün sistemi anlamadılarsa, hangi sınıflara ihtiyaç duyacaklarını ve nasıl etkileşime gireceklerini nasıl bilebilir?

Bu benim sorunum. Nesneye Yönelik Bir Sistemin nasıl tasarlanacağını anlamıyorum, ancak Nesneye Yönelik Programlama kavramlarını anlıyorum ve bu kavramları bildiğim Nesne Tabanlı Programlama dillerinde kullanabiliyorum. Bu nedenle, Nesne Yönelimli Sistemler'i bana mantıklı bir şekilde tasarlamak için hangi basit süreci kullanabileceğimi açıklayacak birine ihtiyacım var.


8
"Şimdi bunun yazılım oluşturmak için uygun bir yol olmadığını biliyorum" - bunu kim söyledi? Bir şekilde "tasarım kodlamadan önce, belki de süslü UML diyagramları çizerek yaptığınız bir şeydir" inanmak gibi popüler tuzağa düşüyor gibi görünüyor. Sizi bu yanlış anlamadan korumak için Jack Reeves tarafından "Tasarım Olarak Kodla" ile başlamanızı öneririm .
Doc Brown


@DocBrown. Kodlama sırasında tasarımın işimizi bu kadar usta yapan şey olduğunu düşünmüyor musunuz? Diğer mühendislerin de aynı şekilde çalıştığını hayal edemiyorum. Bir mimarın tuğlaları ve harcı boncukladığını ve yolda binayı / köprüyü tasarladığını düşünün.
Laiv

5
@Laiv: "kodlama", diğer mühendis disiplinlerinde tasarım olarak adlandırılan şeyin bir parçasıdır . Konut binasında, tasarımdan son ürüne kadar olan adım, boncuklanma tuğlaları ve harç kullanılarak yapılır. Programlamada, bu adım, tasarım (= program) son ürüne (= çalıştırılabilir ikili) çevrilirken derleyici tarafından gerçekleştirilir. Ve bu yeni bir bilgelik değil. Reeves denemeleri 25 yaşında.
Doc Brown

@DocBrown, geliştirici. * Artık küratörlüğünü yapmıyor mu? Örneğin abone ol düğmesi bozuk.
radarbob

Yanıtlar:


20

Yukarıdan aşağıya şelale stili OOAD, yazdığınız kodun nesne yönelimli olmasını sağlamaz. Ben kesinlikle kanıtlayan kod üretilen OOAD dağları gördüm. OO sizi karıştırıyorsa, yardım için buraya bakmayın. Bulamayacaksın. OO, yukarıdan aşağıya tasarım yapmanızı gerektirmez.

Eğer bir sınıfa dalmak nasıl kodlamak isterseniz, öyle olsun. Size bir ipucu vereyim. Procrastinate.

Henüz mevcut olmadıklarında bile bunları kullanan kod yazarak sınıfları tasarlamak ne kadar kolay. Prosedürü unut. Yapıyı unutun. Sadece kendinize güzel ve tutarlı bir soyutlama seviyesi alın ve onunla devam edin. Günaha girmeyin ve ekstra detayları karıştırmayın. Sizi mevcut soyutlamadan çıkaran her şey, bir şekilde bilmesi gereken her şeyi bilen başka bir nesnede olabilecek bazı yöntemlerde yapılabilir. Size teslim edilmesini isteyebileceğiniz hiçbir şey inşa etmeyin.

Böyle yazmayı öğrenin ve çok uğraşmadan OO yaptığınızı göreceksiniz. Bu sizi nesnelerinize nasıl kullanıldıkları (arayüzleri) ve hangi nesnelerin hangi diğer nesneler hakkında bilgi sahibi oldukları bakış açısından bakmaya zorlar. Bir UML diyagramları ana iki nokta nedir tahmin edin?

Eğer o düşünme biçimine girebilirseniz geriye kalan mimari olur. Hepimiz hala çözüyoruz. MVC'den temiz mimariye, alan güdümlü tasarıma. Onları inceleyin ve oynayın. Neyin işe yaradığını kullanın. % 100 güvenilir bir şey bulursanız geri dönün ve bana bildirin. Bunu onlarca yıldır yapıyor ve hala bakıyorum.


2
Ya da kendinizi OO yapmadığınızı görüyorsunuz ve yine de "her şey" her şey yolunda gidiyor ...
Derek Elkins SE

2
"Henüz var olmadıklarında bile onları kullanan kod yazarak sınıflar tasarlamak ne kadar kolay" - Bu yukarıdan aşağıya tasarım diyorum, ama yanıldığım anlaşılıyor. Yukarıdan aşağıya tasarım nedir ve buna ne denir? Bir arayüze mi programlama?
Piovezan

Sadece yukarıdan aşağıya değil. Ayrıca, parametreleri kabul ederek isteyebileceğiniz şeyleri inşa etmemeye de istekli olmalısınız.
candied_orange

@Piovezan, arayüz henüz mevcut olmasa bile bunu yapabilirsiniz. Derleyicinizi bir süreliğine görmezden gelin. Daha sonra, var olursunuz.
candied_orange

@CandiedOrange "Ayrıca, parametreleri kabul ederek isteyebileceğiniz şeyleri inşa etmemeye de istekli olmalısınız." - Anladığımdan emin değilim, lütfen kısa bir örnek (veya bu konu için karşı örnek) açıklığa kavuşturabilir misiniz?
Piovezan

4

Kodunuzda nesne yönelimli teknikleri kullanabileceğinizi iddia edersiniz, bu nedenle zaten bir nesne yönelimli sistemi nasıl tasarlayacağınızı bilmenizle , probleminizin ne zaman yapılacağına , yapamayacağınıza ya da yapamayacağınıza inanıyorum . Nesneye yönelik tasarımda uzun vadeli bir planlama yöntemi yerine kısa vadeli yinelemeli bir şekilde rahat görünüyorsunuz.

Bir projeyi ilk kez geliştirirken planlamak ve tasarlamak çok zor olabilir , şelale planının büyük kapsamı genellikle bir yazılım projesinin tüm karmaşıklıklarını yakalamayacağından, şelale gelişimi üzerinde çevik gelişimin tercih edildiği zamandır .

"Başlangıç ​​planı" olmadan anında geliştirmenin şu şekildedir:

"... yazılım oluşturmanın doğru yolu değil ..."

Sorununuz ilk planınızın yeterince ayrıntılı olmamasıysa, ilk düşüncelerinizi açıklamak için biraz daha zaman ayırın. Yazmayı planladığınız programın ilk bölümü nedir ? Neye ihtiyacı olacak ? Belki hangi nesnelerle başlayacağınızı düşünmeyin, bunun yerine hangi özellikleri ve planlamayı düşünün.

Sorununuz belgeleme / tasarım / UML becerilerinizden emin değilseniz , mevcut bir projeyi belgeleyerek pratik yapın.

Şahsen tasarımlarınızın mükemmel nesne yönelimli olması konusunda endişelenmemenizi tavsiye ederim, çoğu sistem% 100 nesne yönelimli değildir. Amaç, mükemmel bir soyutlama değil, sistemin daha iyi anlaşılmasını ve görselleştirilmesini sağlamaktır. Nesne yönelimi gümüş mermi değil, kemerdeki başka bir araçtır.


Ayrıca, cevap için konu dışı da olsa bahsetmek istedim ... Planlarınızın çok büyük olmasına gerek yok! Bazen bir plan sadece "Onu çalıştırmak istiyorum ve bir şey yapar" meselesidir. Yeterince iyi, eğer gerçekten yapacaksa.
Erdrik Ironrose

2

OOAD bir ütopyadır. Bununla bunun en iyi yaklaşım olduğunu kastetmiyorum, yani alçakgönüllü görüşüme göre hiçbir zaman gerçekten ulaşılamaz. Deneyimlerime göre, bir şey her zaman değişir, gereksinimler veya ayrıntılar olsun, hatta sizi bir bağımlılığı tamamen değiştirmeye zorlayan bir bağımlılık çatışması. İster bu şekilde öğrendim, isterse benim için en doğal olan şey bu olsun, tasarım için fikirlerim kod yazarken çok kolay geliyor. Kodlamak üzereysem ve kodu nasıl yapılandıracağım konusunda net bir fikrim yoksa, ilk önce problemi gerçekten anlamak için zaman ayırmaya çalışacağım, daha sık olmamakla birlikte, görüyorum bir sınıfa ihtiyacım var ve ben yaparım

Benim tavsiyem, kendiniz için yapabileceğiniz en iyi şeyin cepheleri kullanarak kod girmesi , giriş ve çıkış için basit bir arayüz sağlaması ve giriş ve çıkışların sık sık değişmemesini ummasıdır. Olsalar bile, bir teknik sorun olduğu kadar bir tasarım sorunu olmadığını bilin (gereklilik / çalışma / işlevsellik değişikliği). Bu, programınızı, programınızı veya kod bölümünü çağıranlara karşı programınızda yankılanan sorunlara karşı biraz dirençli hale getirecektir.

Nesne yönelimli bir sistemin tasarlanması ile ilgili olarak, her şeyi nesne yönelimli olmayacak şekilde yapmaya çalışmak için bir şey söylenmelidir. Bu, C # ve Java gibi OOP programlama dilleri arasında yaygın bir hatadır, her şeyi bir nesne olarak ele almaya çalışmaktır, bu da genellikle durumu değiştirmeyen statik yöntemler olabilecek bir işlemi gerçekleştirmek için bir sınıfın tek bir örneğini oluşturmaya neden olur. Bununla birlikte, elbette, uygun olan yerlerde OOP tasarımını kullanmalısınız, ancak statik bir yöntem yazmak daha doğal olduğunda yanlış yaptığınızı hissetmeyin. Bu her zaman yanlış içgüdü değildir.

Aşağıdaki sorulardan herhangi birine evet yanıtı verirken bir sınıf kullanmayı düşünmelisiniz:

  • Aynı kavramla ilgili bir grup bilgim var mı (yani ad, soyadı, adres)?
  • Birkaç parça bilgi gerektiren bir işlem yapmam gerekir mi (örn. calculatePrice(basePrice, quantity, tax))?
  • Aynı veya benzer bilgilerle (yani if(type == "cat") { meow(name); } else if (type == "dog") { bark(name); }==> animal.speak()) biraz farklı işlemler yapan büyük kod blokları ile başka bir var mı
  • Birden fazla özel görevi yerine getiren ve biraz fazla büyüyen bir sınıfım var mı?

Bir süre sonra, sınıflar yaratmak ikinci doğa olacak. Kodunuz yukarıdaki durumlardan birine girerse bunları kullanmaktan korkmayın. Umarım bu yardımcı olur!


2

Doc Brown'ın yorumlarda belirttiği noktaların, kesinlikle doğru olduğu için bir yorumdan çok daha fazla görünürlüğü hak ettiğini düşünüyorum :

" Şimdi bunun yazılım oluşturmak için uygun bir yol olmadığını biliyorum " - bunu kim söyledi? Bir şekilde "tasarım kodlamadan önce, belki süslü UML diyagramları çizerek yaptığınız bir şeydir" inanmak gibi popüler tuzağa düşüyor gibi görünüyor. Sizi bu yanlış anlamadan kurtarmak için, Jack Reeves tarafından "Tasarım Olarak Kodla" ile başlamanızı öneririm . - Doc Brown 21 Haziran, 5:27

@Laiv: "kodlama", diğer mühendis disiplinlerinde tasarım olarak adlandırılan şeyin bir parçasıdır. Konut binasında, tasarımdan son ürüne kadar olan adım, boncuklanma tuğlaları ve harç kullanılarak yapılır. Programlamada, bu adım, tasarım (= program) son ürüne (= çalıştırılabilir ikili) çevrilirken derleyici tarafından gerçekleştirilir. Ve bu yeni bir bilgelik değil. Reeves denemeleri 25 yaşında. - Doc Brown 21 Haziran, 6:39

Aynı duygu başka yerlerde de yankılanıyor. Glenn Vanderburg'un "Gerçek Yazılım Mühendisliği" ve bir dereceye kadar "El Sanatları, Mühendislik ve Programlamanın Özü" ve "El Sanatları ve Yazılım Mühendisliği" görüşmelerini düşünün . Ayrıca C2 wiki'deki WhatIsSoftwareDesign ve TheSourceCodeIsTheDesign sayfalarını / tartışmalarını da göz önünde bulundurun .

Kodun tasarım olduğu kavramı herhangi bir paradigmaya özgü değildir. Nesne yönelimli, fonksiyonel, prosedürel, mantık veya başka herhangi bir şeye eşit olarak uygulanabilir. Temel fikir aynıdır - tasarım kaynak kodunun kendisidir. İnşaat eylemi, kaynak kodunun (tasarım) bir tercüman veya derleyici tarafından kullanılabilir bir şeye dönüştürüldüğü süreçtir.

Karmaşık bir sistemde, alt düzeyleri, bileşenleri, modülleri, hizmetleri tanımlamak ve kod yazmaya başlamadan önce bunlara gereksinimleri tahsis etmek için bir miktar üst düzey mimari tasarım olması muhtemeldir. UML'yi bu mimari tasarım etrafında tartışmalar yaratmanın, belgelemenin ve yardımcı olmanın bir yolu olarak kullanabilirsiniz. Fikrini düşünün UML Modları Martin Fowler tartışıyor olduğunu , özellikle bir Kroki olarak UML ve Notlar gibi UML . Ayrıca Çevik Modelleme - İlk Mimari Modelleme , İterasyon Modelleme ve Sadece Yeterince İyi Yeterli modellerden bazı fikirleri göz önünde bulundurun .

Tüm bunlar, yazılım oluşturmanın doğru yolunun, projenin tamamını etkilememek olduğu anlamına gelir. En kritik (zamanın şu andaki noktasında) gereksinimleri anlamak, gereksinimler arasındaki teknik bağımlılıkları ve ödünleşimleri belirlemek ve ardından yazılımın yumuşak olmasından yararlanmak için yeterli zaman harcamaktır. Ayrıca tasarımınızı almanın ve bir şey üretmenin maliyetinin inanılmaz derecede düşük olduğunu unutmayın (özellikle bir tasarım almak ve diğer birçok mühendislik dalında bir şey üretmekle karşılaştırıldığında). Bu nedenle tasarım (kodlama) faaliyetlerinizi tekrarlayın ve yaptığınız işi aşamalı olarak oluşturmanın veya değiştirmenin ne kadar kolay ve ucuz olduğundan yararlanın.


1

OOAD, varlıkları tanımlamak ve gerçek hayattaki nesneleri veya kavramları bir ölçüde soyutlamaya modellemekle ilgilidir. İlk başta yazma arayüzleri sınıfları yazmak yerine, onları henüz uygulamak zorunda değilsiniz, ancak kod derliyorsa, bunu daha kolay olarak algılayacaksınız.

OOAD, büyük modüller olarak sistemde düşünme olasılığını dışlamaz. Bunu hala yapabilirsiniz. Her modül, bir dizi kullanıcı öyküsünü karşılamak için mevcuttur (kullanım örnekleri). Bu tür kullanıcı hikayeleri, bunları yerine getirmek için işbirliği yapan sınıflara ihtiyaç duyar.

Prosedürel bir OO yaklaşımı arasındaki önemli bir fark, genellikle prosedürel düşünmenin gereksinimleri ekranlarla eşleştirmesidir, oysa OOD, ön ucun başka bir kişi tarafından yapılmasını veya OO olmayan bir şekilde yapılmasını sağlayan başlık altında neler olduğunu düşünme eğilimindedir.

Ekstrem Programlamada CRC Kartları adı verilen bir teknik var . CRC, "sınıf sorumlulukları-ortak çalışanlar" anlamına gelir.

Temel olarak belirgin sınıfları tanımlar ve her birine bir kart atarsınız. Diyelim ki sınıfın Invoicekendi kartı var.

Her kart tutma sınıfı için, o sınıfın sorumluluklarının ne olacağını yazarsınız, örneğin "genel bir toplamı hesaplar" .

Ayrıca her kart tutma sınıfı için, sınıfın kendi sorumluluklarını yerine getirmesi için başka hangi sınıflardan talep etmesi gerektiğini yazarsınız. Burada Invoiceişbirliğinin ihtiyaçlarını InvoiceDetailkeşfedebilir, hatta ilk etapta böyle bir sınıfın gerekli olduğunu keşfedebilirsiniz.

Ait olduğunuzu düşündüğünüz bazı sorumlulukların Invocegerçekten ortak çalışanlarından birine ait olduğunu keşfedebilirsiniz .

Alıştırmadan sonra, her kart bir sınıf haline gelir, her sorumluluk bir yöntem haline gelir ve her işbirliği ilişkisi bir kompozisyon, anlaşma veya salt çağrı haline gelebilir.

Bu alıştırma, iş adamlarının bile katılım gösterdiği bir grupta yapılabilir (ve yapılmalıdır).

Bu teknik hakkında daha fazla bilgiyi şu bağlantılardan edinebilirsiniz:

http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card

http://www.extremeprogramming.org/rules/crccards.html

CRC kartlarına örnekler:

resim açıklamasını buraya girin

resim açıklamasını buraya girin

resim açıklamasını buraya girin


0

Yazılım uygulayıcıları topluluğu olarak bizim için en büyük zorluk; daha spesifik olarak nesne yönelimli tasarım uygulayıcıları, tüm problemlerimizi / görevlerimizi bir programlama bilgisine dönüştürmektir. Öyle ol görevler - olarak temsil fonksiyonları veya olması aktörler olarak temsil - görevlerin arayüzleri / sınıfları [NYAT doğru sürüş]. Yazılım tasarım alışkanlıklarımızı geliştirdikçe, sürekli olarak çeşitli metodolojiler / çerçeveler hakkında bilgi edinerek. Bizim bakış açımız, nesneleri ve hangi nesnenin hangi işlevi yerine getireceğini açıkça ayırmak için gittikçe daha rafine hale geliyor.

Sorunlarınızı etraftaki nesnelerin varlığıyla alt problemlere bölmek için, bunu kolayca yapabilirsiniz, çünkü SİZİN hangi nesnelerin mevcut olmasını istediğinizin tam kontrolüne sahipsiniz. Ayrıca nesnelerinize ve arayüzlerinize doğa ve amaç kazandırmak kolaylığına da sahipsiniz. Tek yapmanız gereken, problem ifadesini görselleştirmek ve hangi amaca / işlevselliğe hangi nesneye verilebileceğini düşünmektir.

Bir dizi otomobilin yardımıyla daha fazla açıklamaya çalışacağım ve aynı nesne modelini görselleştirmenin iki farklı yolunu vurgulayacağım.

Çeşitli otomobil kategorilerine yayılan otomobil üreticisine bir örnek verin: ticari araçlar, tüketici arabaları (sedanlar, hatchback, istasyon vagonları) vb.

Üreticinin açıkça bir kategori ve amaç ayrımı yapması için orada sınıflar oluşturabilmelerinin birden fazla yolu vardır.

Araç Üreticisi OOAD

  1. Aracın kategorisine (pazar sektörü) göre: Ağır vasıta, tüketici aracı [sedan, hatchback, station wagon vb.]

  2. Motor kapasitesi ve sürüş şekline göre: 800-1500 CC,> 1500 CC vb.

Üreticinin bu sınıflandırmaların her birine ait nesnelere ayrı ayrı işlev verebileceği en iyi yoldan geçerek , uygun bir temel nesne tasarımı seçebilir ve bunun üzerine model oluşturabilirler.


Tamam başlıyorsunuz, ancak son bit, OOD'un benzer davranışları gruplamak yerine bir şeyleri kategorilere ayırmakla ilgili yanılgıya benziyor.
Pete Kirkham
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.