Mengapa antarmuka memerlukan metode lebih dari anggota?


8

... Karena ini memaksa kita untuk membuat getter dan setter, yang dalam praktiknya sering sama sekali asing? Apakah ada alasan desain bahasa yang baik mengapa antarmuka di sebagian besar (semua?) Bahasa tidak memungkinkan bidang anggota untuk membantu memenuhi spesifikasi antarmuka?

Dalam sebagian besar bahasa yang ada, anggota diperlakukan secara fundamental berbeda dari metode, tetapi apakah ini HARUS terjadi? Dalam bahasa teoretis, tidak bisakah kita memiliki antarmuka yang (a) menetapkan metode zero-arg sebagai pengambil, tetapi menerima anggota yang dapat dibaca sebagai implementor, dan (b) menetapkan metode satu-arg sebagai penyetel, tetapi menerima bidang anggota yang dapat ditulis sebagai implementornya, diberikan bahasa yang mendukung penetapan kontrol akses langsung pada variabel ketika dideklarasikan? Bahasa prototipe yang memungkinkan pewarisan berganda (untuk membahas poin yang sangat valid yang dibuat beberapa responden), akan ideal untuk hal seperti ini.

Tolong beri tahu saya jika sesuatu seperti ini sudah ada.


2
Uh ... metode adalah anggota. Saya kira maksud Anda "bidang anggota"?
Aaronaught

OK untuk menggunakan terminologi Java yang tepat, ya, "bidang anggota". Terima kasih telah menunjukkannya.
Insinyur

1
OOP menyebalkan, tetapi cobalah C # jika Anda harus.
Pekerjaan

Jawaban:


3

Jelas dalam sebagian besar bahasa yang ada, anggota diperlakukan secara fundamental berbeda dari metode, tetapi apakah ini HARUS terjadi?

Bukan untuk alasan yang didasarkan pada teori. Saya pikir alasan mengapa Anda tidak sering melihatnya praktis:

Yang pertama adalah bagaimana Anda menangani hal-hal ini saat runtime. Di Java atau C ++, penugasan kepada anggota publik yang diketik primitif seperti foo.x = 5mudah untuk ditangani: barang 5- barang ke dalam register, mencari tahu di mana dalam memori xanggota fookehidupan dan membuang register di sana. Dalam bahasa seperti C # di mana kelas dapat merangkum tugas pencegatan kepada anggota atau pra-menghitung bagaimana anggota akan mengevaluasi , kompiler tidak akan memiliki prioritaspengetahuan tentang apakah implementasi kelas yang disediakan saat runtime menggunakan fitur itu. Itu berarti semua penugasan anggota publik dan evaluasi anggota publik harus ditunda untuk implementasi. * Operasi yang melibatkan banyak akses ke anggota tersebut akhirnya membuat hit kinerja karena mereka terus melakukan panggilan subrutin yang dapat ditangani lebih cepat dengan teratur tugas in-line. Meninggalkan evaluasi dan penugasan terpisah dari getter dan setter memberi pengembang kontrol atas bagaimana mereka ditangani dalam situasi tertentu.

Yang kedua adalah usia. Dengan pengecualian yang mungkin untuk F #, tidak ada bahasa yang digunakan secara luas saat ini lebih muda dari satu dekade, dan bahkan baru-baru ini, siklus tambahan yang diperlukan untuk membuat evaluasi dan penugasan yang mungkin dilakukan mungkin tidak dapat diterima.

Ketiga adalah inersia. Saya pikir sampai tingkat tertentu, masih ada beberapa stigma yang terkait dengan melakukan penugasan langsung kepada anggota publik bahkan jika bahasa tersebut memungkinkan kelas untuk memanipulasi mereka dan orang-orang masih berpikir dalam hal getter dan setter menjadi lebih baik. Itu akan hilang dengan waktu, seperti halnya dengan semua orang yang memiliki hidung di udara di atas orang-orang yang menulis program dalam bahasa tingkat yang lebih tinggi daripada berkumpul.


