Bagaimana pengubah akses menghambat pengembangan profesional muda

Sebagian besar bahasa OO populer menyediakan alat seperti pengubah untuk mengakses metode atau bidang. Dan ini bagus untuk programmer yang berpengalaman, tapi itu bukan tempat untuk memulai enkapsulasi. Di bawah ini saya akan menjelaskan alasannya.



Penafian. Artikel ini bukan ajakan untuk bertindak dan tidak menyatakan bahwa hanya ada satu-satunya cara yang benar untuk menyembunyikan data. Artikel ini dimaksudkan untuk menawarkan pembaca suatu perspektif baru tentang enkapsulasi. Ada banyak situasi di mana pengubah akses lebih disukai, tetapi ini bukan alasan untuk diam tentang antarmuka.

Secara umum, enkapsulasi didefinisikan sebagai alat untuk menyembunyikan implementasi internal suatu objek dari klien untuk menjaga integritas objek dan menyembunyikan kompleksitas dari implementasi yang sangat internal ini.

Ada beberapa cara untuk mencapai penyembunyian ini. Salah satunya adalah penggunaan pengubah akses, yang lainnya adalah penggunaan antarmuka (protokol, file header, ...). Ada fitur rumit lainnya, tetapi artikel ini bukan tentang mereka.

Sekilas pengubah akses mungkin tampak lebih kuat dalam hal menyembunyikan implementasi, karena mereka memberikan kontrol atas setiap bidang secara individual dan memberikan lebih banyak opsi akses. Pada kenyataannya, ini sebagian hanyalah jalan pintas untuk membuat beberapa antarmuka ke kelas. Akses pengubah memberikan kemampuan yang tidak lebih luas dari antarmuka, karena dengan bantuan mereka, mereka dinyatakan, kecuali untuk satu detail. Tentang dia di bawah ini.


Visibilitas lapangan ditunjukkan oleh berbagai pengubah akses di Jawa.

Cuplikan kode di bawah ini menunjukkan kelas dengan pengubah akses ke metode dan representasi yang setara dalam bentuk antarmuka.

public class ConsistentObject { public void methodA() { /* ... */ } protected void methodB() { /* ... */ } void methodC() { /* ... */ } private void methodD() { /* ... */ } } public interface IPublicConsistentObject { void methodA() { /* ... */ } } public interface IProtectedConsistentObject: IPublicConsistentObject { void methodB() { /* ... */ } } public interface IDefaultConsistentObject: IProtectedConsistentObject { void methodC() { /* ... */ } } 

Protokol memiliki beberapa keunggulan. Cukup untuk menyebutkan bahwa ini adalah cara utama untuk mengimplementasikan polimorfisme di OOP, yang menjangkau pendatang baru jauh lebih lambat dari yang seharusnya.

Satu-satunya kesulitan mendekati dengan protokol adalah bahwa Anda perlu mengontrol proses membuat objek. Membangkitkan templat diperlukan secara tepat untuk melindungi kode berbahaya yang berisi tipe spesifik dari kode murni yang berfungsi dengan antarmuka. Memperhatikan aturan sederhana ini, kami mendapatkan enkapsulasi yang sama dengan menggunakan kualifikasi, tetapi pada saat yang sama kami mendapatkan lebih banyak fleksibilitas.

Kode seperti itu dalam C #

 public class DataAccessObject { private void readDataFromFixedSource() { // ... } public byte[] getData() { // ... } } 

akan setara dengan itu untuk kemampuan klien.

 public class DataAccessObjectFactory { public IDataAccessObject createNew() { return new DataAccessObject(); } } public interface IDataAccessObject { byte[] getData(); } class DataAccessObject: IDataAccessObject { void readDataFromFixedSource() { // ... } public byte[] getData() { // ... } } 

Karena adanya pengubah akses, pemula tidak akan tahu tentang antarmuka untuk waktu yang sangat lama. Karena itu, mereka tidak menggunakan kekuatan PLO yang sebenarnya. Artinya, ada beberapa substitusi konsep. Pengubah akses tidak diragukan lagi merupakan atribut dari OOP, tetapi mereka juga menarik selimut dari antarmuka yang membuka OOP jauh lebih kuat.

Selain itu, antarmuka membuat Anda secara sadar memilih fitur apa yang dapat diterima klien dari objek. Artinya, kami memiliki kesempatan untuk menyediakan protokol yang sama sekali tidak terkait untuk klien yang berbeda, sementara pengubah tidak membedakan antara klien. Ini merupakan nilai tambah yang besar untuk antarmuka.