Sınıfları “Bilgi” sonekiyle adlandırmanın ardındaki fikir nedir, örneğin: “SomeClass” ve “SomeClassInfo”?

Fiziksel cihazlarla ilgilenen bir projede çalışıyorum ve bu projedeki bazı sınıfların nasıl düzgün bir şekilde adlandırılacağı konusunda kafam karıştı.

Gerçek cihazlar (sensörler ve alıcılar) bir şey ve onların yazılımda temsil başka bir şey göz önüne alındığında , ben bazı sınıfları "Bilgi" soneki ad desen ile adlandırmayı düşünüyorum.

Örneğin, a Sensor, gerçek sensörü temsil eden bir sınıf olsa da (gerçekte bazı çalışma cihazlarına bağlandığında), SensorInfosadece bu sensörün özelliklerini temsil etmek için kullanılır. Örneğin, dosya kaydetme üzerine, mantıklı bile olmayan bir tür SensorInfoserileştirmek yerine, dosya başlığına serileştiririm Sensor.

Ama şimdi kafam karıştı, çünkü nesnelerin yaşam döngüsünde bir ya da diğeri kullanmam gerekip gerekmediğini ya da diğerinden nasıl alacağımı ya da her iki varyantın aslında sadece bir sınıfa daraltılmasının gerekip gerekmediğine karar veremediğim bir orta alan var.

Ayrıca, çok yaygın olan örnek Employeesınıf açık bir şekilde sadece gerçek kişinin bir temsilidir, ancak hiç kimse EmployeeInfobildiğim kadarıyla sınıfı adlandırmayı önermez.

Birlikte çalıştığım dil .NET'tir ve bu adlandırma modeli, bu sınıflarla örneklemek için çerçeve boyunca yaygın görünmektedir:

• Directoryve DirectoryInfosınıflar;
• Fileve FileInfosınıflar;
• ConnectionInfosınıf (muhabir Connectionsınıf olmadan );
• DeviceInfosınıf (muhabir Devicesınıf olmadan );

Benim sorum şu: Bu adlandırma modelini kullanmanın ortak bir mantığı var mı? Bir çift isme ( Thingve ThingInfo) sahip olmanın mantıklı olduğu durumlar ve muadili olmadan sadece ThingInfosınıfın veya sınıfın olması gereken diğer durumlar var Thingmı?

"Bilgi" nin yanlış isim olduğunu düşünüyorum. Nesnelerin durumu ve eylemleri vardır: "bilgi", halihazırda OOP'a dönüştürülmüş "durum" için başka bir addır.

Burada gerçekten neyi modellemeye çalışıyorsunuz? Diğer kodun kullanabilmesi için yazılımdaki donanımı temsil eden bir nesneye ihtiyacınız vardır.

Söylemesi kolay ama öğrendiğiniz gibi bundan daha fazlası var. "Donanımı temsil etmek" şaşırtıcı derecede geniştir. Bunu yapan bir nesnenin birkaç endişesi vardır:

• USB arabirimi, seri bağlantı noktası, TCP / IP veya tescilli bağlantıyla konuşurken düşük seviye cihaz iletişimi.
• Devlet yönetimi. Cihaz açık mı? Yazılımla konuşmaya hazır mısınız? Meşgul?
• Olayları işleme. Cihaz veri üretti: şimdi ilgilenen diğer sınıflara geçmek için etkinlikler oluşturmamız gerekiyor.

Sensörler gibi bazı aygıtların yazıcı / tarayıcı / faks çok işlevli aygıtından daha az endişe olacaktır. Bir sensör muhtemelen sadece biraz akış üretirken, karmaşık bir cihaz karmaşık protokollere ve etkileşimlere sahip olabilir.

Her neyse, özel sorunuza geri dönersek, özel gereksinimlerinize ve donanım etkileşiminin karmaşıklığına bağlı olarak bunu yapmanın birkaç yolu vardır.

Bir sıcaklık sensörü için sınıf hiyerarşisini nasıl tasarlayacağımın bir örneği:

• ITemperatureSource: sıcaklık verisi üretebilecek her şeyi temsil eden arayüz: bir sensör, bir dosya sarıcı veya sabit kodlu veri bile olabilir (düşün: sahte test).

• Acme4680Sensör: ACME model 4680 sensörü (Roadrunner yakında olduğunda tespit etmek için mükemmeldir). Bu, birden fazla arabirim uygulayabilir: belki de bu sensör hem sıcaklığı hem de nemi algılar. Bu nesne, "sensör bağlı mı?" Gibi program düzeyinde bir durum içeriyor. ve "son okuma neydi?"

