Friday, January 29, 2016

Pola-Pola Perancangan

0 comments


POLA-POLA PERANCANGAN
>> Design Pattern

            Pola desain atau pola rancangan adalah sebuah istilah dalam rekayasa perangkat lunak yang mengacu kepada solusi umum yang dapat digunakan secara berulang kali untuk menyelesaikan masalah-masalah umum yang ditemukan dalam desain perangkat lunak. Sebuah pola desain tidak berbentuk solusi akhir yang dapat langsung diterjemahkan menjadi kode program
            Pola desain merupakan penjelasan atau templat yang menunjukkan bagaimana cara menyelesaikan sebuah masalah yang kemudian dapat digunakan di berbagai situasi yang berbeda-beda. Pola desain untuk object-oriented biasanya menunjukkan relasi dan interaksi antar kelas dan objek, tanpa menjelaskan kelas dan objek akhir yang terlibat dalam sebuah aplikasi. Algoritma biasanya tidak disebut sebagai pola desain, karena algoritma menjadi solusi masalah komputasi bukan masalah desain test.

            Design Pattern adalah suatu solusi yang umum dilakukan untuk menangani masalah perancangan software.Design Pattern yang cukup populer diperkenalkan oleh GOF(Gang Of Four). Dewanya Design diantaranya adalah Erich Gamma, Richard Helm, Ralph Johnson dan John Vlissides. Dalam penjelasan dari Gang Of Four(GoF) terdapat 23 Pattern yang di bagi menjadi 3 kelompok besar.

1.      Creation Patterns(cara Class/object di inisialisasi)
2.      Structural Patterns (Struktur/ relasi antar object/class)
3.      Behavior Patterns (Tingkah laku atau fungsi dari class/object)

Penjelasan secara singkat bagian-bagian Design Pattern :
1.      Creation Pattern, yaitu pattern yang menyangkut dengan pembuatan object.Pattern akan menangani pembuatan suatu object, daripada kita menangani pembuatan objcet
secara langsung dan mungkin akan tersebar di dalam code kita. Dengan cara ini program akan lebih fleksibel dalam memutuskan pemakaian object yang dibutuhkan.
2.      Structural Pattern. yaitu pattern yang menyangkut dengan struktur program. dimana dalam Pattern ini akan lebih konsen ke class objcet composite. akan banyak penggunaan pewarisan to menggabungkan interface dan menjelaskan cara untuk menggabungkan object tujuan membuat fungsionalitas baru.
3.      Behavioural Pattern. yaitu pattern yang menyangkut tentang kelakuan program. Dimana pada pattern ini akan menjelaskan spesifik tentang komunikasi antar objcet.
Dari ketiga kelompok besar design pattern tersebut memiliki bagian2 seperti berikut

    >>Structural Pattern
1.      Bridge Desain Pola Maksud Memisahkan suatu abstraksi dari pelaksanaannya sehingga dua dapat bervariasi secara independen. Publikasikan antarmuka dalam hirarki warisan, dan mengubur implementasi dalam hirarki warisan sendiri.Luar enkapsulasi, untuk isolasiMasalah "Pengerasan arteri software" telah terjadi dengan menggunakan subclassing dari kelas dasar abstrak untuk menyediakan implementasi alternatif. Ini terkunci pada mengikat antara interface dan implementasi saat kompilasi. Abstraksi dan implementasi tidak dapat mandiri diperpanjang atau terdiri.
Pertimbangkan domain dari "benang penjadwalan".

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguu5dJ22sTEazC-pgJVoG1VPnkiNYWQ0Q2kpAkkxlnMZy_fmEz0NkApJNdeuDPW_lC4u27iHkrgwwW0ZiWqJJtOh66zMDTOQh8LNWuCvcg1wO6xjw4cZDpc0maGtyfQBL3ZCwWdSnjHKu7/s400/b1.jpg

