OOP'larda sınıf tasarımına nasıl yaklaşıyorsunuz?

Bir OO çözümü tasarlamaya çalıştığımda, genellikle sınıf adlarını (isimler), yaptıkları şeyi (fiiller) ve diğer sınıflarla nasıl işbirliği yaptıklarını listelediğim CRC modellemesini kullanıyorum .

Bu blog , bu isim-fiil yaklaşımı hakkında söylenecek aşağıdaki şeylere sahiptir

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

Sorum şu: OO yaklaşımını kullanmak için daha iyi bir modelleme tekniği var mı?

Adil olmak gerekirse, bu iddiaya "Eğlenceli" ifadesini ekledi.

Bugüne kadar, sistemleri "isim ve fiil" yaklaşımını kullanarak modelleme eğilimindeyim, ancak yıllar içinde TDD'nin bize bu yaklaşımın odak noktanızı yanlış şeye çektiğini öğrettiğini gördüm. Bu anlamda blog yazarının bir anlamı var. Ancak, aklımızın çalışma biçiminden ziyade, hataya yaklaşımın bu olduğundan emin değilim.

Burada küçük bir meydan okuma denemek istiyorsanız, okumayı bırakın ve İngilizceyi kullanarak Tekel oyununu modellemeye çalışın, sonra buraya geri dönün.

Günaha çok etkileşimde bulunduğumuz nesnelere - tahta, boşluklar, kartlar, zarlar, parçalar - hemen bakmak olacağından şüpheleniyorum, ama mantığın büyük kısmı bu değil. Bu nesnelerin çoğu tamamen aptal. Veri, eğer istersen.

Ancak, testler yazmaya başlar başlamaz, hangi nesnenin herhangi bir oyunda en önemli olduğunu fark edersiniz: kurallar.

Oyunu ilk aldığınızda bir kez okuduğunuz ve bir anlaşmazlık olana kadar tekrar etkileşimde bulunmadığınız küçük kağıt parçasını hatırlıyor musunuz? Bilgisayarlı sürüm bu şekilde çalışmaz. Oyuncunun yapmaya çalıştığı her şey, bir bilgisayar kurallara bakacak ve izin verilip verilmediğini görecektir.

Bunu düşündüğünüzde aynı şeyi yaparsınız, ancak kağıt tabanlı kuralları okumak zaman alır ve beyninizin makul bir önbellekleme sistemi olduğundan, kafanızdaki kurallara danışırsınız. Bir bilgisayar, veritabanında depolanmadığı sürece, kuralları tekrar okumayı muhtemelen bu kadar kolay bulacaktır, bu durumda da bunları önbelleğe alabilir.

İşte bu yüzden TDD aslında tasarımı yönlendirmek için çok popüler. Çünkü düşünce sürecinizi hızlı bir şekilde doğru yerlere yönlendirme eğilimindedir:

Tekel oyunum için bazı testler yazacağımı düşündüğümde. Kümeme bakıp nesneleri bulmaya çalışabilirim. Yani, bu parçalara sahibiz. Bunlar için bazı testler yazacağım.

Belki bir MonopolyPiece temel sınıfım olacak ve her bir parça bu türden türeyecek. DogPiece ile başlayacağım. İlk test ... ahh. Aslında burada mantık yok. Evet, her parça farklı şekilde çizilecek, bu yüzden bir DogDrawer'a ihtiyacım olabilir, ancak oyunu bitirirken, sadece ekrana "D" yazmak istiyorum. Sonunda kullanıcı arayüzünü renklendireceğim.

Test etmek için gerçek bir mantık bulalım. Bu evlerin ve otellerin çoğu var, ama testlere ihtiyaçları yok. Para yok. Mülkiyet kartları, hayır. Ve bunun gibi. Tahta bir devlet makinesinden başka bir şey değildir, herhangi bir mantık içermez.

Elinizde üç şeyin kaldığını çabucak bulacaksınız. Şans ve Toplum Sandığı kartları, bir çift zar ve bir dizi kural. Bunlar tasarlanması ve test edilmesi gereken önemli parçalar olacaktır.

İsimleri ve fiilleri yazdığınızda bunun geldiğini gördünüz mü?

Aslında, Robert Martin Agile Principles Patterns and Practices'de TDD kullanarak bir Bowling Score Card uygulamasını kullanmaya ve açık sınıfların uğraşmaya değer olmadığını düşündükleri her türlü şeyi bulmaya çalıştıkları harika bir örnek var .

Benim için hiç böyle yöntemler bulamadım. Aslında onları kullanmanın beni daha da karıştırdığını fark ettim. Check out Robert C. Martin Kahve Makinesi , onun da bu tür bir yaklaşımı kullanır sanmıyorum.

Beni rahatsız eden bir şey, bağlandığınız CRC makalesinde kişinin geldiği çözümdür. Müşteri / Sipariş işbirliği, değerli bulduğum bir şey değil, yine de yazıldığı gibi değil. Bu modelde, Sınıf durumunu hak eden bir Müşteri hakkında özellikle ilginç bir şey yoktur. Bir "müşteri" olma konusunda tek şey ilginç bununla ilişkili bir veya daha fazla siparişleriniz olmasıdır Kişi .

Ayrıca kolej modeli. Öğrenci ve Profesör arasında paylaşılabilecek ve muhtemelen paylaşılması gereken çok şey var. Dahası, üniversite kampüslerinde ücretsiz olarak izin verilen bir Profesör ders aldığında ne olur?

Sanırım bu değerli bir uygulama, tasarım araç setindeki bir unsur olabilir. Yine de tasarıma en azından yaklaşmanın tek yolu olması gerektiğini düşünmüyorum. Açıkçası, ben ortaklık / varyasyon analizi yaklaşımını daha yararlı buluyorum. Bana öyle geliyor ki günlük yaşamda soyutlamaları sınıflandırmak için ne yaptığımızı çok yakından modelleniyor.

Edit: Sadece o ikinci blogun yarısını okuyun ve ben oldukça katılıyorum söylemek gerekir. Gerisini okumak ve öğrenme açısından neler sunduğunu görmek zorundayım.

Bence endişeleri ayırmak ve bağımlılıkları azaltmak için kodlar olarak sınıflar eklenmeli (ve kaldırılmalıdır). Tasarım modellerinde akıcı olmak, yeniden düzenleme ve basitleştirme olasılıklarını görmek için muhtemelen iyi bir bahistir.

Sınıflar genellikle benim tecrübelerime göre, isim / fiil kategorilerine düzgün bir şekilde girmez, aksine farklı desen sınıfları (fabrikalar, singletonlar, strateji kalıpları vb.) Ve diğer yönetici sınıfları ile birlikte bir isim / fiil sınıfları karışımı ile sonuçlanırsınız. uygulamanızın bir yönünü ele alır.

Önemli olan, amacınız bir sınıfa bakıp ne yaptığını ortaya çıkarmak ve bunu sadece o sınıfı değiştirerek değiştirmek olmalıdır. Uygulamanızın bir yönü için ne kadar fazla kod sınıflar arasında yayılırsa, onu takip etmek, yönetmek ve genişletmek o kadar zorlaşır.