• Acme4680SensorComm: yalnızca fiziksel cihazla iletişim kurmak için kullanılır . Çok fazla devleti korumaz. Mesaj göndermek ve almak için kullanılır. Donanımın anladığı her mesaj için bir C # yöntemi vardır.

• HardwareManager: cihazları almak için kullanılır. Bu aslında örnekleri önbelleğe alan bir fabrika: her donanım cihazı için bir cihaz nesnesinin yalnızca bir örneği olmalıdır. A ipliği ACME sıcaklık sensörünü talep ederse ve B ipliği ACME nem sensörünü isterse bunların aslında aynı nesne olduğunu ve her iki dişe de geri döndürülmesi gerektiğini bilecek kadar akıllı olmalıdır.

En üst düzeyde, her bir donanım türü için arayüzlere sahip olacaksınız. C # kodunuzun C # veri türlerini (örn. Ham aygıt sürücüsünün kullanabileceği bayt dizileri değil) kullanarak aygıtlarda gerçekleştireceği işlemleri açıklarlar.

Aynı düzeyde, her donanım türü için bir örnek içeren bir numaralandırma sınıfınız vardır. Sıcaklık sensörü bir tip, nem sensörü başka bir tip olabilir.

Bunun altında bir seviye, bu arayüzleri uygulayan gerçek sınıflardır: yukarıda tarif edilen Acme4680Sensör I'e benzer bir cihazı temsil ederler. Aygıt birden çok işlevi yerine getirebiliyorsa, belirli bir sınıf birden çok arabirim uygulayabilir.

Her aygıt sınıfının, donanımla konuşmanın düşük düzeyli görevini gerçekleştiren kendi özel Comm (iletişim) sınıfı vardır.

Donanım modülünün dışında görünen tek katman arabirimler / enum artı HardwareManager'dır. HardwareManager sınıfı, aygıt sınıflarının örneğini, önbellek örneklerini ( gerçekten aynı donanım aygıtıyla konuşurken iki aygıt sınıfının olmasını istemezsiniz) vb . İşleyen fabrika soyutlamasıdır . Belirli bir sensör türüne ihtiyaç duyan bir sınıf, HardwareManager'dan belirli numaralandırma için cihaz, daha sonra zaten somutlaştırılmış olup olmadığını, nasıl yaratılacağı ve başlatılacağı vb.

Burada amaç etmektir Decouple düşük seviyeli donanım mantıktan iş mantığı. Sensör verilerini ekrana yazdıran bir kod yazarken, bu kod, ne tür bir sensörünüz olduğunu ve yalnızca bu donanım arayüzleri üzerinde merkezlenen bu ayırma işleminin mevcut olup olmadığını önemsememelidir .

Not: şema ok çorbasına dönüşeceği için HardwareManager ile çizmediğim her aygıt sınıfı arasında ilişkilendirmeler vardır.

Burada tek bir birleştirici kural bulmak biraz zor olabilir, çünkü bu sınıflar bir dizi isim alanına yayılmıştır ( ConnectionInfoiçeride CrystalDecisionsve DeviceInfoiçeride System.Reporting.WebForms).

Ancak bu örneklere baktığımızda, son ekin iki farklı kullanımı var gibi görünüyor:

• Örnek yöntemler sağlayan bir sınıfla statik yöntemler sağlayan bir sınıfı ayırt etme. System.IOTanımları ile altı çizildiği gibi , sınıflar için durum böyledir :

  Dizin :

  Dizinler ve alt dizinler aracılığıyla oluşturma, taşıma ve numaralandırma için statik yöntemleri ortaya koyar. Bu sınıf devralınamaz.

  DirectoryInfo :

  Dizinler ve alt dizinler aracılığıyla oluşturma, taşıma ve numaralandırma için örnek yöntemleri ortaya koyar. Bu sınıf devralınamaz.

  Infoburada biraz garip bir seçim gibi görünüyor, ancak farkı nispeten netleştiriyor: bir Directorysınıf makul bir şekilde belirli bir dizini temsil edebilir veya herhangi bir durumu tutmadan genel dizinle ilgili yardımcı yöntemler DirectoryInfosağlayabilirken, sadece gerçekten eski olabilir.

• Sınıfın yalnızca bilgi tuttuğunu ve son ekli addan makul şekilde beklenebilecek davranış sağlamadığını vurgulamak .

  O cümlenin son kısmı, farklılaşacaktır, demek ki bulmacanın parçası olabileceğini düşünmek ConnectionInfodan EmployeeInfo. Eğer denilen bir sınıfım Connectionolsaydı, bana gerçekten bir bağlantının sahip olduğu işlevselliği sağlamasını beklerdim - void Open()vb. Yöntemler arardım . Ancak, sağ akıllarında hiç kimse bir Employeesınıfın aslında gerçek ne Employeeyapar, ya da benzeri yöntemler aramaya void DoPaperwork()veya bool TryDiscreetlyBrowseFacebook().

