Apakah ada pola desain yang mungkin untuk program berorientasi objek? Saya bertanya ini karena baru-baru ini saya melihat implementasi Doorkelas dengan a Lock. Itu adalah bagian dari tes dan jawabannya mengatakan bahwa kode mengikuti pola Objek Null:

class Lock
{
public:
    virtual void close() = 0;
    virtual void open() = 0;
    virtual bool is_open() const = 0;
    virtual ~Lock() { }
};

class DummyLock
    : public Lock
{
private:
    DummyLock();
    DummyLock(const DummyLock&) = delete;
    DummyLock& operator=(const DummyLock&) = delete;

private:
    void close() { }
    void open() { }
    bool is_open() const { return true; }

public:
    static DummyLock m_instance;
};

class Door
{
public:
    Door() : m_lock(DummyLock::m_instance) { }
    Door(Lock &lock) : m_lock(lock) { }

public:
    Lock& get_lock() const { return m_lock; }

private:
    Lock &m_lock;
};

Ini membuat saya berpikir: Kode ini mengikuti pola desain yang baik meskipun deskripsinya sangat sederhana (kelas ini merancang kelas pintu dengan kunci), jadi jika saya menulis kode yang lebih kompleks, harus selalu ada beberapa pola desain yang saya miliki. mengikuti?

harus selalu ada pola desain yang saya ikuti?

Ya Tuhan, TIDAK!

Maksud saya, Anda dapat melanjutkan dan mengatakan bahwa kode acak apa pun mengikuti beberapa pola XYZ acak, tetapi itu tidak lebih berguna daripada saya yang mengklaim sebagai raja dari kursi komputer saya. Tidak ada orang lain yang benar-benar tahu apa artinya itu dan bahkan mereka yang melakukannya tidak akan menghargai klaim saya.

Pola desain adalah alat komunikasi sehingga pemrogram dapat memberi tahu programmer lain apa yang telah dilakukan atau apa yang harus dilakukan tanpa menghabiskan banyak waktu mengulangi sendiri. Dan karena mereka adalah hal-hal yang muncul beberapa kali, mereka adalah konsep yang berguna bagi pemrogram untuk belajar "hei, membuat XYZ sepertinya selalu muncul karena itu baik / berguna".

Mereka tidak menggantikan kebutuhan Anda untuk berpikir sendiri, untuk menyesuaikan pola untuk masalah unik di depan Anda, atau untuk menangani semua hal yang tak terhindarkan yang tidak cocok dengan ember bagus.

Tidak.

Inilah yang dikatakan oleh Gang of Four (yang awalnya mempopulerkan pola desain) dalam buku mereka :

"Tidak ada diskusi tentang bagaimana menggunakan pola desain akan lengkap tanpa beberapa kata tentang bagaimana tidak menggunakannya. Pola desain tidak boleh diterapkan tanpa pandang bulu. Seringkali mereka mencapai fleksibilitas dan variabilitas dengan memperkenalkan tingkat tipuan tambahan, dan yang dapat menyulitkan desain dan / atau biaya kinerja Anda. Pola desain hanya boleh diterapkan ketika fleksibilitas itu benar-benar diperlukan. "

Contoh yang Anda perlihatkan sebenarnya tidak melakukan banyak hal (Saya pikir itu tidak dimaksudkan, saya pikir itu hanya dimaksudkan sebagai contoh). Dengan sendirinya, tidak perlu pola objek nol. Dalam konteks program yang lebih besar, mungkin.

Pendekatan yang salah adalah mengasumsikan bahwa hanya karena telah diberi label "pola desain" itu harus baik, dan kemudian mencari lebih banyak tempat untuk menjejalkan lebih banyak pola. Gunakan mereka ketika mereka cocok dengan program dan benar-benar memecahkan masalah untuk Anda.

jika saya menulis kode yang lebih kompleks, haruskah selalu ada pola desain yang saya ikuti?

