Apa ide di balik kelas penamaan dengan akhiran "Info", misalnya: "SomeClass" dan "SomeClassInfo"?

20

Saya bekerja di sebuah proyek yang berhubungan dengan perangkat fisik, dan saya bingung bagaimana cara menyebutkan beberapa kelas dengan benar dalam proyek ini.

Mengingat perangkat yang sebenarnya (sensor dan penerima) adalah satu hal, dan representasi mereka dalam perangkat lunak adalah hal lain, saya berpikir tentang penamaan beberapa kelas dengan pola nama akhiran "Info".

Sebagai contoh, sementara a Sensorakan menjadi kelas untuk mewakili sensor aktual (ketika itu sebenarnya terhubung ke beberapa perangkat yang berfungsi), SensorInfoakan digunakan untuk hanya mewakili karakteristik sensor tersebut. Sebagai contoh, setelah menyimpan file, saya akan membuat cerita bersambung SensorInfoke tajuk file, alih-alih membuat cerita bersambung Sensor, yang jenisnya bahkan tidak masuk akal.

Tapi sekarang saya bingung, karena ada jalan tengah pada siklus hidup objek di mana saya tidak bisa memutuskan apakah saya harus menggunakan satu atau yang lain, atau bagaimana cara mendapatkan satu dari yang lain, atau bahkan apakah kedua varian harus benar-benar diciutkan menjadi hanya satu kelas.

Juga, Employeekelas contoh yang terlalu umum jelas hanya merupakan representasi dari orang yang sebenarnya, tetapi tidak ada yang menyarankan untuk menyebutkan kelas EmployeeInfo, sejauh yang saya tahu.

Bahasa yang saya gunakan adalah .NET, dan pola penamaan ini tampaknya umum di seluruh kerangka kerja, untuk contoh dengan kelas-kelas ini:

Directorydan DirectoryInfokelas;
Filedan FileInfokelas;
ConnectionInfokelas (tanpa Connectionkelas koresponden );
DeviceInfokelas (tanpa Devicekelas koresponden );

Jadi pertanyaan saya adalah: apakah ada alasan umum untuk menggunakan pola penamaan ini? Apakah ada kasus di mana masuk akal untuk memiliki pasangan nama ( Thingdan ThingInfo) dan kasus lain di mana seharusnya hanya ada ThingInfokelas, atau Thingkelas, tanpa pasangannya?

— heltonbiker
sumber

5

Ben Aaronson menjawab dengan benar di bawah; yang Infoakhiran membedakan statickelas yang berisi metode utilitas dari rekan stateful nya. Itu bukan "praktik terbaik"; itu hanya cara yang dibuat oleh tim .NET untuk memecahkan masalah tertentu. Mereka bisa saja dengan mudah membuat FileUtilitydan File, tetapi File.DoSomething()dan FileInfo.FileNametampaknya membaca lebih baik.

— Robert Harvey

1

Perlu dicatat bahwa ini adalah pola umum, tetapi dengan banyak konvensi penamaan yang berbeda seperti bahasa dan API. Di Java, misalnya, jika Anda memiliki kelas stateful Foo, Anda mungkin memiliki kelas utilitas non-instantiable Foos. Ketika berbicara tentang penamaan, yang penting adalah konsistensi dalam API, dan idealnya di seluruh API pada platform.

— Kevin Krumwiede

1

Sangat? "Tidak ada yang menyarankan untuk memberi nama kelas EmployeeInfo" ?? TAK SEORANGPUN? Tampaknya agak kuat untuk sesuatu yang tidak begitu jelas.

— ThePopMachine

@ThePopMachine Saya setuju kata "tidak ada" mungkin terlalu sulit dalam kasus ini, tetapi Employeecontoh ditemukan oleh lusinan, baik online atau di buku-buku klasik, sementara saya belum melihat EmployeeInfo(mungkin karena seorang karyawan adalah makhluk hidup, tidak konstruksi teknis seperti koneksi atau file). Tetapi, setuju, jika kelas EmployeeInfoakan diusulkan dalam suatu proyek, saya percaya itu bisa digunakan.

