You Aren't Gonna Need It - YAGNI

Giriş
You aren't gonna need it (YAGNI) kuralı geliştiricilerin kendi varsayımları üzerine fazladan kod yazmaması gerektiği hakkında. Açıklaması şöyle.

Often, in the past, before I knew that approach, I thought something like: “What could happen with my software in the future? Oh yeah, maybe this and that. Let’s implement all these things since we are working on this part anyway. That way it’s future-proof.”

What happened afterward? Right, the implemented features, based on assumptions, didn’t work as expected by the customer or user. In the end, we had to reimplement some parts of the software to fix that. And sometimes it happens that a piece of the software is not needed or used in the future, because of reasons.

Dolayısıyla genel anlamda şu sorunun cevabı da verilmiş olunuyor.

Do you just write a class, or do you already create an abstract class with one child class because you suspect more children will come in the future?

Ancak bu kurala aykırıymış gibi görünen fakat en iyi uygulama (best practice) anlamında izlenilmesi gereken gereken şeyler de var.

1. Interface ve Tek Kalıtan Sınıf
Bu durum şeklen şöyle.

Bu konuda biraz dikkatli olmak lazım. Çünkü YAGNI kuralı ile çelişmeyeceğiz diye yanlış bir şey yapıyor olabiliriz.

1.1 Interface Alt Sistemler Arasında İse
Eğer interface, iki tane alt sistem arasındaki arayüzü temsil ediyorsa, kaç tane sınıfın kalıttığının bir önemi yok. İki alt sistemin konuşması için bir kontrat olması güzel bir şey. Açıklaması şöyle.

Interfaces are a tool for defining contracts between multiple subsystems of your application; so what really matters is how your application is divided into subsystems. There should be interfaces as the front-end to encapsulated subsystems, no matter how many classes implement them.

1.2 Bir Alt Sistemin İçinde İse
Bu konuda iki farklı görüş var. İlk görüş arayüz yaratmanın gereksiz olduğu yönünde. Açıklaması şöyle. Ben genellikle bu görüşü destekliyorum ve uyguluyorum.

Unjustified usage of an interface with single implementation is plain wrong since this violates YAGNI. In my experience, this also has been pretty damaging maintenance-wise, mostly because methods implementing interface are forced to be unnecessarily public. After you gather more refactoring experience, you'll probably learn to appreciate modest charm of private and package private access modifiers allowing one to focus attention within a single class / package.

Diğer görüş ise bu yöntemin ilerideki bakım ve değişiklik isteklerini kolaylaştırdığı yönünde. Açıklaması şöyle.

Your company is following the SOLID principles and targeting an interface rather than concrete class adds zero overhead to the program. What they're doing is a very moderate amount of extra work that can pay back volumes when the assumptions that you are making end up being false...and you can never tell what assumption that's going to be. What you're recommending while slightly less work, can cost many, many, many hours of refactoring that could have just been done ahead of time by simply following basic OO design principles.

You should be learning from these guys and consider yourself lucky. Wish I worked in such an environment where solid design was a priority goal.

Eğer alt sistem aslında bir framework ise yine dikkatli olmak gerekiyor. Bakımı ve genişlemeyi kolaylaştırdığını söyleyen bir görüş şöyle

For example, the Spring framework uses this design a lot throughout its packages. One great example is the ViewResolver interface, which has a rich children hierarchy and a lot of different implementing classes; e.g. InternalResourceViewResolver and VelocityLayoutViewResolver, among others. Other examples abound (bean registry, context, etc.) in different parts of the framework.

However, please note a few important facts about Spring:

1. There are a lot of different children classes organized within a structured hierarchy.

2. It’s a framework, and it’s meant to be open for extension and closed to modification by definition.

2. Soyutlamalar

Açıklaması şöyle. Bazen öyle fazla soyutlama katmanı oluyor ki, gerçek koda erişmek bile problem oluyor. Bir projede 13 katmanlı kalıtım hiyerarşisini kırmak için çok fazla çaba göstermiştik. Bir sınıf 10 tane arayüzü gerçekleştiriyordu ve kodda bu sınıf yerine arayüz isimleri kullanılmıştı. Aynı sınıfın farklı isimlerle karşımıza çıkması inanılmaz kafa karıştırıyordu

... some traditions take abstraction to such an extreme that 95% of the source code is just wrappers and routing, making it almost impossible to find the tiny bits of actual program logic and develop any sense of what is going on.