Tidak. Pola desain hanya itu: pola dalam hubungan antar objek. Dengan kata lain, hubungan yang cukup sering digunakan dan digunakan kembali sehingga seseorang berkata, "Hei, sepertinya kita sering melakukan ini, mari kita beri nama." Daftar pola desain tidak ditentukan sekaligus di awal OOP dan kemudian diserahkan oleh GOF ! Mereka ditemukan dan akhirnya didokumentasikan, dan kemudian dipopulerkan oleh buku itu.

Yang mengatakan, sebagian besar manfaat dari pola desain adalah mereka membuatnya lebih mudah untuk berpikir tentang desain perangkat lunak pada tingkat yang lebih tinggi. Mereka membiarkan Anda melewatkan kekhawatiran tentang detail implementasi dan berpikir lebih banyak tentang gambaran besar. Dalam hal itu mereka membebaskan Anda dari hal-hal kecil, tetapi mereka juga dapat membatasi Anda dengan cara yang sama sehingga cara Anda mengekspresikan diri dapat dibatasi oleh kata-kata yang Anda ketahui. Jadi, mungkin ada datang suatu waktu ketika ada adalah pola desain untuk sebagian besar dari apa yang Anda lakukan hanya karena pola yang Anda tahu adalah istilah di mana Anda berpikir. Buka mata Anda untuk kasus-kasus di mana Anda mungkin menyalahgunakan suatu pola, dan di mana Anda mungkin perlu berpikir lebih dalam tentang cara-cara yang lebih baik untuk melakukan sesuatu.

Juga, sadari bahwa dalam praktiknya Anda sering tidak menerapkan pola desain tertentu seperti mengenali pola dalam beberapa kode yang ada, seperti kerangka kerja objek. Mengetahui tentang pola desain umum membuatnya lebih mudah untuk mempelajari bagaimana kerangka kerja dimaksudkan untuk digunakan karena Anda dapat melihat hubungan antar kelas dalam istilah yang sudah Anda pahami.

Pola desain memiliki dua keunggulan

1. Mereka mudah dideskripsikan kepada pengembang lain, karena orang umumnya sepakat tentang apa polanya
2. Mereka cenderung telah dipukuli dengan cukup serius oleh para pendahulu kita, sehingga kekuatan dan kelemahan mereka dipahami dengan baik.

Sasaran dari setiap program seharusnya

1. Berhasil. Itu harus melakukan apa pun tujuan akhirnya, atau tidak peduli berapa banyak pola desain yang Anda gunakan. Pola desain OO membuatnya mudah untuk memecahkan masalah menjadi bit yang mudah dipahami sehingga lebih mudah untuk membuktikannya bekerja.
2. Mudah dibaca. Di sinilah pola desain bagus. Masalah OO yang mereka selesaikan rumit. Jika Anda menyelesaikannya dengan cara "standar", lebih mudah bagi pengembang berikutnya
3. Mudah tumbuh. Hampir 0 program modern selesai di mana semua orang merencanakannya. Setiap program tumbuh setelah rilis awal. Pola OO dikenal sangat baik dalam pertumbuhan.

Itu semua dikatakan, perhatikan bahwa setiap referensi ke pola desain OO adalah "mereka hanya baik dalam pekerjaan." Mereka tidak sempurna, tetapi mereka mengisi ceruk dengan sangat efektif. Gunakan mereka ketika mereka bekerja, hindari ketika mereka tidak.

Sebagai contoh, "kode kompleks," seperti yang Anda sebutkan dalam pertanyaan, ambil bahasa scripting yang saya tulis. Sebagian besar adalah OO dengan pola desain di mana-mana. Namun, ketika harus menulis tentang pengumpul sampah, saya secara tidak sengaja membatalkan semua kepura-puraan OO, karena hal-hal khusus yang perlu saya lakukan lebih baik dimodelkan sebagai pemukulan bit yang baik. Tidak ada pola OO di seluruh hal sampai sampai menulis finalizers, di mana sekali lagi OO mulai menjadi model yang berguna lagi. Tanpa kemegahan atau keadaan apa pun, kode tiba-tiba berubah kembali menggunakan teknik OO lagi.