— heltonbiker

1

chegg.com/homework-help/questions-and-answers/… mathworks.com/help/matlab/matlab_oop/… stackoverflow.com/questions/22082434/binarytree-employee-class cplusplus.com/forum/general/24222

— ThePopMachine

21

Saya pikir "info" adalah istilah yang salah. Objek memiliki status dan tindakan: "info" hanyalah nama lain untuk "status" yang sudah dimasukkan ke OOP.

Apa yang sebenarnya Anda coba model di sini? Anda memerlukan objek yang mewakili perangkat keras dalam perangkat lunak sehingga kode lain dapat menggunakannya.

Itu mudah dikatakan tetapi ketika Anda tahu, ada lebih dari itu. "Perangkat keras yang mewakili" sangat luas. Objek yang melakukan itu memiliki beberapa masalah:

Komunikasi perangkat tingkat rendah, apakah itu berbicara dengan antarmuka USB, port serial, TCP / IP, atau koneksi eksklusif.
Mengelola negara. Apakah perangkat dihidupkan? Sudah siap berbicara dengan perangkat lunak? Sibuk?
Menangani acara. Perangkat menghasilkan data: sekarang kita perlu membuat acara untuk diteruskan ke kelas lain yang tertarik.

Perangkat tertentu seperti sensor akan memiliki masalah lebih sedikit daripada mengatakan perangkat multifungsi printer / pemindai / faks. Sensor kemungkinan hanya menghasilkan aliran bit, sementara perangkat yang kompleks mungkin memiliki protokol dan interaksi yang kompleks.

Bagaimanapun, kembali ke pertanyaan spesifik Anda, ada beberapa cara untuk melakukan ini tergantung pada kebutuhan spesifik Anda dan juga kompleksitas interaksi perangkat keras.

Berikut adalah contoh bagaimana saya akan merancang hirarki kelas untuk sensor suhu:

ITemperatureSource: antarmuka yang mewakili apa pun yang dapat menghasilkan data suhu: sensor, bahkan bisa berupa pembungkus file atau data yang dikodekan dengan keras (pikirkan: pengujian tiruan).
Acme4680Sensor: ACME model 4680 sensor (bagus untuk mendeteksi ketika Roadrunner berada di dekatnya). Ini dapat menerapkan beberapa antarmuka: mungkin sensor ini mendeteksi suhu dan kelembaban. Objek ini berisi status tingkat program seperti "apakah sensor terhubung?" dan "apa bacaan terakhir?"
Acme4680SensorComm: hanya digunakan untuk berkomunikasi dengan perangkat fisik. Itu tidak mempertahankan banyak negara. Ini digunakan untuk mengirim dan menerima pesan. Ini memiliki metode C # untuk setiap pesan yang dimengerti oleh perangkat keras.
HardwareManager: digunakan untuk mendapatkan perangkat. Ini pada dasarnya adalah pabrik yang menyimpan instance: hanya ada satu instance objek perangkat untuk setiap perangkat perangkat keras. Harus cukup pintar untuk mengetahui bahwa jika ulir A meminta sensor suhu ACME dan ulir B meminta sensor kelembaban ACME, ini sebenarnya adalah objek yang sama dan harus dikembalikan ke kedua utas.

Di tingkat atas Anda akan memiliki antarmuka untuk setiap jenis perangkat keras. Mereka menggambarkan tindakan kode C # Anda akan mengambil pada perangkat, menggunakan tipe data C # (bukan misalnya byte array yang mungkin menggunakan driver perangkat mentah).

Pada tingkat yang sama Anda memiliki kelas enumerasi dengan satu instance untuk setiap jenis perangkat keras. Sensor suhu mungkin satu jenis, sensor kelembaban yang lain.

