Kod powinien robić to czego się po nim spodziewamy, tego uczy SOLID a w szczególności LSP. Również funkcje powinny robić to co mówi ich nazwa. To ułatwia pracę z kodem a jeśli nie zgadzasz się z tym to popatrzmy na taki kod: [csharp] class car { int wheels = 4; string engine; } car mybike […]
Dobrze napisany kod nie powinien wprowadzać w błąd Read More »
Bardzo lubię konstrukcję enum. Dzięki niej i wsparciu IDE mogę bardzo łatwo zautomatyzować sobie pracę. [csharp] public enum SomeEnum { Dog, Cat, Lion } public class SomeAnimals { public void Sounds(SomeAnimals animal) { switch (animal) { case SomeEnum.Cat : Console.WriteLine("Meow"); break; case SomeEnum.Dog : Console.WriteLine("Wof"); break; … } } } [/csharp] Po dodaniu nowej wartości
Klasyczne naruszenie Open Close Principle Read More »
Wyobraźmy sobie taką sytuację: jest sklep internetowy, podczas składania zamówienia system wylicza rabat – przy zamówieniach 500-1000 zł 5%, powyżej 1000 zł 10%, powyżej 5000 dodatkowo darmowa przesyłka. Brzmi znajomo? [csharp] public double CalculateDiscount(IOrder order) { if (order.Total <= 500 && order.Total > 1000) { return order.Total*0.05; } if (order.Total > 1000) { return order.Total*0.1;
Open Close Principle czyli jak zarobić ale się nie narobić. Read More »
Jestem fanem interfejsów jak to wcześniej już pisałem, zatem dzisiaj będzie temat łatwy i przyjemny o interfejsach właśnie. W sam raz na ciężki po długo weekendowy poniedziałek. Interface Segregation Principle mówi, że klient nie powinien być zmuszany do implementowania interfejsów, których nie używa. Z tego wynika, że interfejs powinien być minimalistyczny lub po prostu możliwie
Od młodego uczą nas, że każdy kwadrat jest prostokątem. Później uczymy się programować i zaczyna się tragedia. Matematycznie kwadrat jest specyficznym przypadkiem prostokąta programistycznie już nie bardzo. Metoda ustawiająca szerokość wywołana dla prostokąta powinno ustawić jego szerokość a w przypadku kwadratu? W przypadku kwadratu oczekujemy, że ustawienie szerokości ustawi również wysokość. Zobaczmy zatem taki kod:
Kwadrat jest prostokątem czyli Liskov Substitution Principle (LSP) Read More »
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
Dependency Inversion Principle – czyli co powinno zależeć od czego Read More »
Wczoraj mówiliśmy o single responsibility principle (SRP) czyli o zasadzie pojedynczej odpowiedzialności. Jest to zasada, która moim zdaniem najwięcej zmienia w dotychczasowych przyzwyczajeniach programistycznych. Na początku jest trochę męcząca ponieważ zgodnie z nią w klasie nie powinniśmy tworzyć innych obiektów. Jak to? Nie mogę używać słowa kluczowego new? Nie mogę tworzyć obiektów? No właściwie to
Single Responsibility Principle – ciąg dalszy Read More »
Wczoraj mówiliśmy o tym, że funkcja powinna wykonywać jedną rzecz. Świetnym papierkiem lakmusowym jest nazwa funkcji. Jeśli można łatwo nadać jej nazwę i nie zawiera spójników typu i, lub, albo, oraz (lub ich odpowiedników w j. angielskim ) to jesteśmy na dobrej drodze. Funkcje, które wykonują kilka czynności są wprowadzają po prostu w błąd. A
Single Responsibility Principle Read More »