Yönetici sınıfları kötü mimarinin bir işareti olabilir mi?

Son zamanlarda, tasarımınızda birçok yönetici sınıfının olmasının kötü bir şey olduğunu düşünmeye başladım. Bu fikir benim için zorlayıcı bir tartışma yapmam için yeterince olgunlaşmamış, ancak işte birkaç genel nokta:

• Ağır bir şekilde “yöneticilere” dayanan sistemleri anlamak benim için çok daha zor oldu. Bunun nedeni, gerçek program bileşenlerine ek olarak, yöneticinin nasıl ve neden kullanıldığını da anlamanızdır.

• Yöneticiler, çoğu zaman, programcının programı Just Work ^TM yapmanın bir yolunu bulamaması ve her şeyin doğru çalışmasını sağlamak için yönetici sınıflarına güvenmesi gerektiğindeki gibi, tasarımla ilgili bir sorunu hafifletmek için kullanılıyor gibi görünmektedir .

Tabii ki, yemlik iyi olabilir. Açık bir örnek, EventManagertüm zamanların en sevdiğim yapılarından biri. : P Demek istediğim, yöneticilerin çoğu zaman fazla kullandığı ve program mimarisiyle ilgili bir sorunu maskelemek dışında iyi bir sebep olmadığı görülüyor.

Yönetici sınıfları gerçekten kötü mimarinin bir işareti midir?

Yönetici sınıfları, birkaç nedenden dolayı, kötü bir mimarinin işareti olabilir:

• Anlamsız Tanımlayıcılar

  Adı FooManagersınıfı aslında neyi hakkında hiçbir şey söylemez yapar , bu şekilde içerdiğini hariç Fooörneklerini. Sınıfa daha anlamlı bir ad verilmesi, yeniden yapılanmalara yol açacak olan gerçek amacını açıklar.

• Kesirli Sorumluluklar

  Tek sorumluluk ilkesine göre, her bir kod birimi tam olarak bir amaca hizmet etmelidir. Bir yöneticiyle, bu sorumluluğu yapay olarak bölüyor olabilirsiniz.

  Örneklerin ResourceManageryaşamlarını ve bunlara erişimi koordine eden bir düşünün Resource. Bir uygulamanın, örnekleri ResourceManageredindiği bir tanesi var Resource. Bu durumda, bir ResourceManagerörneğin işlevinin Resourcesınıftaki statik yöntemlerle yerine getirilememesi için gerçek bir neden yoktur .

• Yapılandırılmamış Soyutlama

  Genellikle bir yönetici, yönettiği nesnelerle ilgili temel sorunları soyutlamak için tanıtılır. Bu nedenle yöneticiler, kötü tasarlanmış sistemler için yara bandı olarak kötüye kullanma konusunda kendilerini ödünç veriyor. Soyutlama, karmaşık bir sistemi basitleştirmek için iyi bir yoldur, ancak “yönetici” adı , soyutlamanın yapısı hakkında hiçbir ipucu vermez . Gerçekten bir fabrika mı yoksa bir vekil ya da başka bir şey mi?

Tabii ki, yöneticiler aynı sebeplerden ötürü kötülükten daha fazlası için kullanılabilirler. Bir EventManagerolan -ki gerçekten Dispatcherkaynaklar ve ilgi hedeflere onları harekât olayları -queues. Bu durumda, olayları alma ve gönderme sorumluluğunu ortadan kaldırmak mantıklıdır, çünkü bir birey Eventsadece bir kanıt veya hedef fikri olmayan bir mesajdır.

Biz yazma Dispatcherait Eventbir yazma temelde aynı nedenle durumlarda GarbageCollectorveya Factory:

Bir yönetici, yükünün neye ihtiyacı olduğunu bilmemesi gerektiğini bilir.

