Komposit Desain Pola

Komposit Desain Pola

Maksud

   Menulis objek ke dalam struktur pohon untuk mewakili seluruh bagian hirarki. Komposit memungkinkan klien memperlakukan objek individu dan komposisi benda seragam.

Komposisi rekursif

"Direktori berisi entri, yang masing-masing bisa menjadi sebuah direktori."

1-ke-banyak "memiliki" up "adalah" hierarki

Masalah

Aplikasi perlu memanipulasi koleksi hirarkis "primitif" dan "komposit" benda. Pengolahan dari objek primitif ditangani salah satu cara, dan pengolahan objek komposit ditangani secara berbeda. Memiliki untuk query "jenis" dari setiap objek sebelum mencoba untuk memprosesnya tidak diinginkan.

Diskusi

   Mendefinisikan kelas dasar abstrak (Komponen) yang menentukan perilaku yang perlu dilakukan merata di semua objek primitif dan komposit. Subclass kelas primitif dan Komposit off dari kelas Komponen. Setiap objek Composite "pasangan" itu sendiri hanya untuk abstrak jenis Komponen karena berhasil "anak" nya.

Menggunakan pola ini setiap kali Anda memiliki "komposit yang mengandung komponen, yang masing-masing bisa menjadi komposit".

   Metode manajemen anak [misalnya addChild (), removeChild ()] biasanya harus didefinisikan dalam kelas Komposit. Sayangnya, keinginan untuk mengobati Primitif dan Komposit seragam mengharuskan metode ini dipindahkan ke kelas Komponen abstrak. Lihat "Pendapat" di bawah untuk diskusi tentang "keselamatan" versus masalah "transparansi".

Struktur

Komposit yang mengandung komponen, yang masing-masing bisa menjadi Composite 

   Menu yang berisi item menu, yang masing-masing bisa menjadi menu.

Baris-kolom layout GUI manajer yang mengandung widget, yang masing-masing bisa menjadi baris-kolom layout GUI manajer. 

Direktori yang berisi file, yang masing-masing bisa menjadi sebuah direktori. 

Kontainer yang berisi Elements, yang masing-masing bisa menjadi sebuah wadah.

Contoh

   Composite menyusun objek ke dalam struktur pohon dan memungkinkan klien memperlakukan objek individu dan komposisi seragam. Meskipun contoh yang abstrak, ekspresi aritmatika yang Komposit. Sebuah ekspresi aritmatika terdiri dari operan, operator (+ - * /), dan operan lain. Operan bisa menjadi nomor, atau expresssion aritmatika lain. Dengan demikian, 2 + 3 dan (2 + 3) + (4 * 6) keduanya ekspresi valid.

Periksa daftar

   Pastikan bahwa masalah Anda adalah tentang mewakili "seluruh bagian" hubungan hirarkis.

Pertimbangkan heuristik, "Kontainer yang berisi containees, yang masing-masing bisa menjadi sebuah wadah." Misalnya, "Sidang yang mengandung komponen, yang masing-masing bisa menjadi perakitan." Membagi konsep domain Anda ke dalam kelas kontainer, dan kelas containee.

Buat "common denominator terendah" antarmuka yang membuat wadah dan containees dipertukarkan. Ini harus menentukan perilaku yang perlu dilakukan secara seragam di semua containee dan wadah benda.

   Semua kelas kontainer dan containee mendeklarasikan "adalah" hubungan dengan antarmuka.

Semua kelas kontainer menyatakan satu-ke-banyak "memiliki" hubungan dengan antarmuka.

Kelas kontainer pengaruh polimorfisme untuk mendelegasikan ke objek containee mereka.

Metode manajemen anak [misalnya addChild (), removeChild ()] biasanya harus didefinisikan dalam kelas Komposit. Sayangnya, keinginan untuk mengobati Leaf dan Composite benda seragam mungkin mengharuskan metode ini dipromosikan ke kelas Komponen abstrak. Lihat Gang of Four untuk diskusi ini "aman" versus "transparansi" trade-off.

Aturan praktis

   Komposit dan dekorator memiliki diagram struktur yang mirip, mencerminkan fakta bahwa keduanya bergantung pada komposisi rekursif untuk mengatur jumlah terbuka benda.

