“Yönetici” sınıflarının kullanımının nasıl azaltılacağına dair ipuçları / tavsiyeler?

Bazen programınızın tasarımında çok fazla "yönetici" sınıfına sahip olmanın kod kokusu olduğunu ve gereksiz bir karmaşıklık katmanı eklediğini duyuyorum. Benim için insanların, kendileri için anlamlı bir bağlamdan nesneleri manipüle etmek ve kontrol etmek için yönetici sınıflarını kullanmak istedikleri mantıklı, ancak onlar olmadan bir çözümün nasıl çalışacağını bulmak kafa karıştırıcı olabilir.

Mümkün olduğunca yönetici sınıflarından kaçınmalı mı? Ayrıca, bu yöneticilerin kaldırılabileceği genel / yaygın durumlar için alternatif bir çalışmanın nasıl uygulanacağı hakkında hangi makaleleri / makaleleri okumalıyım?

Bunun bir kod kokusu olmasının iki nedeni olabilir. Bunun bir nedeni, etki alanı nesnelerinizin olmadığı anlamına gelebilir, ancak bunun yerine yalnızca denetleyici veya yönetici sınıfları tarafından manipülasyon için veri depolayan değer nesnelerinizin olması olabilir. Bu aslında oldukça yaygındır ve bir OO dilinde prosedürel programlama anlamına gelir. "Çok sayıda yönetici", durum mantığını, doğrulamayı ve diğer doğrudan endişeleri etki alanı nesnelerine entegre etmeniz için bir ipucu olabilir, böylece bir şeyi gerçekten kapsülleyebilirler. Tabii ki, alıcı / ayarlayıcılardan başka yönteminiz olmadığı gibi daha büyük ipuçları var.

Kod kokusunun diğer nedeni, etki alanı nesnelerinizin aslında birbiriyle çok iyi ilişkili olmadığı anlamına gelebilir. Örneğin, Transaction sınıfı dışında Transaction adı dışında hiçbir şey bilmeyen bir Account sınıfınız varsa ve bunlardan birden fazla olabilirse, yine de gerçekten çok hareketli bir iş etki alanı uygulamanız yoktur. Örneğin, SavingsAccount, accountStatus kapatılırsa DebitTransaction'ı kabul edemeyeceğini bilmelidir. Birçok uygulama bunu yöneticiye bırakacaktır.

Çok sayıda "yönetici" sınıfına sahip olmak, genellikle etki alanı mantığının etki alanı modelinden kaldırıldığı ve bunun yerine az çok işlem komut dosyalarına eşit olan yönetici sınıflarına yerleştirildiği anemik bir etki alanı modelinin bir belirtisidir . Buradaki tehlike, temel olarak prosedürel programlamaya geri dönmenizdir - projenize bağlı olarak kendi başına iyi bir şey olabilir veya olmayabilir - ancak düşünülmediği veya amaçlanmadığı gerçeği "kod kokusu" imo'dur.

"Bilgi uzmanı" ilkesinin ardından, mantıksal bir işlem, gerektirdiği verilere olabildiğince yakın oturmalıdır. Bu, etki alanı mantığının etki alanı modeline geri taşınması anlamına gelir, böylece etki alanı modelinin durumunu dışarıdan değiştiren işlem komut dosyaları yerine etki alanı modelinin durumu üzerinde gözlemlenebilir bir etkiye sahip olan bu mantıksal işlemler olur.

Yönetici Sınıfları ile ilgili en büyük sorun, sadece sınıfın ne yapması gerektiği konusundaki bu belirsiz fikri temsil etmeleridir. Bir şeyi Yönetici olarak adlandırırsanız, yönettiği her şeyle ilgili her şeyi ve mümkün olan her şeyi yapabilir. Herhalde iyi olabilecek bazı bağlamlarda, ama hemen hemen her durumda istediğiniz şey olmadığını söyleyebilirim. Birinin sınıf adına bakmasını ve sadece sınıfın ne yaptığına dair iyi bir fikir sahibi olmakla kalmayıp aynı zamanda ne yapmadığını da bilmesini istiyorsunuz.

Yönetici sınıflarıyla ilgili bir diğer sorun da işlevselliklerin nereye gitmesi gerektiğine karar vermeyi çok zorlaştırmasıdır. Çok sayıda yönetici sınıfı olduğunda, yönetici sınıfları arasında işlevsellikte genellikle çok fazla çakışma vardır. Daha sonra, hangi sınıfın çakışan işlevselliği uygulaması gerektiğini ve elbette başka birinin farklı seçeceğini anlamanız gerekir. Bu yüzden işlevselliği aradıklarında ve bekledikleri yerde görmediklerinde, diğer uygulamanın varlığının farkında olmadıkları için, devam ettiklerini ve ait olduklarını düşündükleri yerde yeniden uygularlar. Başka bir deyişle, yönetici sınıfları anlaşılması zor ve sık sık kıvrımlı tasarımlara yol açar.