using – papierek lakmusowy Twojej architektury

W Visual Studio wersji Ultimate są narzędzia do analizowania architektury. Jednak są ludzie, którzy zamiast wydawać pieniądze na ultimate-a wolą iść do salonu i kupić sobie auto albo dwa. Jak jednak poradzić sobie bez diagramu warstw? Wystarczy pooglądać usingi.

Single Responsibility Principle mówi, że klasa powinna robić jedną rzecz, mieć jedną odpowiedzialność. Jeśli ma jedną odpowiedzialność to nie powinna raczej grzebać we wszystkich warstwach. Wątpliwe jest aby klasa, która ma jedną odpowiedzialność musiała sięgać do bazy danych i interfejsu użytkownika i plików i logiki biznesowej i Bóg raczy wiedzieć gdzie jeszcze.

Zamiast czytać całą klasę (w wersji optymistycznej <50 linii a w wersji ekstremalnej >10k linii) wystarczy rzucić okiem na usingi. Te zazwyczaj mają mniej niż 15 linijek. Jeśli mamy dobrze ponazywane biblioteki  i katalogi (w solution) to po usingach poznasz co klasa potrzebuje (tu warto wspomnieć, że ReSharper Productivity Power Tools pozwalają automatycznie usuwać niepotrzebne usingi). Jeśli usingów jest za dużo i ze zbyt wielu warstw to wiedz, że coś jest nie tak.