* Ada tradeoff yang datang dengan ini: bahasa harus pergi seluruh babi dengan menunda evals / tugas ke kelas atau menolak saat runtime jika kode menggunakan in-line evals / tugas untuk kelas tertentu mencoba untuk menghubungkan dengan implementasi yang memotong mereka . Secara pribadi, saya pikir yang terakhir adalah ide yang buruk karena memaksa kompilasi ulang kode yang menggunakan API yang tidak berubah.


Terima kasih, Anda telah memahami dorongan pertanyaan saya dan masuk ke detail-detail kasar MENGAPA. Saya punya firasat bahwa kecepatan akan menjadi salah satu alasan - seperti yang selalu terjadi ketika Anda menuju jalan "lebih dinamis". Seperti yang kita lihat sekarang dengan bahasa-bahasa seperti JS dan Python, fleksibilitas sering mengalahkan kecepatan, sehingga "inersia" yang Anda sebutkan ke arah tren desain bahasa tertentu berdasarkan pada (apa yang dulu perlu) optimasi perlahan-lahan larut.
Insinyur

F # sangat didasarkan pada Objective CAML - mungkin lebih muda dari satu dekade, tetapi sebagian besar (mungkin semua) ide-ide lebih tua.
Steve314

1
Saya agak ingin tahu mengapa kedua downvoters menekan tombol merah.
Blrfl

@ Blrfl: Kritik saya adalah bahwa jawaban Anda terlalu berfokus pada detail implementasi, daripada melihatnya dari sudut pandang desain bahasa. Saya tidak memilih Anda untuk itu, tetapi mungkin orang lain melakukannya.
Niels van der Rest

Scala juga relatif muda dan banyak digunakan
Display Name

10

Dalam sebagian besar bahasa yang ada, anggota [bidang?] Diperlakukan secara fundamental berbeda dari metode, tetapi apakah ini HARUS terjadi?

Ya, benar.

Bidang anggota adalah data per-instance. Data harus benar-benar ada di suatu tempat di memori untuk setiap contoh - harus ada alamat atau urutan alamat yang disediakan untuk itu. Di Java, .NET, dan banyak bahasa OO lainnya, data ini terus bertambah.

Metode adalah data per kelas. Mereka adalah pointer ke tabel. Begitulah cara mendapatkan pengiriman virtual. Sebenarnya hanya ada satu instance yang dialokasikan, per kelas.

Antarmuka pada dasarnya adalah tipe kelas khusus yang hanya berisi metode, tidak ada data instan. Itu bagian dari definisi antarmuka. Jika itu berisi data apa pun, itu tidak akan menjadi antarmuka lagi, itu akan menjadi kelas abstrak. Kedua pilihan itu baik-baik saja, tentu saja, tergantung pada pola desain seperti apa yang Anda coba terapkan. Tetapi jika Anda menambahkan data instan ke antarmuka, Anda akan mengambil semua yang membuatnya antarmuka.

OK, jadi mengapa metode antarmuka tidak bisa menunjuk ke bidang anggota? Karena tidak ada apa-apa di tingkat kelas untuk menunjuk. Sekali lagi, sebuah antarmuka tidak lain hanyalah sebuah tabel metode. Kompiler hanya dapat menghasilkan satu tabel, dan setiap metode di dalamnya harus mengarah ke alamat memori yang sama. Jadi tidak mungkin metode antarmuka untuk menunjuk ke bidang kelas, karena bidang kelas adalah alamat yang berbeda untuk setiap contoh.

Mungkin kompiler dapat menerima ini dan menghasilkan metode pengambil untuk antarmuka untuk menunjuk ke - tetapi kemudian pada dasarnya menjadi properti . Jika Anda ingin tahu mengapa Java tidak memiliki properti, yah ... itu adalah kisah yang sangat panjang dan membosankan yang saya lebih suka tidak masuki di sini. Tapi jika Anda tertarik, Anda mungkin ingin melihat pada bahasa OO lain yang melakukan menerapkan sifat, seperti C # atau Delphi. Sintaksnya sangat mudah:

