Design Pattern Abuse
Dalam dunia programming / pembuatan software, dikenal istilah yang namanya design pattern :
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
Secara sederhana, design pattern itu semacam template solusi yang bisa dibilang “best practice” untuk berbagai macam permasalahan design yang muncul pada saat kita membuat software. Design pattern bukan semacam silver bullet yang bisa menyelesaikan semua masalah. Design pattern ada banyak. Masing-masing pattern memberikan solusi untuk domain problem yang spesifik.
So,apakah kita harus selalu menggunakan design pattern saat membuat program? Jeff Atwood di blog nya mengambil kutipan dari buku head first design pattern yang gw kutip lagi disini :
First of all, when you design, solve things in the simplest way possible. Your goal should be simplicity, not “how can I apply a pattern to this problem.” Don’t feel like you aren’t a sophisticated developer if you don’t use a pattern to solve a problem. Other developers will appreciate and admire the simplicity of your design. That said, sometimes the best way to keep your design simple and flexible is to use a pattern.
No one ever talks about when to remove a pattern. You’d think it was blasphemy! Nah, we’re all adults here, we can take it. So when do you remove a pattern? When your system has become complex and the flexibility you planned for isn’t needed. In other words, when a simpler solution without the pattern would be better.
Design patterns are powerful, and it’s easy to see all kinds of ways they can be used in your current designs. Developers naturally love to create beautiful architectures that are ready to take on change from all directions.
Resist the temptation. If you have a practical need to support change in a design today, go ahead and employ a pattern to handle that change. However, if the reason is only hypothetical, don’t add the pattern. It’s only going to add complexity to your system, and you might never need it.
Poin yang penting dari kutipan itu adalah :
- Don’t feel like you aren’t a sophisticated developer if you don’t use a pattern to solve a problem
- if the reason is only hypothetical, don’t add the pattern. It’s only going to add complexity to your system, and you might never need it.
Design pattern adalah tipe solusi yang kompleks untuk problem yang spesifik. Kalau kira-kira permasalahan yang dihadapi tidak memerlukan implementasi dari design pattern, maka jangan memaksakan untuk memakai.
Hal ini berujung ( lagi-lagi ) pada salah satu mata kuliah yang lagi gw ambil. Kita diharuskan memakai design pattern untuk software yang dibuat. Mungkin bagus, membantu anak-anak untuk lebih memahami implementasi design pattern di permasalahan yang nyata daripada cerita tentang abstrak tentang tukang pizza.
Tapi ada implikasi buruk yang mungkin sedikit menempel di mental anak-anak : program kalau ada design patternnya berarti bagus, dan kalau gak ada berarti jelek. Jelas salah. Selesaikan permasalahan dengan solusi yang sesederhana mungkin ( tapi bukan yang paling sederhana ).
Sekali lagi, kalau design pattern tidak dibutuhkan, maka jangan memaksakan untuk menambahkannya. Hal itu hanya akan menambahkan kompleksitas yang tidak perlu. Seperti quote dari Jeff Atwood :
Don’t use fancy OOP features just because you can. Use fancy OOP features because they have specific, demonstrable benefit to the problem you’re trying to solve. [source]
Patterns, like all forms of compexity, should be avoided until they are absolutely necessary [source]