Ada dua jenis benang penjadwal, dan dua jenis sistem operasi atau "platform". Mengingat pendekatan ini untuk spesialisasi, kita harus mendefinisikan kelas untuk setiap permutasi dari dua dimensi tersebut. Jika kita menambahkan platform baru (katakanlah ... Jawa Virtual Machine), apa yang akan hirarki kami terlihat seperti?
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYFK1DvQZ-TEZwv9sfj-PLPOVD4e8KSrmlD0RQK0M5uzTXlWZe85o8Cwmk-WnwrRI1RpcxdRQHzomkgU-mxLYNyVzGEaVQk3Y7m4NBmEDyQtf6oMIJ_yQFy7saCHQi_N7d6vCJUmUHLn3f/s400/b2.jpg
Bagaimana jika kita memiliki tiga jenis benang penjadwal, dan empat jenis platform? Bagaimana jika kita memiliki lima jenis benang penjadwal, dan sepuluh jenis platform? Jumlah kelas kita harus mendefinisikan adalah produk dari jumlah skema penjadwalan dan jumlah platform.
            Pola desain Bridge mengusulkan refactoring hirarki warisan eksponensial peledak ini menjadi dua hirarki orthogonal - satu untuk abstraksi platform-independen, dan yang lainnya untuk implementasi tergantung platform.

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEia1VQtp72Ehl1cIUwHlSxr9bqEiYgYmq4cBk0Go_MUEQ3FdxtGczjbqsZKdceVWWq4Qr2GgQzLAwt1P0MFIHSD-7v94P5mypRbzkneAg7MrVBMgHAU9oBkUKk85tacCREac4rR4H7uDIyF/s400/b3.jpg


            Terurai interface dan implementasi komponen ke dalam hierarki kelas orthogonal. Kelas antarmuka berisi pointer ke kelas implementasi abstrak. Pointer ini diinisialisasi dengan sebuah instance dari kelas implementasi konkret, tetapi semua interaksi berikutnya dari kelas antarmuka ke kelas implementasi terbatas pada abstraksi dipertahankan di kelas dasar pelaksanaan. Klien berinteraksi dengan kelas antarmuka, dan pada gilirannya "delegasi" semua permintaan untuk kelas implementasi.
            Objek antarmuka adalah "pegangan" yang dikenal dan digunakan oleh klien; sedangkan objek pelaksanaan, atau "tubuh", yang aman dikemas untuk memastikan bahwa hal itu mungkin terus berkembang, atau seluruhnya diganti (atau bersama saat run-time.
Menggunakan pola Bridge ketika:
Anda ingin run-time mengikat pelaksanaan, Anda memiliki proliferasi kelas yang dihasilkan dari antarmuka ditambah dan banyak implementasi, Anda ingin berbagi sebuah implementasi antara beberapa objek, Anda perlu untuk memetakan hierarki kelas orthogonal.
Konsekuensi meliputi:
decoupling antarmuka objek, ditingkatkan diperpanjang (Anda dapat memperpanjang (yaitu subclass) abstraksi dan implementasi hirarki independen), menyembunyikan rincian dari klien. Bridge adalah sinonim untuk "menangani / body" idiom. Ini adalah mekanisme desain yang merangkum kelas implementasi dalam kelas antarmuka. Yang pertama adalah tubuh, dan yang terakhir adalah pegangan. Pegangan tersebut dilihat oleh pengguna sebagai kelas yang sebenarnya, tetapi pekerjaan dilakukan di dalam tubuh. "Pegangan / body kelas idiom dapat digunakan untuk menguraikan abstraksi kompleks menjadi lebih kecil, kelas lebih mudah dikelola. Idiom dapat mencerminkan pembagian sumber daya tunggal dengan beberapa kelas yang mengontrol akses ke sana (misalnya menghitung referensi).”
Struktur Klien tidak mau berurusan dengan rincian tergantung platform. Pola Bridge merangkum kompleksitas ini di belakang sebuah abstraksi "wrapper".
            Jembatan menekankan mengidentifikasi dan decoupling "antarmuka" abstraksi dari "implementasi" abstraksi.

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEib6dVvqW7ta_4LrStSZbpHQsiMh13ddmbd_doe9sVoihc8Jb5-HEnunNV5PvXvby9bMPFwbdFkT5OJbBJL61jw_DaHhKpNmZp8fSGo0nkMnapVdPi1ZGlLWBW8cy1IG9sSzZHHb2KJ2Dgf/s400/b4.jpg

Contoh
            Pola Bridge decouples abstraksi dari pelaksanaannya, sehingga dua dapat bervariasi secara independen. Sebuah switch lampu rumah tangga mengendalikan, kipas langit-langit, dll adalah contoh dari Jembatan. Tujuan dari saklar untuk menghidupkan perangkat atau menonaktifkan. Saklar yang sebenarnya dapat diimplementasikan sebagai rantai tarik, sederhana dua posisi saklar, atau berbagai switch dimmer.

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhSCCIaCPNoWOlPq7oBLrIHfcA-2ZipSN4v1_9B4COXjPjAx62Ztbrbi-6DSdULbL-_jV6RmzDyPP7m3IWUn0YXAJaqmmeOaTljteaDmbUeOKSvyFrB4yl8jjcBWLPU4utjnlZwho02FEaD/s400/b5.jpg
Periksa daftar
            Memutuskan apakah dua dimensi ortogonal ada di domain. Konsep-konsep yang independen bisa menjadi: abstraksi / platform, atau domain / infrastruktur, atau front-end / back-end, atau antarmuka / implementasi. Desain pemisahan keprihatinan: apa klien inginkan, dan apa yang platform menyediakan.
Merancang antarmuka platform yang berorientasi yang minim, perlu, dan cukup. Tujuannya adalah untuk memisahkan abstraksi dari platform. Mendefinisikan kelas turunan dari antarmuka untuk setiap platform. Buat abstraksi kelas dasar yang "memiliki" objek Platform dan delegasi platform yang berorientasi fungsi untuk itu. Menentukan spesialisasi dari kelas abstraksi jika diinginkan.

Aturan praktis
            Adapter membuat hal-hal bekerja setelah mereka dirancang; Bridge membuat mereka bekerja sebelum mereka. Jembatan dirancang muka untuk membiarkan abstraksi dan pelaksanaannya bervariasi secara independen. Adaptor dipasang untuk membuat kelas tidak berhubungan bekerja sama. Negara, Strategi, Bridge (dan untuk beberapa derajat Adapter) memiliki struktur solusi yang sama. Mereka semua elemen bagian dari "pegangan / body" idiom. Mereka berbeda dalam maksud - yaitu, mereka memecahkan masalah yang berbeda.
            Struktur Negara dan Bridge adalah identik (kecuali bahwa Bridge mengakui hirarki kelas amplop, sedangkan Negara memungkinkan hanya satu). Dua pola menggunakan struktur yang sama untuk memecahkan masalah yang berbeda: Negara memungkinkan perilaku obyek untuk mengubah bersama dengan keadaan, sementara niat Bridge adalah untuk memisahkan suatu abstraksi dari pelaksanaannya sehingga dua dapat bervariasi secara independen.
            Jika kelas antarmuka mendelegasikan penciptaan kelas pelaksanaannya (bukan menciptakan / kopling sendiri langsung), maka desain biasanya menggunakan pola Pabrik Abstrak untuk membuat objek implementasi.

read more