Genel olarak, bir Infonesne zaman içinde bir nesnenin durumu hakkında bilgi içerir . Sistemden bir dosyaya bakmasını FileInfove boyutuyla ilişkili bir nesneyi vermesini istersem, bu nesnenin, istek verildiğinde (veya daha kesin olarak, boyutunda) dosyanın boyutunu bildirmesini beklerim. aramanın yapıldığı zaman ve geri döndüğü zaman arasındaki dosya). Dosyanın boyutu zamanında isteği döner ve zaman arasındaki değişirse FileInfonesne incelendiğinde, ben ederim değil böyle bir değişiklik yansıtılması bekliyoruz FileInfonesne.

Bu davranışın bir Filenesnenin davranışından çok farklı olacağını unutmayın . Bir disk dosyasını özel olmayan modda açma isteği Filebir Sizeözelliğe sahip bir nesne verirse , disk dosyasının boyutu değiştiğinde döndürülen değerin değişmesini beklerim, çünkü Filenesne yalnızca durumunu göstermez bir dosya - dosyanın kendisini temsil eder .

Çoğu durumda, bir kaynağa iliştirilen nesnelerin hizmetleri artık gerekli olmadığında temizlenmesi gerekir. Çünkü *Infonesneler kaynaklara takmak yok, temizleme gerektirmez. Sonuç olarak, bir Infonesnenin bir istemcinin gereksinimlerini karşılayacağı durumlarda , temel kaynağı temsil eden, ancak bu kaynakla olan bağlantısının temizlenmesi gereken bir nesneyi kullanmaktan ziyade kod kullanmak daha iyi olabilir.

Gerçek cihazlar (sensörler ve alıcılar) bir şey ve onların yazılımda temsil başka bir şey göz önüne alındığında , ben bazı sınıfları "Bilgi" soneki ad desen ile adlandırmayı düşünüyorum.

Örneğin, a Sensor, gerçek sensörü temsil eden bir sınıf olsa da (gerçekte bazı çalışma cihazlarına bağlandığında), SensorInfosadece bu sensörün özelliklerini temsil etmek için kullanılır. Örneğin, dosya kaydetme üzerine, mantıklı bile olmayan bir tür SensorInfoserileştirmek yerine, dosya başlığına serileştiririm Sensor.

Bu ayrımı sevmiyorum. Tüm nesneler "yazılımda temsil [ler] dir. "Nesne" kelimesinin anlamı budur.

Şimdi, bir çevre birimi hakkındaki bilgileri, çevre birimiyle arayüz oluşturan gerçek koddan ayırmak mantıklı olabilir. Bu nedenle, örneğin, Sensör, donanım değişkenine ihtiyaç duymayan bazı yöntemlerle birlikte örnek değişkenlerinin çoğunu içeren bir SensorInfo öğesine sahipken, Sensor sınıfı fiziksel sensörle etkileşime girmekten sorumludur. Sen-a yok SensorBilgisayarınız bir sensör sahip olmadıkça, ancak makul bir şekilde var-bir olabilir SensorInfo.

Sorun şu ki, bu tür bir tasarım (neredeyse) herhangi bir sınıfa genelleştirilebilir. Bu yüzden dikkatli olmalısın. SensorInfoInfoMesela bir dersiniz olmazdı . Eğer bir Sensordeğişkeniniz varsa , üyesiyle etkileşime girerek kendinizi Demeter yasasını ihlal ederken bulabilirsiniz SensorInfo. Elbette bunların hiçbiri ölümcül değildir, ancak API tasarımı sadece kütüphane yazarları için değildir. Kendi API'nizi temiz ve basit tutarsanız, kodunuz daha sürdürülebilir olur.

Dizinler gibi dosya sistemi kaynakları bence bu kenara çok yakın. Yerel olarak erişilemeyen, doğru olmayan bir dizini tanımlamak istediğiniz bazı durumlar vardır, ancak ortalama geliştirici muhtemelen bu durumlardan birinde değildir. Sınıf yapısını bu şekilde karmaşıklaştırmak bana göre yararsızdır. Kontrast Python'un yaklaşımı pathlib: "Büyük olasılıkla ihtiyacınız olan şey" olan tek bir sınıf ve çoğu geliştiricinin güvenle göz ardı edebileceği çeşitli yardımcı sınıflar vardır. Bununla birlikte, gerçekten onlara ihtiyacınız varsa, sadece aynı yöntemleri sağlarlar, sadece somut yöntemlerle çıkarılırlar.