Bence, yönetici benzeri bir sınıf yaratmanın en iyi nedeni budur. Bir değer gibi davranan bazı “yük” nesnesine sahip olduğunuzda, genel sistemin esnek kalması için mümkün olduğunca aptal olması gerekir. Bireysel örneklere anlam vermek için, bu örnekleri anlamlı bir şekilde koordine eden bir yönetici oluşturursunuz . Başka bir durumda, yöneticiler gereksizdir.

Yöneticiler , kötü bir mimarinin işareti olabilir , ancak çoğu zaman, tasarımcı adına nesnelerinin daha iyi isimlerle karşı karşıya kalmamasının bir işareti veya sadece İngilizcenin sadece bir gerçeğin bir yansıması olduğuna dair bir işaret değildir. (ve bu konuda herhangi bir insan dili) günlük pratik kavramları iletmek için uygundur ve son derece soyut, yüksek teknik kavramları değil.

Amacımı açıklamak için basit bir örnek: Fabrika Şablonu seçilmeden önce insanlar onu kullanıyordu, ama nasıl çağırılacağını bilmiyorlardı. Bu yüzden, Foosınıfı için bir fabrika yazmak zorunda olan biri aramış olabilir FooAllocationManager. Bu kötü tasarım değil, sadece hayal gücü eksikliği.

Ve sonra birinin çok sayıda fabrikayı barındıran ve onları isteyen çeşitli nesnelere dağıtan bir sınıf uygulaması gerekiyor; ve sınıfını çağırdı, FactoryManagerçünkü kelime Industryhiç bir zaman onun başına gelmedi, ya da bunun cool olacağını düşündü çünkü programlamada böyle bir şeyi daha önce hiç duymamıştı. Yine, hayal gücü eksikliği bir durum.

Çok sayıda "yönetici" sınıfına sahip olmak, genellikle etki alanı mantığının etki alanı modelinden çıkarıldığı ve bunun yerine işlem komut dosyalarına eşit veya daha az 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 - kendi başınıza, projenize bağlı olarak iyi bir şey olabilir veya olmayabilir - ama bunun düşünülmemesi veya amaçlanmaması gerçek sorun imo.

"Bilgi uzmanı" ilkesini takiben, mantıksal bir işlem mümkün olduğu kadar verilere yakın durmalıdır. Bu, etki alanı mantığının etki alanı modeline geri taşınması anlamına gelir; bu, etki alanı modelinin durumunu dışardan değiştiren 'yöneticiler' yerine etki alanı modelinin durumu üzerinde gözlenebilir bir etkiye sahip olan bu mantıksal işlemlerdir.

Kısa cevap: duruma göre değişir .

Bazı “yönetici sınıfları” nın farklı biçimleri vardır, bazıları iyi, bazıları kötüdür ve çoğu için, eğer yönetici sınıfını tanıtmak doğru şeyse, içeriğe çok bağlıdır. Onları doğru yapmak için iyi bir başlangıç ​​noktası, tek sorumluluk ilkesini takip etmektir - yönetici sınıfınızın her birinin neyin sorumlu olduğunu (ve neyin olmadığını) biliyorsanız, onları anlamada daha az sorun yaşayacaksınız.

Veya sorunuzu doğrudan cevaplamak için: kötü bir yapıya işaret eden yönetici sınıflarının sayısı değildir, ancak çoğu bilinmeyen sorumlulukları olan veya çok fazla kaygıyla başa çıkabilen yöneticilerin sayısıdır.

Her ne kadar doğal olarak kötü bir tasarımın göstergesi olduklarını söylemek kolay olsa da, proje boyunca tek bir görevi ve sorumluluğu evrensel olarak kapsayarak çok iyi şeyler getirmeye ve proje boyunca kod karmaşıklığını ve diğer kaynak kodunu azaltmaya hizmet edebilir.

Yöneticilerin yaygınlığı, tasarım konusundaki kötü kararlardan dolayı olabilirken, aynı zamanda kötü tasarım kararlarını veya uyumsuzluk sorunlarını, bileşenli bir tasarım veya üçüncü taraf UI bileşenlerinde veya garip bir arayüze sahip üçüncü taraf web hizmetlerinde ele almak olabilir. örnekler olarak.