Satu level di bawah ini adalah kelas aktual yang mengimplementasikan antarmuka itu: mereka mewakili satu perangkat yang mirip dengan Acme4680Sensor yang saya jelaskan di atas. Kelas tertentu dapat menerapkan beberapa antarmuka jika perangkat dapat melakukan banyak fungsi.

Setiap kelas perangkat memiliki kelas Comm (komunikasi) pribadi yang menangani tugas tingkat rendah untuk berbicara dengan perangkat keras.

Di luar modul perangkat keras, satu-satunya lapisan yang terlihat adalah antarmuka / enum plus HardwareManager. Kelas HardwareManager adalah abstraksi pabrik yang menangani instantiation kelas perangkat, instance caching (Anda benar-benar - tidak ingin dua kelas perangkat berbicara dengan perangkat perangkat keras yang sama), dll. Kelas yang membutuhkan jenis sensor tertentu meminta HardwareManager untuk mendapatkan perangkat untuk enum tertentu, yang kemudian diketahui jika sudah dipakai, jika tidak cara membuatnya dan menginisialisasi, dll.

Tujuannya di sini adalah untuk memisahkan logika bisnis dari logika perangkat keras tingkat rendah. Saat Anda menulis kode yang mencetak data sensor ke layar, kode itu seharusnya tidak peduli jenis sensor apa yang Anda miliki jika dan hanya jika decoupling ini berada di tempat yang berpusat pada antarmuka perangkat keras tersebut.

Contoh diagram kelas UML yang menunjukkan desain yang dijelaskan dalam jawaban ini

Catatan: ada asosiasi antara HardwareManager dan setiap kelas perangkat yang tidak saya gambar karena diagram akan berubah menjadi sup panah.

Jawaban yang sangat menarik. Saya akan meminta edit cepat: biarkan lebih eksplisit apa warisan / penahanan / kolaborasi antara empat kelas yang Anda sebutkan. Terima kasih banyak!

— heltonbiker

Saya menambahkan diagram kelas UML. Apakah ini membantu?

2

Saya akan mengatakan ini adalah jawaban yang mematikan , dan itu tidak hanya akan banyak membantu saya, tetapi saya percaya dapat membantu lebih banyak orang di masa depan. Selain itu, contoh hierarki kelas yang Anda berikan memetakan masalah dan domain solusi kami dengan sangat baik. Terima kasih banyak lagi!

— heltonbiker

Ketika saya membaca pertanyaan saya menyadari ada lebih banyak hal yang terjadi, jadi saya sedikit berlebihan dan membagikan seluruh desain. Ini lebih dari masalah penamaan sederhana karena nama merupakan indikasi dari desain. Saya telah bekerja dengan sistem yang dibangun dengan cara ini dan mereka bekerja dengan cukup baik.

11

Mungkin agak sulit untuk menemukan satu konvensi pemersatu di sini karena kelas-kelas ini tersebar di sejumlah ruang nama, ( ConnectionInfotampaknya ada di CrystalDecisions, dan DeviceInfodi System.Reporting.WebForms).

Melihat contoh-contoh ini, tampaknya ada dua kegunaan akhiran yang berbeda:

Membedakan kelas yang menyediakan metode statis dengan kelas yang menyediakan metode instan. Ini adalah kasus untuk System.IOkelas, sebagaimana digarisbawahi oleh deskripsi mereka:

Direktori :

Mengekspos metode statis untuk membuat, memindahkan, dan menghitung melalui direktori dan subdirektori. Kelas ini tidak dapat diwarisi.

Informasi Direktori :

Mengekspos metode instan untuk membuat, memindahkan, dan menghitung melalui direktori dan subdirektori. Kelas ini tidak dapat diwarisi.

Infosepertinya pilihan yang sedikit aneh di sini, tetapi itu membuat perbedaan relatif jelas: sebuah Directorykelas dapat mewakili direktori tertentu atau menyediakan metode pembantu terkait direktori umum tanpa memegang status apa pun, sedangkan yang DirectoryInfobenar-benar hanya bisa menjadi yang pertama.
Menekankan bahwa kelas hanya menyimpan informasi dan tidak memberikan perilaku yang mungkin diharapkan dari nama yang tidak berakhiran .

