SOLID ilkelerini kullanırken geliştiriciler için keşfedilebilirlik bir sorun oluşturuyor mu?

Diğer tüm geliştiricilerin temel CRUD uygulamaları yapmaya alışkın oldukları veya yalnızca güzel / fonksiyonel arayüzler yapmaya odaklandıkları iş uygulamaları serisi yapıyorum ve aşağıdakileri çok alıyorum.

"Bunu yapmak için kullandığımız yolla Çalışan, bir çalışanla yapabileceğiniz her şeye sahip olacaktır." Ve bu doğruydu. Bir "Sınıf" binlerce satır kod vardı ve bir çalışan ile yapabileceğiniz her şey vardı. Daha da kötüsü, bir çalışan verileri tablosu vardı ve her geliştirici olay işleyicisinde yapmak istediklerini nasıl yapacağını anladı.

Bu yaklaşımla ilgili tüm kötü şeyler doğruydu, ancak en azından çalışanı kullanan geliştirici, diğer belgelere gitmeden, çalışanı bir sağlık planına nasıl kaydedeceğini, ücret artışı, yangın, işe alma, transfer vb. Yönetici ve diğer tüm büyük fikirler için. Veya, çalışanı diğer gerekli veri tablolarını kullanıyorlarsa, istediklerini yapabilirlerdi.

Evet, çoğaltılmış kod vardı. Evet çok kırılgan bir kod. Evet, test etmek gerekenden çok daha zordu. Evet işlevselliği değiştirmek korku uyandırıcıydı ve Kopyala Yapıştır yaklaşımı nedeniyle doğaldı.

Ama en azından bir sınıf oluşturarak neyin mevcut olduğunu keşfedebildiler ya da arayüzler, soyut sınıflar, somut sınıflar vb. Arasındaki farkı anlamak zorunda kalmadan yapmaları gerekeni yapabilirlerdi. intellisense tarafından döndürülen yöntemler veya verilerin bulunduğu tabloları bilir.

Ben googled / binged ve hatta yahoo! D var ama bu sorunun herhangi bir kabul bulamadık.

Belki bir sorun yok ve ben sadece bir şey eksik. Gerçek davranış / tasarım çalışmayan geliştiricilerin herhangi bir harici belgeye başvurmak zorunda kalmadan veya çeşitli bileşenlerde sınıf adlarını taramak zorunda kalmadan kolayca bir şeyler yapmayı keşfedebilecekleri bir çözüm bulmaya çalışan bir çözüm bulmaya çalıştım. projenin kulağa hoş geleceğini bulmak için çalışır.

Ortaya koyabildiğim tek şey, daha iyi bir isim eksikliğinden dolayı, gerçek sınıfları döndüren başka bir şey yapmayan "İçerik Sınıfı Tablosu" (ve bunların çoğu arayüzler ama diğer geliştiricilerin istenen gerçek görevleri yerine getirmek için kullanabileceği farkı veya hatta bakımı). Hala gerçekten büyük sınıflarla sonuçlanıyor ama içlerinde neredeyse hiç davranış yok.

SOLID'in gerçek uygulamasının gerçekleştiği orta katman hakkında samimi bilgi gerektirmeyen daha iyi bir yol var mı?

Temelde istediğim, CRUD tipi geliştiricilerin çok karmaşık bir sistemde CRUD geliştiricileri olmaya devam etmelerine izin vermenin bir yolu var

Görünüşe göre (yani bir çalışanla yapabileceğiniz TÜM olası kodlara sahip çalışan sınıfı) kişisel olarak oldukça sık gördüğüm son derece yaygın bir kalıptır. Daha iyi bilmeden önce kendim yazdığım bu kodlardan bazıları.

Yönetilebilir yöntemlerle tek bir varlığı temsil etmesi gereken bir sınıf olarak başlayan şey, sürdürülecek bir kabus gibi bir şeye dönüşür, çünkü her özellik ve her sürüm aynı sınıfa giderek daha fazla eklemeye devam eder. Bu, bir kez bir sınıf yazmanız ve onu tekrar tekrar değiştirme isteğine karşı koymanız gerektiğini söyleyen SOLID ilkelerine aykırıdır.