Gunakan pola desain setiap kali mereka membuat produk Anda lebih baik; hindari ketika mereka membuat produk Anda lebih buruk.

Saya akan sedikit melawan tren, karena jawabannya lebih halus daripada jawaban lain. Setiap kelas yang Anda tulis tidak boleh menggunakan pola desain, tetapi sebagian besar program non-sepele yang Anda tulis seharusnya.

Program non-sepele tanpa pola desain menunjukkan:

• Program Anda sangat unik sehingga tidak ada bagian yang mirip dengan masalah umum yang dihadapi pemrogram sebelumnya. Atau
• Program Anda mengandung masalah-masalah umum tersebut, tetapi Anda telah memecahkannya dengan cara yang lebih baik yang tidak pernah dipikirkan oleh siapa pun sebelumnya.

Kedua skenario sangat tidak mungkin, tidak ada pelanggaran.

Itu tidak berarti bahwa pola desain harus mendorong desain Anda, atau Anda harus memasukkannya secara membabi buta karena Anda pikir itu akan terlihat buruk jika tidak. Pola desain yang salah lebih buruk daripada tidak sama sekali.

Maksudnya adalah Anda harus melihat kurangnya pola desain dalam keseluruhan program Anda sebagai bau kode. Sesuatu yang membuat Anda melihat kembali dan mengevaluasi kembali jika desain Anda tidak bisa lebih bersih. Jika pada saat itu Anda memutuskan untuk meninggalkan pola desain dari suatu program, itu harus menjadi keputusan yang disengaja dan diinformasikan, bukan kebetulan.

Misalnya, Anda tidak mengatakan, "Saya perlu memodelkan pintu dan kunci, pola desain apa yang harus saya gunakan?" Namun, jika Anda mendesainnya terlebih dahulu tanpa menggunakan pola desain apa pun, itu akan meminta Anda sesudahnya untuk mengatakan sesuatu seperti, "Saya memiliki banyak sekali pemeriksaan nol dalam kode ini, saya bertanya-tanya apakah ada pola desain yang dapat membantu mengaturnya."

Lihat perbedaannya? Ini perbedaan yang halus tapi penting.

Pertanyaan rusak Biarkan saya memberi Anda definisi baru dari pola desain yang akan membatalkan banyak kerusakan yang dikeluarkan oleh GoF: pola desain adalah praktik pengkodean yang baik . Itu dia.

Setiap modul yang cukup kompleks akan memiliki beberapa pola desain di dalamnya. Setiap kali Anda me-cache itu mungkin pola terbang-kelas tetapi saya tidak akan mencabut derajat pemrograman Anda jika Anda tidak menyebutnya begitu. Setiap kali Anda memiliki panggilan balik di dalamnya, Anda berada dalam semacam pola kejadian / kebakaran / panggilan balik. dll. Jika Anda memiliki kata "statis", Anda memiliki singleton. Jika Anda memiliki konstruktor statis, Anda memiliki pola pabrik. Jika sumber daya diteruskan ke modul Anda, Anda menggunakan injeksi dependensi.

"Pola desain" adalah istilah rusak yang dipopulerkan oleh GoF, yang membuatnya terdengar seperti semua pola berada pada level yang sama atau Anda harus menggunakan dokter yang direkomendasikan 3 hingga 5 per kelas. Setiap kali Anda melakukan sesuatu dengan benar yang orang lain lakukan dengan benar, itu adalah pola desain . A for(;;)adalah pola umum yang digunakan untuk mewakili loop infinite, misalnya.