Saya pikir bagian terakhir dari kalimat itu mungkin adalah bagian dari teka-teki yang membedakan, katakanlah, ConnectionInfodari EmployeeInfo. Jika saya memiliki kelas yang dipanggil Connection, saya cukup berharap untuk benar-benar memberi saya fungsionalitas yang dimiliki oleh koneksi - saya akan mencari metode seperti void Open(), dll. Namun, tidak ada orang waras yang berharap bahwa sebuah Employeekelas dapat benar-benar lakukan apa yang nyata Employeelakukan, atau cari metode seperti void DoPaperwork()atau bool TryDiscreetlyBrowseFacebook().

— Ben Aaronson
sumber

1

Terimakasih banyak atas jawaban Anda! Saya percaya peluru pertama dalam jawaban Anda jelas menggambarkan apa yang terjadi di kelas .NET, tetapi yang kedua memiliki nilai lebih (dan omong-omong berbeda), karena itu mengungkapkan lebih baik abstraksi yang dimaksudkan: sesuatu yang akan digunakan vs hal yang harus dijelaskan. Sulit untuk memilih jawaban mana yang akan diterima.

— heltonbiker

4

Secara umum, suatu Infoobjek merangkum informasi tentang keadaan suatu objek pada suatu saat . Jika saya meminta sistem untuk melihat file dan memberi saya FileInfoobjek yang terkait dengan ukurannya, saya akan berharap objek itu melaporkan ukuran file pada saat permintaan diberikan (atau, lebih tepatnya, ukuran file beberapa saat antara saat panggilan dibuat dan ketika kembali). Jika ukuran file berubah antara waktu permintaan kembali dan waktu FileInfoobjek diperiksa, saya tidak akan mengharapkan perubahan seperti itu tercermin dalam FileInfoobjek.

Perhatikan bahwa perilaku ini akan sangat berbeda dari Fileobjek. Jika permintaan untuk membuka file disk dalam mode non-eksklusif menghasilkan Fileobjek yang memiliki Sizeproperti, saya akan mengharapkan nilai yang dikembalikan dengan demikian berubah ketika ukuran file disk berubah, karena Fileobjek tidak hanya mewakili keadaan file - itu mewakili file itu sendiri .

Dalam banyak kasus, objek yang menempel pada sumber daya harus dibersihkan ketika layanan mereka tidak lagi diperlukan. Karena *Infoobjek tidak melampirkan sumber daya, mereka tidak memerlukan pembersihan. Sebagai konsekuensinya, dalam kasus di mana suatu Infoobjek akan memenuhi persyaratan klien, mungkin lebih baik menggunakan kode daripada menggunakan objek yang akan mewakili sumber daya yang mendasarinya, tetapi yang hubungannya dengan sumber daya itu harus dibersihkan.

— supercat
sumber

1

Ini tidak persis salah, tetapi tampaknya tidak menjelaskan pola penamaan .NET dengan sangat baik, karena Filekelas tidak dapat dipakai dan FileInfoobjek melakukan pembaruan dengan sistem file yang mendasarinya.

— Nathan Tuggy

@ NathanTuggy Saya setuju bahwa ini tidak berhubungan dengan konvensi penamaan ini di .NET, tetapi mengenai masalah saya saat ini, saya percaya ini sangat relevan dan dapat menghasilkan solusi yang konsisten. Saya membatalkan jawaban ini, tetapi sulit untuk memilih hanya satu yang akan diterima ...

— heltonbiker

@ NathanTuggy: Saya tidak akan merekomendasikan menggunakan .NET sebagai model dari segala jenis konsistensi. Ini adalah Kerangka kerja yang baik dan berguna yang merangkum banyak ide bagus, tetapi beberapa ide buruk juga ikut tercakup.

