Memahami Interface C++
Ketika Anda sedang merancang sebuah kelas di C ++, hal pertama yang Anda harus memutuskan adalah antarmuka publik untuk kelas. Antarmuka publik menentukan bagaimana kelas Anda akan digunakan oleh programmer lain (atau Anda), dan sekali dirancang dan dilaksanakan umumnya harus tetap cukup konstan. Anda dapat memutuskan untuk menambah antarmuka, tetapi setelah Anda mulai menggunakan kelas, akan sulit untuk menghapus fungsi dari antarmuka publik (kecuali mereka tidak digunakan dan tidak diperlukan di tempat pertama).
Tapi itu tidak berarti bahwa Anda harus mencakup fungsi lainnya di kelas Anda dari yang diperlukan hanya agar nanti dapat memutuskan apa yang harus menghapus dari antarmuka. Jika Anda melakukan ini, Anda hanya akan membuat kelas lebih sulit untuk digunakan. Orang-orang akan mengajukan pertanyaan seperti, "mengapa ada empat cara untuk melakukan hal ini? Mana yang lebih baik? Bagaimana saya bisa memilih antara mereka?" Ini biasanya lebih mudah untuk menjaga hal-hal sederhana dan menyediakan satu cara untuk melakukan setiap hal kecuali ada alasan kuat mengapa kelas Anda harus menawarkan beberapa metode dengan fungsi dasar yang sama.
Pada saat yang sama, hanya karena menambahkan metode untuk antarmuka publik (mungkin) akan tidak melanggar apa-apa itu tidak berarti bahwa Anda harus mulai dengan antarmuka kecil. Pertama-tama, jika ada yang memutuskan untuk mewarisi dari kelas Anda dan Anda kemudian memilih fungsi dengan nama yang sama, Anda berada dalam untuk muatan kapal kebingungan. Pertama, jika Anda tidak mendeklarasikan fungsi virtual, maka obyek subclass akan memiliki fungsi yang dipilih tergantung pada jenis statis pointer. Ini bisa berantakan. Selain itu, jika Anda menyatakan hal itu virtual, maka Anda memiliki masalah yang mungkin menyediakan berbagai jenis fungsi dari yang dimaksudkan oleh pelaksanaan asli fungsi itu. Akhirnya, Anda tidak bisa menambahkan fungsi virtual murni untuk kelas yang sudah digunakan karena tidak ada yang telah mewarisi dari itu akan telah menerapkan fungsi itu.
Antarmuka publik, maka, harus tetap konstan mungkin. Bahkan, pendekatan yang baik untuk merancang kelas adalah menulis antarmuka sebelum pelaksanaan karena itulah yang menentukan seberapa kelas Anda berinteraksi dengan seluruh dunia (yang lebih penting untuk program secara keseluruhan dari bagaimana kelas yang benar-benar dilaksanakan) . Selain itu, jika Anda menulis antarmuka yang pertama, Anda bisa mendapatkan merasakan bagaimana kelas akan bekerja dengan kelas-kelas lain sebelum Anda benar-benar menyelam ke rincian pelaksanaan.
Inheritance and Class Design Isu kedua desain kelas Anda adalah apa yang harus tersedia untuk programmer yang ingin membuat subclass. Interface ini terutama ditentukan oleh fungsi virtual, tetapi Anda juga dapat menyertakan metode dilindungi yang dirancang untuk digunakan oleh kelas atau subclass-nya (ingat bahwa metode yang dilindungi terlihat untuk subclass sementara metode swasta tidak).
Pertimbangan utama adalah apakah masuk akal untuk fungsi menjadi virtual. Sebuah fungsi harus virtual saat pelaksanaannya cenderung berbeda dari subclass ke subclass. Sebaliknya, setiap kali fungsi tidak harus mengubah, maka harus dibuat non-virtual. Ide utama adalah untuk berpikir tentang apakah untuk membuat fungsi virtual dengan menanyakan apakah fungsi harus selalu sama untuk setiap kelas.
Misalnya, jika Anda memiliki kelas yang dirancang untuk memungkinkan pengguna untuk memantau lalu lintas jaringan dan Anda ingin mengizinkan subclass yang menerapkan cara yang berbeda untuk menganalisis lalu lintas, Anda mungkin menggunakan antarmuka berikut:
Di kelas ini, beberapa metode tidak akan berubah dari implementasi pelaksanaan; menambahkan sebuah paket harus selalu ditangani dengan cara yang sama, dan rata-rata ukuran paket tidak akan berubah baik. Di sisi lain, seseorang mungkin memiliki ide yang sangat berbeda dari apa artinya memiliki jaringan kelebihan beban. Ini akan berubah dari situasi ke situasi dan kami tidak ingin mencegah seseorang dari mengubah cara ini dihitung - untuk beberapa, apa pun lebih dari 10 Mbits / sec lalu lintas mungkin jaringan kelebihan beban, dan untuk orang lain, itu akan membutuhkan 100 Mbits / sec pada beberapa kabel jaringan tertentu. Akhirnya, ketika mewarisi publik dari kelas atau merancang untuk warisan, ingat bahwa Anda harus berusaha untuk itu menjadi jelas bahwa model warisan adalah-a. Pada intinya, adalah-hubungan berarti bahwa subclass harus mampu muncul di mana saja kelas induk bisa muncul. Dari sudut pandang pengguna kelas, seharusnya tidak peduli apakah kelas adalah kelas induk atau subclass. Merancang adalah-hubungan, pastikan bahwa itu masuk akal untuk kelas untuk menyertakan fungsi-fungsi tertentu untuk memastikan bahwa itu tidak termasuk yang subclass tidak mungkin benar-benar perlu. Salah satu contoh memiliki fungsi tambahan adalah bahwa dari kelas Bird yang mengimplementasikan fungsi lalat. Masalahnya adalah bahwa tidak semua burung bisa terbang - penguin dan burung emu, misalnya. Hal ini menunjukkan bahwa pilihan desain yang lebih bijaksana mungkin untuk memiliki dua subclass burung, satu untuk burung yang bisa terbang dan satu untuk burung terbang. Tentu saja, itu mungkin berlebihan untuk memiliki dua subclass dari burung tergantung pada bagaimana kompleks hirarki kelas Anda akan. Jika Anda tahu bahwa tak seorang pun akan pernah mengharapkan menggunakan kelas Anda untuk burung terbang, maka itu tidak begitu buruk. Tentu saja, Anda tidak akan selalu tahu apa yang seseorang akan menggunakan kelas Anda untuk dan itu jauh lebih mudah untuk berpikir cermat sebelum Anda mulai menerapkan seluruh kelas hirarki daripada akan kembali dan mengubahnya sekali orang yang menggunakannya.
Tapi itu tidak berarti bahwa Anda harus mencakup fungsi lainnya di kelas Anda dari yang diperlukan hanya agar nanti dapat memutuskan apa yang harus menghapus dari antarmuka. Jika Anda melakukan ini, Anda hanya akan membuat kelas lebih sulit untuk digunakan. Orang-orang akan mengajukan pertanyaan seperti, "mengapa ada empat cara untuk melakukan hal ini? Mana yang lebih baik? Bagaimana saya bisa memilih antara mereka?" Ini biasanya lebih mudah untuk menjaga hal-hal sederhana dan menyediakan satu cara untuk melakukan setiap hal kecuali ada alasan kuat mengapa kelas Anda harus menawarkan beberapa metode dengan fungsi dasar yang sama.
Pada saat yang sama, hanya karena menambahkan metode untuk antarmuka publik (mungkin) akan tidak melanggar apa-apa itu tidak berarti bahwa Anda harus mulai dengan antarmuka kecil. Pertama-tama, jika ada yang memutuskan untuk mewarisi dari kelas Anda dan Anda kemudian memilih fungsi dengan nama yang sama, Anda berada dalam untuk muatan kapal kebingungan. Pertama, jika Anda tidak mendeklarasikan fungsi virtual, maka obyek subclass akan memiliki fungsi yang dipilih tergantung pada jenis statis pointer. Ini bisa berantakan. Selain itu, jika Anda menyatakan hal itu virtual, maka Anda memiliki masalah yang mungkin menyediakan berbagai jenis fungsi dari yang dimaksudkan oleh pelaksanaan asli fungsi itu. Akhirnya, Anda tidak bisa menambahkan fungsi virtual murni untuk kelas yang sudah digunakan karena tidak ada yang telah mewarisi dari itu akan telah menerapkan fungsi itu.
Antarmuka publik, maka, harus tetap konstan mungkin. Bahkan, pendekatan yang baik untuk merancang kelas adalah menulis antarmuka sebelum pelaksanaan karena itulah yang menentukan seberapa kelas Anda berinteraksi dengan seluruh dunia (yang lebih penting untuk program secara keseluruhan dari bagaimana kelas yang benar-benar dilaksanakan) . Selain itu, jika Anda menulis antarmuka yang pertama, Anda bisa mendapatkan merasakan bagaimana kelas akan bekerja dengan kelas-kelas lain sebelum Anda benar-benar menyelam ke rincian pelaksanaan.
Inheritance and Class Design Isu kedua desain kelas Anda adalah apa yang harus tersedia untuk programmer yang ingin membuat subclass. Interface ini terutama ditentukan oleh fungsi virtual, tetapi Anda juga dapat menyertakan metode dilindungi yang dirancang untuk digunakan oleh kelas atau subclass-nya (ingat bahwa metode yang dilindungi terlihat untuk subclass sementara metode swasta tidak).
Pertimbangan utama adalah apakah masuk akal untuk fungsi menjadi virtual. Sebuah fungsi harus virtual saat pelaksanaannya cenderung berbeda dari subclass ke subclass. Sebaliknya, setiap kali fungsi tidak harus mengubah, maka harus dibuat non-virtual. Ide utama adalah untuk berpikir tentang apakah untuk membuat fungsi virtual dengan menanyakan apakah fungsi harus selalu sama untuk setiap kelas.
Misalnya, jika Anda memiliki kelas yang dirancang untuk memungkinkan pengguna untuk memantau lalu lintas jaringan dan Anda ingin mengizinkan subclass yang menerapkan cara yang berbeda untuk menganalisis lalu lintas, Anda mungkin menggunakan antarmuka berikut:
class TrafficWatch
{
public:
// Packet is some class that implements information about network
// packets
void addPacket (const Packet& network_packet);
int getAveragePacketSize ();
int getMaxPacket ();
virtual bool isOverloaded ();
};
Di kelas ini, beberapa metode tidak akan berubah dari implementasi pelaksanaan; menambahkan sebuah paket harus selalu ditangani dengan cara yang sama, dan rata-rata ukuran paket tidak akan berubah baik. Di sisi lain, seseorang mungkin memiliki ide yang sangat berbeda dari apa artinya memiliki jaringan kelebihan beban. Ini akan berubah dari situasi ke situasi dan kami tidak ingin mencegah seseorang dari mengubah cara ini dihitung - untuk beberapa, apa pun lebih dari 10 Mbits / sec lalu lintas mungkin jaringan kelebihan beban, dan untuk orang lain, itu akan membutuhkan 100 Mbits / sec pada beberapa kabel jaringan tertentu. Akhirnya, ketika mewarisi publik dari kelas atau merancang untuk warisan, ingat bahwa Anda harus berusaha untuk itu menjadi jelas bahwa model warisan adalah-a. Pada intinya, adalah-hubungan berarti bahwa subclass harus mampu muncul di mana saja kelas induk bisa muncul. Dari sudut pandang pengguna kelas, seharusnya tidak peduli apakah kelas adalah kelas induk atau subclass. Merancang adalah-hubungan, pastikan bahwa itu masuk akal untuk kelas untuk menyertakan fungsi-fungsi tertentu untuk memastikan bahwa itu tidak termasuk yang subclass tidak mungkin benar-benar perlu. Salah satu contoh memiliki fungsi tambahan adalah bahwa dari kelas Bird yang mengimplementasikan fungsi lalat. Masalahnya adalah bahwa tidak semua burung bisa terbang - penguin dan burung emu, misalnya. Hal ini menunjukkan bahwa pilihan desain yang lebih bijaksana mungkin untuk memiliki dua subclass burung, satu untuk burung yang bisa terbang dan satu untuk burung terbang. Tentu saja, itu mungkin berlebihan untuk memiliki dua subclass dari burung tergantung pada bagaimana kompleks hirarki kelas Anda akan. Jika Anda tahu bahwa tak seorang pun akan pernah mengharapkan menggunakan kelas Anda untuk burung terbang, maka itu tidak begitu buruk. Tentu saja, Anda tidak akan selalu tahu apa yang seseorang akan menggunakan kelas Anda untuk dan itu jauh lebih mudah untuk berpikir cermat sebelum Anda mulai menerapkan seluruh kelas hirarki daripada akan kembali dan mengubahnya sekali orang yang menggunakannya.
0 Komentar untuk "Membuat Class Design dengan C++"