Geçenlerde basit bir dosya okuyucu ve veri dönüştürücü yazmam gerekti. "Hmm, burada kesin bir Strategy Pattern kullanmalıyım, hem de bir Factory ile üretmeliyim" diye düşündüm. Kafamda hemen sınıf diyagramları şekillendi. Sonuç? 5 farklı sınıf, bir interface, bir abstract class... ve asıl işi yapan 20 satırlık mantık, bu kalıpların arasında kaybolup gitti. Kafayı yiyecektim, meğerse sorun şuradaymış: problemi pattern'e uydurmaya çalışıyormuşum.
Şöyle oluyor: Bir problem görüyoruz ve beynimiz hemen "Bu bir Observer olayı!" ya da "Burası kesin Decorator ister!" diye bağırıyor. Asıl sorun şu: Acaba gerçekten o karmaşıklık seviyesinde miyiz? Yoksa sadece "bakın ben design pattern biliyorum" demek için mi kullanıyoruz? StackOverflow'da bile "Burada Singleton kullanmalısın" diye yorum yapılan, aslında basit bir global değişkenle çözülebilecek sorular gördüm. Şaka gibi ama.
Bazen o kadar pattern içinde kayboluyorsun ki, basit bir if statement'ın seni kurtarabileceğini unutuyorsun.
Java:
// Pattern çılgınlığından önce:
// if (format.equals("json")) { parseJson(); } else if (format.equals("xml")) { parseXml(); }
// Pattern çılgınlığından sonra:
// FileParserFactory factory = new FileParserFactory();
// ParserStrategy strategy = factory.getParserStrategyFor(format);
// Data data = strategy.executeParse(context);
// ... ve arka planda 6 farklı sınıf.
Artık şu kuralı koydum kendime: Önce problemi çöz. Çalışan, okunabilir bir kod yaz. Sonra bak: Bu kodda değişmesi muhtemel, sık sık genişletmem gereken bir şey var mı? Eğer cevap evetse ve kod gerçekten karışmaya başladıysa, o zaman uygun pattern'i araştır. Pattern'ler, ortaya çıkmış sorunlar için birer dokümantasyon ve iletişim aracı aslında. "Bak burada bir Observer kullanmışım" demek, iki sayfa açıklama yapmaktan daha etkili.
Siz de böyle "pattern için pattern kullandığım" anlar oldu mu? Ya da "keşke hiç pattern kullanmasaydım, daha sade olsaydı" dediğiniz projeler? Bunun dengesini nasıl kuruyorsunuz?