Blog

Bardzo często w tytułach książek dla programistów można znaleźć określenia typu: „piękny kod”, „czysty kod”, „kod doskonały”, sugerujące, że możliwe jest napisanie programu, którego kod źródłowy jest po prostu idealny. Ale co właściwie znaczy to, że określony fragment, a być może nawet cała aplikacja, ma doskonały kod źródłowy?

Programowanie, wbrew obiegowym opiniom, nie jest aż takie trudne. Wypuszczenie nawet prostych aplikacji mobilnych czy stron nie wymaga dzisiaj dużych nakładów sił. Największym problemem jest napisanie takiego kodu, który będzie łatwo rozszerzalny i będzie miał dla nas sens nawet wtedy, gdy spojrzymy na niego za kilka lat.

„Object reference not set to an instance of an object” — taki, pojawiający się w najmniej oczekiwanym momencie komunikat to zmora każdego programisty C#. Przyczyna jest zawsze taka sama, a jest nią wyjątek NullReferenceException.

Przyszła pora na ostatnią literkę z mnemonika SOLID, ale to wcale nie oznacza, że jest ona najmniej ważna. D rozwijane jest jako Dependency Inversion Principle co tłumaczone jest jako Zasada Odwrócenia Zależności.

W poprzednich wpisach poświęconych SOLID, niejednokrotnie pojawiały się wzmianki o interfejsach. Osobiście jestem ich gorącym zwolennikiem, ale wszystkiego trzeba używać z głową. Tego nauczy Was życie.. i w tym przypadku właśnie czwarta zasada z mnemoniku SOLID, która opisuje zasadę segregacji interfejsów (z ang. Interface segregation principle). 

Liskov Substitution Principle to prawdopodobnie jedna z najbardziej pokręconych zasad mnemonika SOLID. Po raz pierwszy została sformułowana przez Barbarę Liskov w 1987 roku (za Wikipedią), stąd też jej nazwa. W polskim tłumaczeniu nazywamy ją zasadą podstawienia Liskov. Reguła została spopularyzowana przez Roberta C. Martina w artykule Principles of Object Oriented Design oraz książce Agile Software Development: Principles, Patterns,Czytaj więcej…

  Tworząc oprogramowanie, bardzo często stoimy przed dylematem: czy pisać kod szybko, czy porządnie. Oczywiście, o ile tylko mamy możliwość, wybierajmy tę drugą opcję, jednak taka decyzja generuje nowy problem, ponieważ na wczesnym etapie procesu wytwarzania oprogramowania trudno jest określić dokładny kierunek rozwoju.

Bardzo lubię powiedzenie „lepiej nie wymyślać koła od nowa”, ponieważ pasuje do wielu obszarów naszego codziennego życia, w tym programowania. Pisząc kod, bardzo często rozwiązujemy problemy, nad którymi ktoś już wcześniej pracował.