Bu örnekler, genel karmaşıklığı azaltmada ve "çirkin kodunu" tek bir yerde kapatarak çeşitli bileşenler ve katmanlar arasında gevşek birleşmeyi teşvik etmede bazı durumlar için çok faydalı olduklarını göstermektedir. Bunlardan biri, insanların Yöneticileri tek tek yapmak için cazip bulmaları, bununla ilgili tavsiyelerde bulunmaları ve elbette diğerlerinin Tek Sorumluluk İlkesi'nin her zaman takip edilmesi gerektiği yönünde önerileri olması.

Yönetici sınıfları kötü mimarinin bir işareti olabilir mi?

Sorunuzu cevapladınız: kötü bir tasarımın işareti olmaları gerekmez.

EventManager ile ilgili sorunuzdaki örnek dışında, başka bir örnek daha var: MVC tasarım modelinde, sunum yapan kişi model / görünüm sınıfları için bir yönetici olarak görülebilir.

Bununla birlikte, bir kavramı kötüye kullanırsanız, o zaman kötü bir tasarım ve muhtemelen mimarinin bir işaretidir.

Sınıfın adı “Yönetici” olduğunda, tanrı sınıfı sorununa dikkat edin (biri çok fazla sorumluluğu olan). Bir sınıfın neyle sorumlu olduğunu açıklamak zorsa, bu bir tasarım uyarı işaretidir.

Kötü yönetici sınıfları bir yana, gördüğüm en kötü isim "DataContainerAdapter" idi.

"Veri", adlarda yasaklanan alt dizgilerden bir başkası olmalıdır - hepsi veridir, "veri" çoğu alanda çok fazla şey söylemez.

Yönetici sınıfları - tıpkı "-er" ile biten herhangi bir sınıf gibi - kötüdür ve OOP ile ilgisi yoktur. Bu yüzden benim için kötü mimarinin bir işareti.

Neden? "-Er" adı, bir kod tasarımcısının bazı işlemler gerçekleştirdiğini ve bunu sınıfa dönüştürdüğünü belirtir. Sonuç olarak, herhangi bir somut kavramı yansıtmayan, ancak bazı eylemleri yansıtan yapay bir varlığımız var. Bu çok prosedürel geliyor.

Bunun yanı sıra, genellikle bu tür sınıflar bazı verileri alır ve üzerinde çalışırlar. Bu pasif veri ve aktif prosedürlerin bir felsefesidir ve prosedürel programlamada yerini buldu. Bunu fark ederseniz, Yönetici sınıflarında kötü bir şey yoktur, ancak o zaman OOP değildir.

Nesne-düşünme, nesnelerin kendilerine yaptıkları anlamına gelir. Etki alanınızı keşfedin , anlamsal ağlar oluşturun , nesneleriniz canlı olsun, akıllı ve sorumlu insanlar olsun.

Bu tür nesnelerin kontrol edilmesine gerek yoktur. Ne yapacaklarını ve nasıl yapacaklarını biliyorlar. Yönetici sınıfları iki kez OOP prensiplerini çiğniyor. "-Er" sınıfı olmasının yanı sıra, diğer nesneleri de kontrol eder. Ama yine de yöneticiye bağlıdır. Kontrol ediyor - o kötü bir menajer. Koordine ederse - o iyi bir menajer. Bu nedenle MVC’de “C” harfinin “Koordinatör” olarak yazılması gerekir.

Bu sorunun doğru cevabı şudur:

1. Değişir.

Yazılımı yazarken karşılaşacağınız her durum farklıdır. Belki de herkesin yönetici sınıflarının kurum içinde nasıl çalıştığını bildiği bir takımdasınız? Bu tasarımı kullanmamak tamamen çılgınca olurdu. Veya yönetici tasarımını diğer insanlara zorlamaya çalışıyorsanız, bu durumda kötü bir fikir olabilir. Ancak kesin ayrıntılara bağlı.