Bağlam / etki alanının önemli olduğunu söyleyebilirim, çünkü üst düzey iş mantığı kodu ve düşük düzey modelleri, mimari bileşenleri vb ...

'Bilgi', 'Veri', 'Yönetici', 'Nesne', 'Sınıf', 'Model', 'Denetleyici' vb. bu bilgi gerekli değildir.

Ticari alanın sınıf adları, kulağa garip gelse veya% 100 doğru dil olmasa da, tüm paydaşların bu konuda konuştuğu gibi olmalıdır.

Veri yapıları için iyi son ekler örneğin 'Liste', 'Harita' ve gerekli olduğunu düşünüyorsanız 'Dekoratör', 'Bağdaştırıcı' desenleri içindir.

Sensör senaryosuna göre, sensörünüzün SensorInfone olduğunu kaydetmeyi beklemiyordum , ama SensorSpec. Infoimho daha çok türetilmiş bir bilgidir, örneğin FileInfoboyut, kaydetmediğiniz veya yol ve dosya adından oluşturulan dosya yolu gibi bir şeydir.

Başka bir nokta:

Bilgisayar Bilimlerinde sadece iki zor şey vardır: önbellek geçersiz kılma ve şeyleri adlandırma.

- Phil Karlton

Bu bana her zaman sadece birkaç saniyeliğine bir isim düşünmeyi hatırlatıyor ve eğer bir şey bulamazsam, garip isimler kullanıyorum ve 'TODO' ile işaretliyorum. IDE'im yeniden düzenleme desteği sağladığı için bunu daha sonra değiştirebilirim. İyi olması gereken bir şirket sloganı değil, ancak her istediğimizde değiştirebileceğimiz bazı kodlar. Bunu aklınızda bulundurun.

ThingInfo, Şey için harika bir salt okunur Proxy olarak kullanılabilir.

bkz. http://www.dofactory.com/net/proxy-design-pattern

Proxy: "Başka bir nesnenin ona erişimi kontrol etmesi için bir vekil veya yer tutucu sağlayın."

Genellikle ThingInfo, ayarlayıcı içermeyen genel özelliklere sahip olacaktır. Bu sınıfların ve sınıftaki yöntemlerin kullanımı güvenlidir ve yedekleme verilerinde, nesnede veya diğer nesnelerde herhangi bir değişiklik yapmayacaktır. Hiçbir durum değişikliği veya başka yan etki meydana gelmez. Bunlar, raporlama ve web hizmetleri için veya nesne hakkında bilgiye ihtiyaç duyduğunuz ancak asıl nesnenin kendisine erişimi sınırlamak istediğiniz herhangi bir yerde kullanılabilir.

Mümkün olduğunda ThingInfo'yu kullanın ve gerçek Thing'in kullanımını gerçekten Thing nesnesini değiştirmeniz gereken zamanlarla sınırlayın. Bu kalıbı kullanmaya alıştığınızda okuma ve hata ayıklamayı çok daha hızlı hale getirir.

Şimdiye kadar bu sorudaki hiç kimse bu isimlendirme sözleşmesinin gerçek nedenini almamış görünüyor.

Bir DirectoryInfodeğil dizin. Öyle bir veri ile DTO hakkında dizine. Aynı dizini tanımlayan pek çok örnek olabilir. Bu bir varlık değildir. Bu bir atış değeri nesnesidir. A , gerçek dizini temsil etmez. Bunu bir dizin için tanıtıcı veya denetleyici olarak da düşünebilirsiniz.DirectoryInfo

Bunu adlandırılmış bir sınıfla karşılaştırın Employee. Bu bir ORM varlık nesnesi olabilir ve bu çalışanı tanımlayan tek nesnedir. Eğer kimliği olmayan bir değer-nesne ise çağrılmalıdır EmployeeInfo. Bir Employeegerçekten gerçek çalışanı temsil ediyor. Çağrılan bir değer benzeri DTO sınıfı EmployeeInfo, çalışanı açıkça temsil etmez, daha ziyade onu tanımlar veya bu konuda veri depolar.

Aslında BCL'de her iki sınıfın da bulunduğu bir örnek vardır: A ServiceController, bir Windows Hizmetini tanımlayan bir sınıftır. Her hizmet için bu türden herhangi bir sayıda denetleyici olabilir. Bir ServiceBase(ya da türetilmiş bir sınıfı) olan fiili hizmet ve kavramsal olarak farklı hizmet başına bunun birden çok örneği için mantıklı değildir.