Anda tidak harus mencoba mempelajari banyak pola desain. Pengetahuan pemrograman tidak diindeks oleh pola desain! Sebaliknya, Anda harus belajar cara menulis kode yang baik dengan membaca buku, blog, dan menghadiri konferensi di bidang Anda. Misalnya, jika Anda sudah menggunakan injeksi dependensi tetapi belum memberinya label, Anda mungkin mendapat manfaat dengan selalu menggunakan DI atau menggunakan kerangka kerja IoC. Atau jika Anda kesulitan untuk mengkodekan langsung dalam acara dan panggilan balik, pelajari Haskell agar Anda terbiasa dengan pola desain fungsional dan itu menjadi mudah.

Dan jika seluruh kelas Anda membaca sebagai satu hal besar yang dilakukan orang lain dengan benar, mengapa Anda menciptakan kembali kemudi? Gunakan saja barang-barang mereka.

Anda harus selalu mengikuti prinsip-prinsip desain OO (misalnya, modularitas, penyembunyian informasi, kohesi tinggi, dll.). Pola desain adalah ceruk yang relatif disempurnakan dari prinsip-prinsip desain OO, terutama jika Anda mempertimbangkan prinsip KISS .

Pola adalah solusi untuk masalah desain umum. Masalah-masalah ini datang dari salah satu dari dua tempat (atau gabungan dari keduanya): ruang masalah (misalnya, perangkat lunak untuk mengelola Sumber Daya Manusia di suatu perusahaan) dan ruang solusi . Program OO adalah sebuah contoh dalam ruang solusi (misalnya, salah satu dari banyak cara Anda dapat merancang program OO untuk memfasilitasi pengelolaan SDM).

Tidak mudah untuk mengetahui kapan harus menggunakan suatu pola. Beberapa pola tingkat rendah, lebih dekat ke pengkodean dan ruang solusi (misalnya, Singleton, objek Null, Iterator). Lainnya termotivasi oleh persyaratan dalam ruang masalah (misalnya, pola Perintah untuk mendukung undo / redo, Strategi untuk mendukung beberapa jenis file input / output).

Banyak pola datang dari kebutuhan untuk mendukung variasi perangkat lunak di masa depan. Jika Anda tidak perlu membuat variasi-variasi itu, sebuah pola bisa jadi desain berlebihan. Contohnya akan menggunakan pola Adaptor untuk bekerja dengan database SDM eksternal yang ada. Anda memutuskan untuk menggunakan Adaptor karena basis data saat ini bekerja dengan Oracle dan Anda mungkin ingin mendukung NoSQL di masa depan. Jika NoSQL tidak pernah datang ke organisasi Anda, kode Adaptor itu bisa sangat berguna. Lihat YAGNI . Dukungan untuk variasi yang tidak pernah datang adalah menyalahgunakan pola desain.

Pola adalah solusi umum untuk masalah umum. Kami selalu mengikuti beberapa pola, pola oleh GoF mengatasi yang paling berulang. Itu, untuk memiliki pemahaman bersama dan pendekatan bersama yang dikenal oleh para insinyur perangkat lunak.

Yang mengatakan, jawaban saya adalah tidak, tetapi ya Anda selalu mengikuti beberapa pola Anda sendiri. Seperti yang secara tepat dikatakan oleh GoF

Pola seseorang adalah blok pembangun primitif orang lain.

Kutipan yang bagus.

Ketika saya menulis kode, saya tidak berencana untuk sengaja menggunakan sebanyak mungkin pola desain. Tapi, saya kira, secara tidak sadar, ketika saya mendapatkan masalah pengkodean, salah satu pola desain sepertinya cocok, dan saya hanya menggunakannya. Dan terkadang tidak ada yang cocok. Yang lebih penting bagi saya adalah menulis kode yang melakukan pekerjaan dan mudah untuk mempertahankan dan tumbuh.

Berikut ini adalah artikel tentang penerapan prinsip OOD menggunakan pola desain, dan memiliki contoh kode juga (dalam C ++). Ini menunjukkan bagaimana dan kapan menerapkan beberapa pola desain untuk menulis kode bersih.