public interface IFoo
{
    int Bar { get; }
}

public class Foo : IFoo
{
    public int Bar { get; set; }
}

Yap, hanya itu yang ada untuk itu. Penting: Ini bukan bidang, "int Bar" di Fookelas adalah Properti Otomatis , dan kompiler melakukan persis seperti yang saya jelaskan di atas: secara otomatis menghasilkan getter dan setter (serta bidang anggota dukungan).

Jadi, rekap jawaban untuk pertanyaan Anda:

  • Antarmuka memerlukan metode karena seluruh tujuannya bukan untuk memuat data apa pun;
  • Alasan bahwa tidak ada gula sintaksis untuk membuatnya lebih mudah bagi kelas untuk mengimplementasikan antarmuka adalah karena desainer Java tidak menginginkannya - dan pada saat ini, kompatibilitas ke belakang adalah masalah. Desainer bahasa membuat pilihan seperti ini; Anda hanya harus menghadapinya, atau beralih.

Ini adalah jawaban yang baik, khususnya saya menemukan informasi tentang fungsi pencarian informatif. Terima kasih.
Insinyur

9

ini adalah hasil dari penyembunyian informasi, yaitu anggota tersebut tidak boleh terlihat sebagai bidang tetapi sebagai properti yang mungkin atau mungkin tidak disimpan / di-cache secara lokal

salah satu contoh adalah kode hash itu berubah ketika objek berubah sehingga lebih baik untuk menghitungnya ketika diminta dan tidak setiap kali objek berubah

selain itu sebagian besar bahasa adalah single-inheritance + multi-implement dan memungkinkan bidang untuk menjadi bagian dari antarmuka menempatkan Anda ke dalam wilayah multi-inheritance (satu-satunya hal yang hilang adalah implementasi fungsi default) yang merupakan ladang ranjau kasus tepi untuk mendapatkan yang benar


bidang multi-pelaksana adalah masalah di sini.
DeadMG

Saya harus mengatakan, memikirkan hal ini lebih jauh, saya tidak begitu setuju tentang multiple inheritance. Karena apa yang sebenarnya saya tanyakan adalah apakah representasi anggota data dalam antarmuka dimungkinkan, bukan apakah Anda dapat menggunakan anggota data untuk membangun antarmuka (yang pada dasarnya adalah kelas abstrak C ++). Ada perbedaan utama di sana.
Insinyur

Benar-benar tidak ada masalah dengan MI; sebuah bahasa hanya perlu menolak menerapkan dua antarmuka dengan tipe yang saling bertentangan untuk anggota yang sama.
Blrfl

6

Variabel anggota adalah implementasi kelas, bukan antarmuka. Anda mungkin ingin mengubah implementasi, jadi kelas lain tidak boleh diizinkan untuk merujuk ke implementasi itu secara langsung.

Pertimbangkan kelas dengan metode berikut - Sintaks C ++, tapi itu tidak penting ...

class example
{
  public:
    virtual void Set_Mode (int p_mode);
    virtual int  Mode () const;
};

Tampaknya cukup jelas bahwa akan ada variabel anggota yang dipanggil modeatau m_modeserupa yang secara langsung menyimpan nilai mode itu, melakukan cukup banyak apa yang "properti" akan lakukan dalam beberapa bahasa - tetapi itu tidak selalu benar. Ada banyak cara berbeda yang bisa ditangani. Misalnya, metode Set_Mode mungkin ...

  1. Identifikasi mode menggunakan pernyataan sakelar.
  2. Instantiate subclass dari beberapa kelas internal, tergantung pada nilai mode itu.
  3. Menyimpan pointer ke instance itu sebagai variabel anggota.

Setelah melakukan itu, banyak metode lain dari kelas contoh kemudian dapat memanggil metode yang sesuai dari kelas internal melalui pointer, mendapatkan perilaku mode khusus tanpa perlu memeriksa apa mode saat ini.