— supercat

@supercat: Tentu; sepertinya aneh untuk menjawab pertanyaan tentang "mengapa. NET melakukan hal-hal seperti ini?" dengan "itu akan menjadi ide yang baik untuk melakukan hal-hal% THIS_WAY%".

— Nathan Tuggy

@ NathanTuggy: Saya tidak ingat rincian kelas yang bersangkutan, tetapi saya pikir FileInfohanya menyimpan informasi yang ditangkap secara statis. Bukan? Juga, saya tidak pernah memiliki kesempatan untuk membuka file dalam mode non-eksklusif, tetapi itu harus mungkin, dan saya akan berharap ada metode yang akan melaporkan ukuran file saat ini, bahkan jika objek yang digunakan untuk membuka tidak disebut File(biasanya saya hanya menggunakan ReadAllBytes, WriteAllBytes, ReadAllText, WriteAllText, dll).

— supercat

2

Mengingat perangkat yang sebenarnya (sensor dan penerima) adalah satu hal, dan representasi mereka dalam perangkat lunak adalah hal lain, saya berpikir tentang penamaan beberapa kelas dengan pola nama akhiran "Info".

Sebagai contoh, sementara a Sensorakan menjadi kelas untuk mewakili sensor aktual (ketika itu sebenarnya terhubung ke beberapa perangkat yang berfungsi), SensorInfoakan digunakan untuk hanya mewakili karakteristik sensor tersebut. Sebagai contoh, setelah menyimpan file, saya akan membuat cerita bersambung SensorInfoke tajuk file, alih-alih membuat cerita bersambung Sensor, yang jenisnya bahkan tidak masuk akal.

Saya tidak suka perbedaan ini. Semua objek adalah "representasi [s] dalam perangkat lunak." Itulah arti kata "objek".

Sekarang, mungkin masuk akal untuk memisahkan informasi tentang periferal dari kode aktual yang berinteraksi dengan periferal. Jadi, misalnya, Sensor memiliki-SensorInfo, yang berisi sebagian besar variabel instan, bersama dengan beberapa metode yang tidak memerlukan perangkat keras, sedangkan kelas Sensor bertanggung jawab untuk benar-benar berinteraksi dengan sensor fisik. Anda tidak memiliki-a Sensorkecuali komputer Anda memiliki sensor, tetapi Anda mungkin memiliki-a SensorInfo.

Masalahnya adalah bahwa desain semacam ini dapat digeneralisasi ke (hampir) kelas mana pun. Jadi kamu harus hati-hati. Anda jelas tidak akan memiliki SensorInfoInfokelas, misalnya. Dan jika Anda memiliki Sensorvariabel, Anda mungkin menemukan diri Anda melanggar hukum Demeter dengan berinteraksi dengan SensorInfoanggotanya. Tidak ada yang fatal, tentu saja, tetapi desain API tidak hanya untuk penulis perpustakaan. Jika Anda menjaga API Anda sendiri tetap bersih dan sederhana, kode Anda akan lebih mudah dikelola.

Sumber daya filesystem seperti direktori, menurut saya, sangat dekat dengan tepi ini. Ada beberapa situasi di mana Anda ingin menggambarkan direktori yang tidak dapat diakses secara lokal, benar, tetapi pengembang rata-rata mungkin tidak berada dalam salah satu situasi tersebut. Menyulitkan struktur kelas dengan cara ini, menurut pendapat saya, tidak membantu. Kontras dengan pendekatan Python dalam pathlib: Ada satu kelas yang "sangat mungkin apa yang Anda butuhkan" dan berbagai kelas tambahan yang diabaikan oleh sebagian besar pengembang. Namun, jika Anda benar-benar membutuhkannya, mereka menyediakan sebagian besar antarmuka yang sama, hanya dengan metode konkret dilucuti.

— Kevin
sumber

