czyli z komputerem przez życie
Hmm… nie wiedziałem że mam w domu statystyka…
Posted in Ciekawostki, coś na weekend, Wideo.
– 19 maja, 2012
Sporo czasu poświęciłem na elektronikę i mimo tego, że nie byłem i nie jestem przesadnie pedantyczny to tranzystory i rezystory zawsze miałem uporządkowane w klasterach z posklejanych pudełek po zapałkach lub woreczkach strunowych. Takie postępowanie powodowało, że zawsze wiedziałem gdzie szukać tego jednego rezystora, który właśnie potrzebowałem. Takie segregowanie nie ma znaczenia przy 10-20-50 elementach, można to jeszcze ogarnąć jednak przy 100 i więcej zaczyna być problemem. Dokładnie to samo dzieje się z klasami. Wraz ze wzrostem ilości klas rośnie potrzeba segregowania ich i dlatego klasy segreguje się w namespaceach, katalogach, bibliotekach etc. Common Closure Principle mówi, że klasy w ramach jednego assembly (lub jednostki publikacji czyli dll) powinny posiadać wspólne zamknięcie (closure) – wspólny sensowny obszar. Rozumiem to tak, że wszystkie klasy dzielące wspólną dziedzinę powinny znaleźć się w tej same bibliotece. Zasada ta ma głęboki sens. Bo przecież nie jest zbyt wygodne, że aby użyć jakiegoś zewnętrznego elementu (np. kontrolki) należy dodać dziesiąt różnych referencji. Najwygodniej było by gdyby należało by dodać jedną referencję. Z drugiej strony wprowadzając zmiany w jakiejś części systemu nie jest dobre jeśli musimy przegrzebać 3/4 budowanej aplikacji i wprowadzić zmiany w każdej jednej bibliotece. W przeciwnym wypadku zmiana jakiegoś założenia biznesowego spowoduje zmiany w np. 20 bibliotekach, a projekty wykorzystujące takie cudo… no cóż, również wymagają zmiany wszystkich 20 referencji. Więc dla własnej wygody i komfortu konsumentów naszych bibliotek warto pomyśleć przy porządkowaniu klas a należy pamiętać, że SOLID a w szczególności S czyli Single Responsibility Principle generuje dużo więcej klas niż to zwykle bywa przy kodowaniu nie SOLIDnym.
Posted in podstawy programowania, programowanie.
– 16 maja, 2012
W poprzednich częściach przeszliśmy przez zasady SOLID.
S – Single Responsibility Principle (oraz cz. 2)
O – Open Close Principle (oraz cz. 2)
L – Liskov Substitution Principle
I – Inversion Segregation Principle
D – Dependency Inversion Principle
Słowo SOLID bardzo dobrze odzwierciedla to, do czego te zasady prowadzą czyli do budowania solidnego kodu. Przez solidny kod rozumiem taki, który jest łatwy w modyfikacji i który szybko można dostosować do zmieniających się wymagań. Nie są to jednak wszystkie zasady programowania obiektowego, które warto znać i stosować.
Na tapetę bierzemy zatem Reuse Release Equivalence Principle czyli zasadę, która mówi, że kod, który chcemy ponownie wykorzystać, powinien być w paczce, czarnej skrzynce, która jest dostarczalnym modułem czyli po ludzku biblioteką czy też assembly (w .necie).
A jeszcze bardziej po ludzku, zasada ta mówi po prostu, że ponownie użycie kodu to nie jest skopiowanie klasy z jednego projektu do drugiego. Jeżeli chcemy użyć ponownie raz napisany kod to należy go wydzielić do biblioteki czy modułu, który później możemy użyć ponownie.
Takie podejście powoduje, że gdy autor oryginalnego kodu wprowadzi zmianę – w szczególności poprawi jakiś błąd – wówczas możemy łatwo korzystać z dobrodziejstw takich zmian pobierając nową wersję biblioteki. W zespołach korzystających z automatyzacji (Continious Integration/Delivery) nawet nic nie trzeba robić – build server zrobi za nas wszystko.
To co powyżej napisałem może wydawać się oczywistą oczywistością jednak niestety nie jest. Jest wielu programistów (serio!), którzy “ponowne użycie kodu” rozumieją jako kopiowanie z jednego pliku do innego pliku. Dzięki czemu odcinają się od jakiejkolwiek możliwości rozsądnej aktualizacji kodu poza spisaniem na kartce wszystkich takich kopii i regularnie przeglądanie repozytorium w poszukiwaniu zmian – POWODZENIA
Zasada ta ma szczególne znaczenie w grupach, gdzie pracuje więcej niż jedna osoba lub gdy jedna osoba pracuje nad więcej niż jednym projektem – czyli praktycznie zawsze.
Jedyne ewentualne odstępstwo od tej zasady jakie widzę, to kopiowanie kodu, który jest podobny jednak logicznie posiadający inny kontekst.
Aby korzystać z dobrodziejstw zasady Reuse Release Equivalence Principle dobrze stosować się do wcześniejszych – tych z SOLID-a bo wyobraź sobie, że w metodzie CalculateInvoiceValue nagle ktoś zmieni obliczanie faktury na obliczanie różnicy pomiędzy dwiema datami.
Posted in podstawy programowania, programowanie.
– 15 maja, 2012
Na weekend małe wideo. „Zwierzęta” z rurek 
Posted in Ciekawostki, Wideo.
– 12 maja, 2012
Bardzo lubię konstrukcję enum. Dzięki niej i wsparciu IDE mogę bardzo łatwo zautomatyzować sobie pracę.
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;
...
}
}
}
Po dodaniu nowej wartości w SomeEnum wystarczy tylko…. poprawić wszystkie kawałki kodu, które wykorzystują SomeEnum – w głównej mierze trzeba przeglądnąć wszystkie switche i kaskady ifów. Zamiast stosować Open Close Principle i np. wzorzec Visitor z każdym kolejnym dodaniem do enuma miałem sporo pracy. Teraz coraz częściej dochodzę do wniosku, że enum mógł by nie istnieć. Wiele złego kodu by nie powstało. Czasem enum jest dobry jak w przypadku ustawiania klas do szyfrowania czy określania dostępu w FileStreamie ale pisząc kod częściej lepiej unikać ich niż z nich korzystać.
Posted in podstawy programowania, programowanie.
– 10 maja, 2012
