Nested Classes: Alat yang berguna atau pelanggaran enkapsulasi?


11

Jadi saya masih di pagar apakah saya harus menggunakan ini atau tidak.

Saya merasa ini merupakan pelanggaran ekstrim terhadap enkapsulasi, namun saya menemukan bahwa saya dapat mencapai beberapa tingkat enkapsulasi sambil mendapatkan lebih banyak fleksibilitas dalam kode saya.

Proyek Java / Swing Sebelumnya saya telah menggunakan kelas bersarang untuk beberapa derajat, Namun sekarang saya telah pindah ke proyek lain di C # dan saya menghindari penggunaannya.

Bagaimana perasaan Anda tentang kelas bersarang?


Bagaimana tepatnya kelas bersarang merupakan pelanggaran enkapsulasi? Jika ada mereka lebih dienkapsulasi karena mereka 'dienkapsulasi' di dalam kelas lain, dan secara opsional dapat dibuat pribadi.
Steven Jeuris

Jawaban:


8

Yah, sederhananya: kelas bersarang tidak melanggar enkapsulasi dan secara umum, fitur bahasa tidak melanggar prinsip pemrograman. Pemrogram melanggar prinsip pemrograman.

Lucunya, diklaim kelas bersarang meningkatkan enkapsulasi :

Enkapsulasi yang ditingkatkan — Pertimbangkan dua kelas tingkat atas, A dan B, di mana B membutuhkan akses ke anggota A yang jika tidak akan dinyatakan pribadi. Dengan menyembunyikan kelas B dalam kelas A, anggota A dapat dinyatakan pribadi dan B dapat mengaksesnya. Selain itu, B sendiri dapat disembunyikan dari dunia luar.

Ada beberapa kebenaran di dalamnya.

Biasanya B adalah hasil dari penerapan SRP ke A. B itu sendiri tetapi berpotensi melanggar banyak prinsip, terutama, jika semua itu dilakukan dengan mengutak-atik anggota pribadi A: D

Saya pikir kelas tersembunyi dapat bermanfaat. Tetapi ada banyak potensi penyalahgunaan.


5

Kami menggunakan kelas bersarang sepanjang waktu. Dalam banyak situasi, perangkat lunak / proses bisnis memiliki objek bisnis bersarang. Kita semua telah melihat contoh objek Order yang memiliki koleksi OrderItems bersarang.

Intinya adalah itu membuat membaca / menulis kode lebih mudah dan jarang ada kasus di mana Anda akan membutuhkan kelas Order Anda dan tidak perlu tahu tentang OrderItems.


1

Secara pribadi, saya merasa mereka harus dihindari karena mereka memadukan desain Anda dengan berbagai cara (biasanya tidak menguntungkan).

Namun, jika proyek Anda memiliki ruang lingkup yang ditetapkan dan merangkum kelas (seperti kelas Node atau semacam objek yang digunakan untuk melintasi struktur data kelas tertentu) maka saya tidak melihat bahayanya.

Bahkan, saya pikir untuk jenis proyek tertentu itu membuat kode (dan alasannya) lebih mudah dibaca / mudah dimengerti. Namun, saya pikir untuk sebagian besar proyek dengan ekstensibilitas dalam pikiran, itu adalah ide yang buruk, karena jarang akan memisahkan mereka menyebabkan masalah Anda, tetapi meninggalkan mereka bersama-sama dapat memaksa Anda untuk memisahkan mereka di masa depan (yang membuang-buang waktu).


0

(Dalam C #) Secara umum saya akan menghindarinya, meskipun itu dapat bergantung dengan tepat apa tujuan kelas tersebut.

Saya tidak akan pernah menggunakannya untuk semua jenis kelas model domain, itu tidak masuk akal bagi saya.

Saya biasa menggunakannya untuk menyusun data yang bersifat pribadi di kelas luar, tetapi saya menemukan bahwa ini hampir selalu berakhir secara eksternal di kemudian hari dalam siklus proyek jadi saya biasanya tidak repot dengan ini lagi.

Satu-satunya waktu saya menggunakannya sekarang adalah untuk trik pengkodean kecil yang aneh di mana menggunakan kelas kecil lainnya membuat menerapkan kelas tertentu lebih mudah, atau mengimplementasikan antarmuka yang benar-benar hanya pola pemberitahuan acara (di mana kelas internal akan mengimplementasikan antarmuka dan hanya melewati kontrol kembali kelas luar).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.