Intinya di sini kurang bahwa ada lebih dari satu cara yang mungkin untuk menerapkan hal semacam ini, dan lebih banyak lagi bahwa pada suatu waktu Anda mungkin berubah pikiran. Mungkin Anda mulai dengan variabel sederhana, tetapi semua pernyataan peralihan untuk mengidentifikasi mode dalam setiap metode semakin menyebalkan. Atau mungkin Anda memulai dengan hal instance-pointer, tetapi itu ternyata terlalu berat untuk situasi Anda.

Ternyata hal-hal seperti ini dapat terjadi untuk data anggota apa pun. Anda mungkin perlu mengubah unit tempat nilai disimpan dari mil ke kilometer, atau Anda mungkin menemukan bahwa pencacahan nomor identifikasi-unik Anda tidak lagi dapat secara unik mengidentifikasi semua kasing tanpa mempertimbangkan beberapa informasi tambahan, atau apa pun.

Ini juga dapat terjadi untuk metode - beberapa metode murni untuk penggunaan internal, tergantung pada implementasinya, dan harus bersifat pribadi. Tetapi banyak metode adalah bagian dari antarmuka, dan tidak perlu diganti namanya atau apa pun hanya karena implementasi internal kelas telah diganti.

Bagaimanapun, jika implementasi Anda diekspos, kode lain pasti akan mulai bergantung padanya, dan Anda akan dikunci untuk menjaga implementasi itu. Jika implementasi Anda disembunyikan dari kode lain, situasi itu tidak dapat terjadi.

Memblokir akses ke detail implementasi disebut "data hiding".


"Kode ke antarmuka, bukan implementasi" ... Benar. Kadang-kadang kita mengetahui hal-hal ini akhir-akhir ini tetapi dibutuhkan seseorang untuk memikirkannya seperti yang telah Anda lakukan, untuk benar-benar memperkuat konsep sekali lagi.
Insinyur

Oke tunggu sebentar. Setelah berpikir lebih jauh, silakan lihat edit saya untuk pertanyaan itu.
Insinyur

Agak sulit untuk mengetahui apa hasil edit Anda - karena beberapa alasan, perbedaan untuk beberapa suntingan yang lebih lama tidak ditampilkan. Namun, menurut saya perkataan Anda adalah "mengapa properti tidak dapat memiliki variabel anggota sebagai implementasi default?" Properti terlihat (antarmuka) seperti variabel anggota, tetapi diimplementasikan melalui metode pengambil / penyetel. Dan IMO tidak ada alasan mengapa, secara default, metode pengambil / penyetel tidak boleh menerapkan baca / tulis ke variabel anggota - atau mengapa panggilan pengambil dan penyetel tidak boleh dioptimalkan saat aman - memungkinkan pewarisan, terpisah kompilasi dll.
Steve314

@Nick - Jadi ya, selama mungkin untuk mengatakan "pengambil dan / atau penyetel untuk properti ini harus murni" atau " tidak boleh yang default" Saya pikir itu ide yang bagus - menghilangkan beberapa kekacauan untuk kasus umum dengan properti. Saya tidak tahu apakah ada bahasa yang sudah melakukannya - belum menggunakan properti banyak bahkan dalam bahasa di mana mereka ada - tetapi saya akan terkejut jika ini belum didukung.
Steve314

3

Seperti yang orang lain catat, sebuah antarmuka menggambarkan apa yang dilakukan kelas, bukan bagaimana melakukannya. Ini pada dasarnya sebuah kontrak yang harus dipenuhi oleh kelas yang mewarisi.

Apa yang Anda jelaskan sedikit berbeda - kelas yang menyediakan beberapa implementasi tetapi mungkin tidak semua, sebagai bentuk penggunaan kembali. Ini umumnya dikenal sebagai kelas abstrak dan didukung dalam sejumlah bahasa (misalnya C ++ dan Java). Kelas-kelas ini tidak dapat di-instantiate dengan hak mereka sendiri, mereka hanya bisa diwarisi oleh kelas-kelas konkret (atau lebih lanjut abstrak).