Terima kasih atas jawaban Anda, dan pujian untuk konstruk "have-a";) Jawaban Anda mengingatkan saya pada ketidaknyamanan yang disebabkan oleh beberapa konsep "DTO" (Data Transfer Object) - atau saudara kandungnya Parameter Object - yang disukai oleh lebih fanatik OO ortodoks karena biasanya tidak mengandung metode (setelah semua itu adalah objek transfer data ). Dalam pengertian itu, dan meringkas juga apa yang dikatakan orang lain, saya pikir itu SensorInfoakan menjadi semacam DTO, dan / atau juga seperti "snapshot", atau bahkan "spek", yang hanya mewakili data / keadaan bagian dari Sensorobjek aktual bahwa "mungkin tidak ada di sana".

— heltonbiker

Seperti kebanyakan masalah desain, tidak ada aturan yang keras dan cepat. Dalam contoh pathlib yang saya berikan, PureWindowsPathbertindak sedikit seperti objek Info, tetapi memiliki metode untuk melakukan hal-hal yang tidak memerlukan sistem Windows (misalnya mengambil subdirektori, memisahkan ekstensi file, dll.). Ini lebih bermanfaat daripada hanya menyediakan struct yang dimuliakan.

— Kevin

1

Sekali lagi, pujian untuk bagian "struct yang dimuliakan" :). Itu mengingatkan saya pada kutipan terkait dari buku "Kode Bersih" Paman Bob, Bab 6: "Pemrogram dewasa tahu bahwa gagasan bahwa segala sesuatu adalah objek adalah mitos. Kadang-kadang Anda benar-benar menginginkan struktur data sederhana dengan prosedur beroperasi pada mereka."

— heltonbiker

2

Saya akan mengatakan bahwa konteks / domain penting, karena kami memiliki kode logika bisnis tingkat tinggi dan model tingkat rendah, komponen arsitektur, dan sebagainya ...

'Info', 'Data', 'Manager', 'Object', 'Class', 'Model', 'Controller' dll. Dapat berupa sufiks yang bau, terutama pada level yang lebih rendah, karena setiap objek memiliki beberapa informasi atau data, sehingga informasi itu tidak perlu.

Nama kelas dari domain bisnis harus seperti semua pemangku kepentingan membicarakannya, tidak peduli apakah itu terdengar aneh atau tidak 100% bahasa yang benar.

Sufiks yang bagus untuk struktur data misalnya 'Daftar', 'Peta' dan untuk pola petunjuk 'Dekorator', 'Adaptor' jika Anda pikir itu perlu.

Untuk skenario sensor Anda, saya tidak akan berharap SensorInfountuk menyimpan apa sensor Anda, tetapi SensorSpec. Infoimho lebih merupakan informasi turunan, seperti FileInfosesuatu seperti ukuran, Anda tidak menyimpan atau filepath yang dibangun dari path dan nama file, dll.

Poin lain:

Hanya ada dua hal yang sulit dalam Ilmu Komputer: pembatalan cache dan penamaan hal-hal.

- Phil Karlton

Itu selalu mengingatkan saya pada memikirkan nama hanya untuk beberapa detik dan jika saya tidak menemukan nama, saya menggunakan nama-nama aneh dan 'TODO'-tandai mereka. Saya selalu dapat mengubahnya nanti karena IDE saya menyediakan dukungan refactoring. Ini bukan semboyan perusahaan yang harus bagus, tetapi hanya beberapa kode yang dapat kita ubah setiap kali kita inginkan. Ingatlah itu.

— Aitch
sumber

1

ThingInfo dapat berfungsi sebagai Proxy hanya baca yang bagus untuk Hal ini.

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

Proxy: "Berikan pengganti atau pengganti untuk objek lain untuk mengontrol akses ke sana."

