Dependency Inversion Principle – czyli co powinno zależeć od czego

Po Single Responsiblity Principle najważniejsza (moim zdaniem) zasada programowania obiektowego – Dependency Inversion Principle. Mówi ona, że obiekty powinny być zależne od abstrakcji a nie od konkretnej klasy. A po ludzku, w żadnej definicji funkcji i w żadnej deklaracji zmiennej nie powinniśmy używać nazwy klasy. Zamiast tego powinniśmy używać interfejsy albo klasy abstrakcyjne czyli zamiast

[csharp]
private Person _owner;

public bool ValidateOwner(Person personToValidate)
{
//…..
}
[/csharp]

piszemy

[csharp]

private IPerson _owner;

public bool ValidateOwner(IPerson personToValidate)
{

//…..

}

[/csharp]

Co to daje? Ano daje to możliwość podmieniania poszczególnych elementów programu. Powyższy przykład nie jest zależny już od klasy Person a od interfejsu IPerson. To jaki obiekt będziemy validować, nas zupełnie nie obchodzi. Ważne, żeby implementował nasz interfejs.

Co więcej, powyższe podejście pozwala na łatwe wyciągnięcie jakiejś klasy do osobnej biblioteki i użycie jej w innym projekcie. Jeżeli nie stosowalibyśmy Dependency Inversion Principle, wówczas wyciągnięcie klasy do zewnętrznej biblioteki wymagało by wyciągnięcia również wszystkich użytych przez nas klas albo byli byśmy zmuszeni ciągnąć za sobą masę referencji. DIP ułatwia wyciągnięcie klasy i interfejsów, które nas interesują. Zazwyczaj już nie potrzebujemy żadnych dodatkowych referencji.

Pamiętając, że chcemy pracować wydajniej i lepiej to czy nie było by pięknie, gdyby jakąkolwiek funkcjonalność, logikę biznesową czy algorytm pisalibyśmy tylko raz? Jak wydajna byłaby organizacja gdyby każdy taki pojedynczy klocek powstawał tylko i wyłącznie raz? Okazuje się, że bardzo. Okazuje się, że tak pracujące zespoły mogą bardzo szybko i co najważniejsze niskim kosztem potrafią w szybkim tempie dostarczyć nowe wersje czy nawet nowe produkty w mgnieniu oka. Elastyczna architektura pozwala na taką pracę. To co daje .net pozwala z jednego kodu bazowego zrobić usługę w WCF-ie, aplikację konsolową, bardzo bogatą graficznie aplikację w WPF-ie, albo klasyczną Formsową, można szybko dostarczyć stronę www w MVC, aplikację na telefon (WP7) czy nawet w formie gry na XBox-a. To wszystko jest możliwe z jednego kodu bazowego przy odpowiedniej architekturze. .NET nie jest tutaj wyjątkiem. Podobne możliwości daje prawie każdy nowoczesny język programowania. W Javie mamy możliwość tworzenia apletów na strony www, aplikacji również graficznie bogatych, usługi, telefony, telewizory i wiele innych.