Sekali lagi seperti yang sudah disebutkan, kelas-kelas abstrak cenderung memiliki nilai paling besar dalam bahasa-bahasa yang mendukung multiple-inheritance karena mereka dapat digunakan untuk menyediakan bagian-bagian fungsionalitas tambahan untuk kelas yang lebih besar. Namun, ini sering dianggap gaya buruk, karena umumnya hubungan agregasi ("memiliki-a") akan lebih tepat


Jawaban yang bagus. Saya cenderung menyukai komposisi hampir seluruhnya dalam jenis tugas yang saya lakukan hari ini. Saya pribadi tidak percaya pada perlakuan yang terpisah dari kelas abstrak dan antarmuka dalam bahasa tertentu, seperti yang lain di papan tulis ini telah katakan, meskipun ada alasan untuk ini, umumnya alasan ini adalah karena keterbatasan bahasa mendasar (seperti disebutkan dalam komentar saya pada jawaban ratchet freak).
Insinyur

1
Saya cenderung setuju dengan komentar Anda re: abstract / interfaces. Ketika saya melihat kembali kode lama di mana saya menggunakan banyak kelas abstrak, jelas bagi saya dengan pengalaman 10-15 tahun bahwa saya menggunakan fitur bahasa untuk mengkodekan desain yang buruk
Steve Mallam

1

Tolong beri tahu saya jika sesuatu seperti ini sudah ada.

Properti Objective-C menyediakan fungsionalitas semacam ini dengan aksesor properti yang disintesis. Properti Objective-C pada dasarnya hanya janji bahwa kelas menyediakan accessors, biasanya dari bentuk foountuk pengambil dan setFoo:untuk penyetel. Deklarasi properti menentukan atribut tertentu dari accessors yang terkait dengan manajemen memori dan perilaku threading. Ada juga @synthesizearahan yang memberi tahu kompiler untuk menghasilkan pengakses dan bahkan variabel instance terkait, jadi Anda tidak perlu repot menulis getter dan setter atau mendeklarasikan sebuah ivar untuk setiap properti. Ada juga beberapa gula sintaksis yang membuat akses properti terlihat seperti mengakses bidang struct, tetapi sebenarnya menghasilkan panggilan pengakses properti.

Hasil dari semua itu adalah bahwa saya dapat mendeklarasikan kelas dengan properti:

@interface MyClass : NSObject
{}
@property (assign) int foo;
@property (copy) NSString *bar;
@end

dan kemudian saya dapat menulis kode yang terlihat seperti mengakses ivars secara langsung, tetapi sebenarnya menggunakan metode accessor:

MyClass *myObject = [[MyClass alloc] init];  // create myObject

// setters
myObject.foo = 127;                 // same as [myObject setFoo:127];
myObject.bar = @"Hello, world!";    // same as [myObject setBar:@"Hello, world!"];

// getters
int i = myObject.foo                // same as [myObject foo];
NSString *s = myObject.bar          // same as [myObject bar];

Sudah dikatakan bahwa pengakses memungkinkan Anda memisahkan antarmuka dari implementasi, dan alasan yang ingin Anda lakukan adalah untuk menjaga kemampuan Anda untuk mengubah implementasi di masa depan tanpa mempengaruhi kode klien. Kekurangannya adalah Anda harus cukup disiplin untuk menulis dan menggunakan pengakses hanya untuk menjaga opsi masa depan Anda terbuka. Objective-C membuat menghasilkan dan menggunakan accessor semudah menggunakan ivars secara langsung. Bahkan, karena mereka menangani banyak pekerjaan manajemen memori, menggunakan properti sebenarnya jauh lebih mudah daripada mengakses gars secara langsung. Dan ketika saatnya tiba bahwa Anda ingin mengubah implementasi Anda, Anda selalu dapat menyediakan accessors Anda sendiri daripada membiarkan kompiler menghasilkannya untuk Anda.