Bir süre önce (başkaları tarafından tanıtılan tasarım desenlerini veya SOLID'i keşfetmeden önce), bir sonraki projemde işleri biraz tersine çevirmeye karar verdim. İki çok büyük platform arasında arayüz görevi gören bir sunucu üzerinde çalışıyordum. İlk başta, yalnızca yapılandırma senkronizasyonu gerekiyordu, ancak bunun birçok özellik için mantıklı bir yer olacağını görebiliyordum.

Bu yüzden yöntemleri açıklayan bir sınıf yazmak yerine, yöntemleri temsil eden sınıflar yazdım (GoF'den "Command" kalıbı olduğu ortaya çıktı). Müşteri için iş yapmak yerine, tüm ana uygulama derslerim kalıcı devlet sahiplerine dönüştü ve çok daha kısa sürdü. Hizmetin kendisine yeni bir arabirim yöntemi eklemek zorunda kaldığımda, her şeyi başlatan Execute () yöntemine sahip yeni bir sınıf yaratırdım. Birden fazla komutun ortak bir yanı varsa, ortak temel sınıftan türetilmişlerdir. Sonunda olay 70+ farklı komut sınıfına sahipti ve tüm proje hala çok yönetilebilirdi ve üzerinde çalışmak gerçekten bir zevkti.

"TOK sınıfınız" benim yaptığımdan çok uzakta değil. Komutları başlatmaktan sorumlu soyut bir fabrikam (GoF) vardı. Fabrika sınıfının içinde, temel sınıfın ve ATL tarzı makroların arkasındaki ayrıntıların çoğunu sakladım, bu yüzden bir programcı bir istek eklemek veya aramak zorunda kaldığında, oraya gittiler ve gördükleri tek şey şuydu:

BEGIN_COMMAND_MAP()
    COMMAND_ENTRY( CChangeDeviceState )
    COMMAND_ENTRY( CSetConfiguration )
    ....
END_COMMAND_MAP()

Alternatif olarak (veya buna ek olarak), tüm gerçek komut sınıflarınızı ayrı bir ad alanına koyabilirsiniz, böylece insanlar kodlarken ve bir şey çalıştırması gerektiğinde, yalnızca ad alanı adı yazar ve Intellisense tanımladığınız tüm komutları listeler. Daha sonra her komut, tam olarak hangi girdi ve çıktı parametrelerini belirleyen tüm get / set yöntemlerini içerir.

Cephe (GoF) deseninin kullanımını da keşfedebilirsiniz. CRUD mühendislerinize 1000'den fazla sınıfı göstermek yerine. Hepsini sadece gerekenleri ortaya koyan tek bir sınıfın arkasına saklayın. Her bir "eylemin" kendi sınıfı olmasını sağlamaya devam ederdim, ancak Cephe sınıfınız her eyleminizi somutlaştıracak yöntemlere sahip olabilir ve yine Intellisense ile mevcut olanları hemen görürlerdi. Veya Facade'in gerçek yöntemlere sahip olmasını sağlayın, ancak dahili olarak komutları somut hale getirin, sıraya alın ve yanıtları bekleyin. Ardından, normal bir yöntem çağrısı yapılmış gibi geri dönün.

(*) Çok fazla ayrıntıya girmek istemedim, ama aslında "Command" ve "CommandHandler" sınıflarım vardı. Bu, yönetme / sıraya alma / sıraya koyma parametrelerini aslında bu komutları "işleyen" sınıflardan ayırmıştır.

Bir sorun olabilir. Özellikle işleri kötü adlandırırsanız. Ancak karmaşık sınıflara başvurmadan bir dizi çözüm var. Heck, çok fazla yöntemi olan bir sınıfın Intellisense ile gezinmesi aynı derecede zor olabilir.

Sorunu basitleştirmek için ad alanlarını (C #) veya paketleri (Java) ya da dilinizin sahip olduğu benzer bir kavramı (hepsine ad alanı olarak bakacağım) kullanmayı deneyin.

Şirket adınızla başlayın. Bu Intellisense'i yalnızca kendi yazdığınız ad alanlarıyla sınırlar. Daha sonra, birden fazla uygulamanız varsa, bunları bölmek için ad alanının ikinci bölümünü kullanın. Uygulamalar arasında var olan şeyler için bir Core ad alanı ekleyin. Daha sonra işleri işlevsellik türlerine ayırın. Ve bunun gibi.

Bunu doğru yaparsanız, çok keşfedilebilir öğeler elde edersiniz.

Örneğinizi almak için Kullanıcı doğrulamasını istiyorsam "MyCo" yazıyorum. ve bana uygulama ad alanlarının bir listesini veriyor. Kullanıcı veritabanının tüm uygulamalarımızda kullanıldığını biliyorum, bu yüzden "Core" yazıyorum. sonra işlevsellik türlerinin bir listesini alıyorum. Bunlardan biri "Doğrulama" olduğu için bu bariz bir seçim gibi görünüyor. Ve orada, Doğrulama içinde, tüm işlevselliği ile "UserValidator" vardır.

Olduğu gibi, çok kullandığım şeyler için isimleri veya en azından konvansiyonları hızlı bir şekilde hatırlayacağım. Doğrulama kurallarında birçok değişiklik yaptığım için, tüm doğrulama sınıflarımın FooValidator olarak adlandırıldığını bileceğim, burada Foo tablonun adıdır. Bu yüzden aslında isim alanlarını geçmem gerekmeyecek. Sadece UserValidator yazacağım ve IDE'nin geri kalanını yapmasına izin vereceğim.

Ama hatırlayamadığım şeyler için onları bulmak hala çok kolay. Bunu yaptığımda, ad alanı önekini kaldırabilirim.

Onları temelde "CRUD" geliştiricileri olarak adlandırdığınız için, bunların çok iyi olduğunu düşünmediğinizi varsayacağız. Bunun, işletme alanınızı da anlamadıkları anlamına gelip gelmediğini bilmiyoruz. Eğer alanı anlıyorlarsa, sınıflar onlara bir anlam ifade etmelidir. Birkaç sınıfın inşa edildiğini bilerek, önce bakmalı, ikinci olarak sormalı, sıfırdan inşa etmeyi üçüncü bir seçenek olarak düşünmelidirler.

Bir sınıfın sadece ona bakarak nasıl kullanılacağını / yeniden kullanılacağını otomatik olarak nasıl bileceğini bilmek ilk kez beklenmemelidir. Eğitim yoluyla veya muhtemelen kod incelemesi sırasında belgelemeniz ve muhtemelen ek açıklama yapmanız gerekecektir.

Birçok API ve açık kaynak projesi dokümantasyon, kod örnekleri ve diğer açıklamalar sağlar. Kullanıcılarınızın kullanıcı dostu olması gerekmeyebilir, ancak bununla uğraşmak gerekmez. Onlara iyi öğretin.