Program tasarımımda, çoğu zaman nesne sınıflarını birkaç sınıftan geçirmem gereken noktaya gelirim. Örneğin, bir ses dosyasını yükleyen ve sonra onu bir oynatıcıya ileten bir denetleyiciye sahipsem ve oynatıcı onu playerRunnable'a geçirir, bu da başka bir yere geçirir vs. bunun nasıl önleneceğini biliyorum. Yoksa bunu yapmak iyi mi?
EDIT: Belki oyuncu örneği en iyisi değil çünkü dosyayı daha sonra yükleyebilirim, fakat diğer durumlarda çalışmadı.
Yanıtlar:
Diğerlerinin de belirttiği gibi, bu mutlaka kötü bir uygulama değildir, ancak katmanların kaygılarını ayırmadığına ve katmanlara katmana özgü örnekleri aktarmadığınıza dikkat etmelisiniz. Örneğin:
Ancak, gönderdiğiniz örnekler DTO'lar veya varlıkların kendisi ise, muhtemelen tamamdır.
Henüz kimsenin değiştirilemez nesneler hakkında konuşmadığı ilginç . Değişmez bir nesneyi tüm çeşitli katmanlardan geçirmenin, her katman için çok sayıda kısa ömürlü nesne yaratmaktan çok , aslında iyi bir şey olduğunu savunuyorum .
Eric Lippert'in blogunda değişmezliğe dair bazı tartışmalar var
Öte yandan, değişken nesnelerin katmanlar arasında geçirilmesinin kötü bir tasarım olduğunu iddia ediyorum . Esasen, çevresindeki katmanların kodunuzu kıracak şekilde değiştirmeyeceği sözüyle bir katman oluşturuyorsunuz.
Nesne örneklerinin etrafından geçirilmesi, yapılması normal bir şeydir. Durumu koruma ihtiyacını azaltır (örn. Örnek değişkenler) ve kodu yürütme bağlamından ayırır.
Karşılaşabileceğiniz sorunlardan biri, bu zincirin altındaki bir yöntemin değişen parametre gereksinimlerine karşılık olarak, çağırma zinciri boyunca birden fazla yöntemin imzalarını değiştirmeniz gerektiğinde yeniden yapılanmadır. Ancak, yeniden yapılanmaya yardımcı olan modern yazılım geliştirme araçlarının kullanımıyla hafifletilebilir.
Belki küçük olabilir, ancak bu referansı, potansiyel olarak sarkan bir referans veya bellek sızıntısına neden olabilecek katmanlardan birinde bir yere atama riski vardır.
Nesneleri basitçe kodunuzun uzak bir bölgesinde olması gerektiği için dolaştırıyorsanız , isteğe bağlı olarak uygun bir IoC kabı ile birlikte kontrol ve bağımlılık enjeksiyon tasarım desenlerinin ters çevrilmesi, nesnenin etrafındaki nesnelerin taşınmasına ilişkin sorunları güzel bir şekilde çözebilir. Orta ölçekli bir projede kullandım ve bir daha kullanmadan büyük miktarda sunucu kodu yazmayı bir daha asla düşünmemeliydim.
Hızlı Yanıt: Orada yanlış bir şey nesnelerin örneklerini geçerken. Ayrıca belirtildiği gibi, bu referans potansiyel olarak sarkan bir referans veya bellek sızıntısına neden olan tüm katmanlara atlamayı atlamaktır.
Projelerimizde bu uygulamayı DTO'ları (Veri aktarım nesnesi) katmanlar arasında geçirmek için kullanıyoruz ve bu çok faydalı bir uygulama. Ayrıca, dto nesnelerimizi, özet bilgiler gibi, bir kez daha karmaşık hale getirmek için yeniden kullanıyoruz.
Öncelikle bir web UI dev'iyim ama sezgisel rahatsızlığınız, örnek geçişinden daha az ve bu kontrol cihazıyla biraz yordam uyguladığınız gerçeğinden daha fazla olabilir gibi geliyor. Kontrol cihazınız bütün bu detayları terletmeli mi? Sesin çalınması için neden birden fazla nesnenin adına atıfta bulunuyor?
OOP tasarımında, neyin yeşil olduğunu ve neyin değişime maruz kalma ihtimalini daha fazla düşündüğünü düşünüyorum. Eşyaları değiştirmeye konu olan şey, daha büyük nesne kutularınıza koymak isteyeceğiniz şeydir, böylece oyuncular değiştiğinde veya yeni seçenekler eklenirken bile tutarlı arayüzleri koruyabilirsiniz. Veya kendinizi ses nesnelerini veya bileşenlerini toptan olarak değiştirmek istediğinizde bulabilirsiniz.
Bu durumda, denetleyicinizin bir ses dosyası oynatmanın bir gerekliliği olduğunu ve ardından oynatmanın elde edilmesinin tutarlı / her zaman yeşil bir yolunun olduğunu tespit etmesi gerekir. Diğer taraftan, müzik çalar eşyaları teknoloji ve platformlar değiştikçe veya yeni seçenekler eklendikçe kolayca değişebilir. Bu ayrıntıların tümü, daha büyük bir bileşik nesne olan IMO'nun bir arayüzünün altına oturmalıdır ve sesin nasıl çalındığının ayrıntıları değiştiğinde denetleyicinizi yeniden yazmak zorunda kalmamalısınız. Daha sonra, dosya konumu gibi ayrıntılara sahip olan bir nesneyi daha büyük nesneye aktardığınızda, etrafta takas yapan her şey, birinin kendisiyle aptalca bir şey yapma ihtimalinin daha az olduğu uygun bir bağlamın iç kısmında yapılır.
Dolayısıyla bu durumda, bunun etrafından fırlatılmasının, nesnenin sizi rahatsız edebileceğini düşünmüyorum. Bu, Kaptan Picard'ın çözgü çekirdeğini açmak için motor odasına koşuyor, koordinatları çizmek için köprüye geri koşuyor ve ardından kalkanları açtıktan sonra "punch-it" düğmesine basıyor, sadece "Al" Warp 9'da X gezegenine geldik. Öyle yapın. " ve mürettebatının detayları çözmesine izin vermek. Çünkü bu şekilde ele aldığında, her geminin düzenini ve her şeyin nasıl çalıştığını bilmeden filodaki herhangi bir gemiyi kaptan edebilir. Ve sonuçta bu, çekildiği en büyük OOP tasarımı olan IMO'dur.
Diliniz varsa ya da iş parçacığı yerel depolama varsa, bu sorun dinamik olarak kapsamlı değişkenlerle çözülebilir. Bu mekanizmalar bazı özel değişkenleri bir aktivasyon zinciri veya kontrol ipliği ile ilişkilendirmemize izin verir, böylece bu değerleri sadece başka bir koda iletilebilmeleri için onlarla ilgisi olmayan koda geçirmemize gerek kalmaz Bu onlara ihtiyacı var.
Diğer cevapların da belirttiği gibi, bu doğal olarak zayıf bir tasarım değildir. Yuvalanmış sınıflar ve onları yuvalayanlar arasında sıkı bağlantı oluşturabilir, ancak başvuruları yuvalamak tasarıma bir değer sağlarsa bağlantıyı gevşetmek geçerli bir seçenek olmayabilir.
Olası bir çözüm, denetleyici sınıfındaki iç içe referansları "düzleştirmek" dir.
Parametreyi iç içe geçmiş nesnelerden birkaç kez geçirmek yerine, denetleyici sınıfında iç içe geçmiş nesnelerin tümüne başvuruda bulunabilirsiniz.
Bunun tam olarak nasıl uygulandığı (veya geçerli bir çözüm olsa bile) sistemin şu anki tasarımına bağlıdır:
Bu bir GXT istemcisi için MVC tasarım modelinde karşılaştığım bir konudur. GUI bileşenlerimiz, birkaç katman için yuvalanmış GUI bileşenleri içeriyordu. Model verileri güncellendiğinde, uygun bileşen (ler) e ulaşana kadar birkaç katmandan geçirmeyi bıraktık. GUI bileşenleri arasında istenmeyen bir bağlanma yarattı, çünkü yeni bir GUI bileşen sınıfının model verilerini kabul etmesini istiyorsak, model verilerini, yeni sınıfı içeren tüm GUI bileşenlerinde güncellemek için yöntemler oluşturmak zorunda kaldık.
Bunu düzeltmek için, View sınıfında iç içe geçmiş tüm GUI bileşenlerine bir referanslar haritası oluşturduk, böylece model verileri her güncellendiğinde, View güncellenmiş model verilerini doğrudan ihtiyaç duyduğu GUI bileşenlerine gönderebilir, öykünün sonuna . Bu iyi çalıştı çünkü her bir GUI bileşeninin yalnızca tek örnekleri vardı. Bazı GUI bileşenlerinin birden fazla örneği varsa, hangi kopyanın güncellenmesi gerektiğini tanımlamayı zorlaştırıyorsa, o kadar iyi çalışmadığını görebiliyordum.
Tarif ettiğiniz şey, bir Sorumluluk Zinciri tasarım deseni olarak adlandırılır. Apple bu kalıbı olay işleme sistemi için değerinde kullanır.