1

Mengapa antarmuka memerlukan metode lebih dari anggota?

... Karena ini memaksa kita untuk membuat getter dan setter, yang dalam praktiknya sering sama sekali asing? Apakah ada alasan desain bahasa yang bagus mengapa antarmuka di sebagian besar (semua?) Bahasa tidak memungkinkan anggota untuk membantu memenuhi spesifikasi antarmuka?

Bahasa "Terbanyak"? Bahasa apa yang telah Anda selidiki? Dalam bahasa dinamis tidak ada antarmuka. Hanya ada tiga atau empat bahasa OO yang diketik secara statis dengan popularitas apa pun: Java, C #, Objective-C, dan C ++. C ++ tidak memiliki antarmuka; alih-alih kami menggunakan kelas abstrak, dan kelas abstrak dapat berisi anggota data publik. C # dan Objective-C keduanya mendukung properti, sehingga tidak perlu getter dan setter dalam bahasa tersebut. Hanya menyisakan Jawa. Agaknya satu-satunya alasan Java tidak mendukung properti adalah karena sulit untuk memperkenalkannya dengan cara yang kompatibel dengan terbelakang.


Anggota dimaksudkan untuk merujuk ke "bidang anggota" yang bertentangan dengan "fungsi anggota" yang saya sebut hanya sebagai metode. Saya tidak yakin dari bahasa mana (jika ada) saya mengambil konvensi ini. Jadi, mengingat apa yang saya tulis, saya melihat jawaban Anda, tetapi saya kira komentar di bawah pertanyaan saya untuk mengklarifikasi akan lebih konstruktif.
Insinyur

Re C ++, sentuh. Namun, sebenarnya ada antarmuka dalam bahasa dinamis, JS dan Python adalah dua yang langsung muncul di benak. Apakah pendukung bahasa yang diketik secara statis akan memanggil "antarmuka" ini, adalah diskusi lain yang sama sekali tidak ada gunanya saya membahasnya. Secara pribadi saya menunjukkan sedikit preferensi untuk kedua sisi pagar itu, menggunakan karena saya melakukan berbagai bahasa untuk tujuan yang berbeda.
Insinyur

@Nick: JS dan Python memiliki warisan, tapi saya tidak akan mengatakan mereka memiliki antarmuka; seseorang dapat memanggil metode apa pun pada objek apa pun.
kevin cline

1

Beberapa jawaban menyebutkan 'menyembunyikan informasi' dan 'detail implementasi' karena alasan metode antarmuka lebih disukai daripada bidang. Saya pikir alasan utamanya lebih sederhana dari itu.

Antarmuka adalah fitur bahasa yang memungkinkan Anda untuk bertukar perilaku dengan meminta beberapa kelas mengimplementasikan antarmuka. Perilaku kelas ditentukan oleh metodenya. Fields, di sisi lain, hanya mencerminkan keadaan suatu objek.

Tentu saja, bidang atau properti kelas mungkin menjadi bagian dari perilaku, tetapi mereka bukan bagian penting dari kontrak yang ditentukan oleh antarmuka; mereka hanya hasil. Itulah sebabnya misalnya C # memungkinkan Anda untuk mendefinisikan properti dalam sebuah antarmuka, dan di Jawa Anda mendefinisikan pengambil dalam antarmuka. Di sinilah sedikit informasi yang disembunyikan berperan, tetapi itu bukan poin utama.

Seperti yang saya katakan sebelumnya, antarmuka memungkinkan Anda untuk bertukar perilaku, tapi mari kita lihat bagian bertukar. Antarmuka memungkinkan Anda untuk mengubah implementasi yang mendasarinya dengan membuat kelas implementasi baru. Jadi memiliki antarmuka yang terdiri dari bidang tidak masuk akal, karena Anda tidak bisa banyak berubah tentang implementasi bidang.