Komposit dapat dilalui dengan Iterator. Pengunjung dapat menerapkan operasi selama Komposit. Komposit bisa menggunakan Rantai Tanggung Jawab untuk membiarkan komponen mengakses properti global melalui orang tua mereka. Hal ini juga bisa menggunakan dekorator untuk menimpa properti ini pada bagian dari komposisi. Itu bisa menggunakan Observer untuk mengikat satu struktur objek yang lain dan Negara untuk membiarkan komponen mengubah perilaku sebagai perubahan keadaan.

Komposit dapat membiarkan Anda menulis Mediator keluar dari potongan-potongan kecil melalui komposisi rekursif.

Dekorator dirancang untuk membiarkan Anda menambahkan tanggung jawab untuk objek tanpa subclassing. Fokus komposit adalah bukan pada hiasan tetapi pada representasi. Maksud ini berbeda tetapi saling melengkapi. Akibatnya, Komposit dan dekorator sering digunakan dalam konser.

Kelas terbang sering dikombinasikan dengan Composite untuk melaksanakan bersama node daun.

Pendapat

   Inti dari pola Komposit adalah bahwa Composite dapat diobati atom, seperti daun. Jika Anda ingin memberikan protokol Iterator, baik, tapi saya pikir itu adalah di luar pola itu sendiri. Di jantung dari pola ini adalah kemampuan untuk klien untuk melakukan operasi pada objek tanpa perlu tahu bahwa ada banyak benda di dalam.

   Mampu mengobati koleksi heterogen benda atom (atau transparan) mensyaratkan bahwa "manajemen anak" antarmuka didefinisikan pada akar hirarki kelas Composite (kelas Komponen abstrak). Namun, pilihan ini biaya keselamatan Anda, karena klien mungkin mencoba untuk melakukan hal-hal berarti seperti add dan menghapus objek dari objek daun. Di sisi lain, jika Anda "desain untuk keamanan", antarmuka manajemen anak ini dideklarasikan pada kelas Komposit, dan Anda kehilangan transparansi karena daun dan Komposit sekarang memiliki antarmuka yang berbeda.

   Implementasi Smalltalk dari pola Komposit biasanya tidak memiliki antarmuka untuk mengelola komponen dalam antarmuka Komponen, tetapi dalam antarmuka Composite. Implementasi C ++ cenderung meletakkannya di antarmuka Komponen. Ini adalah fakta yang sangat menarik, dan satu yang saya sering merenungkan. Saya dapat menawarkan teori untuk menjelaskannya, tapi tidak ada yang tahu pasti mengapa itu benar.

   Kelas Komponen saya tidak tahu bahwa Komposit ada. Mereka tidak memberikan bantuan untuk navigasi Komposit, maupun bantuan untuk mengubah isi dari Komposit. Hal ini karena saya ingin kelas dasar (dan semua turunannya) untuk dapat digunakan kembali dalam konteks yang tidak memerlukan Komposit. Ketika diberi pointer kelas dasar, jika saya benar-benar perlu tahu apakah atau tidak itu adalah Komposit, saya akan menggunakan dynamic_cast untuk memikirkan hal ini. Dalam kasus-kasus di mana dynamic_cast terlalu mahal, saya akan menggunakan Pengunjung.

Umum keluhan: "jika saya mendorong antarmuka Composite turun ke kelas Komposit, bagaimana aku akan menghitung (yaitu melintasi) struktur yang kompleks?" Jawaban saya adalah bahwa ketika saya memiliki perilaku yang berlaku untuk hierarki seperti yang disajikan dalam pola Composite, saya biasanya menggunakan Pengunjung, sehingga pencacahan tidak masalah - Pengunjung tahu dalam setiap kasus, apa jenis objek itu berurusan dengan. Pengunjung tidak perlu setiap objek untuk menyediakan sebuah antarmuka pencacahan.

   Komposit tidak memaksa Anda untuk memperlakukan semua komponen sebagai Komposit. Ini hanya memberitahu Anda untuk menempatkan semua operasi yang ingin Anda memperlakukan "seragam" di kelas Komponen. Jika menambah, menghapus, dan operasi serupa tidak bisa, atau tidak harus, diperlakukan secara seragam, maka jangan menempatkan mereka di kelas dasar Komponen. Ingat, dengan cara, bahwa setiap pola yang diagram struktur tidak mendefinisikan pola; itu hanya menggambarkan apa yang dalam pengalaman kami merupakan realisasi umum daripadanya. Hanya karena Composite ini diagram struktur menunjukkan operasi manajemen anak di kelas dasar Komponen tidak berarti semua implementasi dari pola harus melakukan hal yang sama.