Biasanya ThingInfo akan memiliki properti publik tanpa seter. Kelas-kelas ini dan metode-metode di kelas aman untuk digunakan dan tidak akan melakukan perubahan apa pun pada data dukungan, objek, atau objek lainnya. Tidak ada perubahan status atau efek samping lainnya yang akan terjadi. Ini dapat digunakan untuk pelaporan dan layanan web atau di mana pun Anda membutuhkan informasi tentang objek tetapi ingin membatasi akses ke objek itu sendiri.

Gunakan ThingInfo kapan pun memungkinkan dan batasi penggunaan Thing aktual hingga saat Anda benar-benar perlu mengubah objek Thing. Itu membuat membaca dan men-debug jauh lebih cepat ketika Anda terbiasa menggunakan pola ini.

— Shmoken
sumber

Luar biasa. Sebelumnya hari ini saya menganalisis kebutuhan arsitektur saya, mengenai kelas yang saya gunakan dalam pertanyaan, dan sampai pada kesimpulan yang sama. Dalam kasus saya, saya punya Receiveryang menerima aliran data dari banyak Sensor. Idenya adalah: penerima harus mengabstraksi sensor yang sebenarnya. Tetapi masalahnya adalah: Saya perlu info sensor sehingga saya bisa menulisnya ke beberapa file header. Solusinya: masing IReceiver- masing akan memiliki daftar SensorInfo. Jika saya mengirim perintah ke penerima yang menyiratkan perubahan status sensor, perubahan ini akan tercermin (melalui pengambil) pada masing-masing SensorInfo.

— heltonbiker

(lanjutan ...) yaitu: Saya tidak berbicara dengan sensor sendiri, saya hanya berbicara dengan Penerima melalui perintah tingkat yang lebih tinggi, dan Penerima pada gilirannya berbicara kepada masing-masing Sensor. Tapi saya akhirnya membutuhkan informasi dari sensor, yang saya dapatkan dari contoh Receiver melalui List<SensorInfo>properti readonly -nya .

— heltonbiker

1

Sejauh ini tidak ada orang dalam pertanyaan ini yang mengetahui alasan sebenarnya dari konvensi penamaan ini.

Sebuah DirectoryInfobukanlah yang direktori. Ini adalah sebuah DTO dengan data tentang direktori. Mungkin ada banyak contoh yang menggambarkan direktori yang sama. Itu bukan entitas. Ini adalah objek nilai yang dibuang. A DirectoryInfotidak mewakili direktori aktual. Anda juga dapat menganggapnya sebagai pegangan atau pengontrol untuk direktori.

Bandingkan dengan kelas yang bernama Employee. Ini mungkin objek entitas ORM dan itu adalah objek tunggal yang menggambarkan karyawan itu. Jika itu adalah nilai-objek tanpa identitas itu harus disebut EmployeeInfo. An Employeememang mewakili karyawan yang sebenarnya. Kelas DTO yang menyerupai nilai yang disebut EmployeeInfojelas tidak akan mewakili karyawan melainkan menggambarkannya atau menyimpan data tentangnya.

Sebenarnya ada contoh di BCL di mana kedua kelas ada: A ServiceControlleradalah kelas yang menjelaskan Layanan Windows. Bisa ada sejumlah pengontrol seperti itu untuk setiap layanan. A ServiceBase(atau kelas turunan) adalah layanan aktual dan secara konseptual tidak masuk akal untuk memiliki beberapa instance dari itu per layanan yang berbeda.

— usr
sumber

Ini terdengar mirip dengan Proxypola yang disebutkan oleh @Shmoken, bukan?

— heltonbiker

@heltonbiker tidak harus menjadi proxy. Itu bisa menjadi objek yang tidak terhubung dengan cara apa pun dengan hal yang dijelaskannya. Misalnya Anda mungkin mendapat EmployeeInfodari layanan web. Itu bukan proxy. Contoh lebih lanjut: Seorang AddressInfobahkan tidak memiliki sesuatu yang dapat diproksikan karena alamat bukan entitas. Itu nilai yang berdiri sendiri.

— usr

1

Saya mengerti, itu masuk akal!

— heltonbiker