Satu-satunya alasan Anda ingin membuat antarmuka bidang saja adalah ketika Anda ingin mengatakan bahwa beberapa kelas adalah jenis objek tertentu. Saya telah menekankan bagian 'adalah', karena Anda harus menggunakan warisan daripada antarmuka.


Catatan: Saya tahu bahwa komposisi yang lebih disukai daripada warisan dan komposisi biasanya hanya dapat dicapai dengan menggunakan antarmuka, tetapi menggunakan antarmuka hanya untuk 'menandai' kelas dengan beberapa properti sama buruknya. Warisan sangat bagus jika digunakan dengan tepat, dan selama Anda tetap berpegang pada Prinsip Tanggung Jawab Tunggal, Anda seharusnya tidak memiliki masalah.

Maksud saya, saya tidak pernah bekerja dengan perpustakaan kontrol UI misalnya, yang tidak menggunakan warisan. Satu-satunya area di mana antarmuka berperan di sini adalah dalam penyediaan data, misalnya ITableDataAdapteruntuk mengikat data ke kontrol tabel. Hal ini persis jenis hal interface dimaksudkan untuk, untuk memiliki perilaku dipertukarkan .


0

Di Jawa alasannya adalah bahwa antarmuka hanya memungkinkan metode yang ditentukan .

Oleh karena itu jika Anda menginginkan sesuatu dengan bidang dalam kontrak antarmuka, Anda perlu melakukannya sebagai metode pengambil dan penyetel.

Lihat juga pertanyaan ini: Kapan Getters and Setters dibenarkan


1
Terima kasih telah datang untuk menjawab, sebenarnya tanggapan Anda tentang topik itulah yang membuat saya mengajukan pertanyaan ini :) Tetapi pertanyaannya tetap, "-WHY- apakah mereka hanya mengizinkan metode?" Titik antarmuka bukan untuk menentukan metode, itu logika siklus. Inti dari antarmuka adalah untuk memastikan bahwa beberapa derajat fungsi dasar terpenuhi. Anggota dapat membuat bagian dari fungsi itu. Jadi mengapa tidak mengizinkan mereka untuk berpartisipasi dalam pemenuhan antarmuka?
Insinyur

Saya tidak tahu. Mungkin jika Anda bertanya langsung kepada Gosling atau Steele?

-1

Inti dari antarmuka adalah menentukan fungsi yang harus Anda terapkan untuk mengklaim mendukung antarmuka ini.


2
Ini tidak menjawab pertanyaan. Pertanyaannya adalah MENGAPA mereka melakukannya dengan cara itu? Pernahkah Anda mempertimbangkan untuk tidak menulis getter dan setter untuk setiap variabel, dan masih dapat memenuhi antarmuka? Itu akan menghemat waktu!
Insinyur

Anda terus bertanya tentang getter dan setter, dan saya tidak tahu mengapa. Lihatlah antarmuka yang sederhana: unduh.oracle.com/javase/6/docs/api/java/util/… Perhatikan bagaimana tidak ada getter dan setter?
Scott C Wilson

1
Apa buktinya? Apakah satu contoh itu membuktikan Anda tidak akan pernah membutuhkan akses sederhana / langsung ke anggota? Intinya adalah, konyol untuk membungkus anggota dalam getter / setter sebagai bagian dari antarmuka, jika bahasa itu sendiri dapat mengatasinya secara otomatis.
Insinyur

Ada ratusan contoh lain seperti ini. Bisakah Anda memberi saya contoh situasi yang sedang Anda bicarakan?
Scott C Wilson

-1

Anggota tidak diperbolehkan dalam antarmuka karena bahasa-bahasa itu harus berurusan dengan kejahatan yang menghebohkan, pewarisan berganda.


2
Tidak yakin saya ikuti. Mengapa mengijinkan variabel anggota dalam antarmuka memerlukan atau menyiratkan dukungan untuk pewarisan berganda?
Steve Mallam
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.