Piotr Zieliński na swoim blogu rozważał zasadność redefiniowania przez klasy dziedziczące metod z klas dziedziczonych (przy pomocy modyfikatora new), warto zapoznać się z tym wpisem przed kontynuowaniem lektury niniejszego tekstu. Na zakończenie Piotr poprosił o podanie innych, od przestawionych przez niego, powodów, na zasadność użycia modyfikatora new. Oto jeden z nich...

W obecnym czasie, z bardzo rozwiniętymi środowiskami programistycznymi, takimi jak choćby Visual Studio, czy też Eclipse, bardzo łatwo jest rozpocząć swoją przygodę z programowaniem, które w tym przypadku czasem bardziej przypomina zabawę z klockami, niż rzeczywiste . Jednak nastawiając się na bezmyślne składanie klocków, szybko można obudzić się z przysłowiową , w sytuacji gdy zajdzie potrzeba modyfikacji lub rozszerzenia tak radośnie tworzonego kodu, a warto zaznaczyć, że nieumiejętnie sklejony kod mo...

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.

W wielu publikacjach service locator podawany jest jako wzorzec projektowy, doskonale nadający się do implementacji inversion of control. W poście jednak chciałbym przedstawić drugą szkołę, która uważa, że ten wzorzec jest “brzydki” i powoduje ogromne zamieszanie. Przede wszystkim odpowiedzmy sobie kiedy używamy podejścia IoC? W aplikacjach tymczasowych? Prototypach? Raczej nie… Początkowy czas na napisanie aplikacji IoC może okazać się dłuższy a korzyści nadchodzą dopiero po kilku miesiącach implementa...

Sprostowanie nieścisłości dotyczącej pojęcia polimorfizmu, która pojawiła się w kursie C# na portalu virtualstudy.pl

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 private IPerson _owner; public bool ValidateOwner(IPerson personToValidate) { //..... } piszemy private IPe...

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 nie. Jeżeli chcesz w klasie tworzyć obiekty to to już jest odpowiedzialność. Wiec klasa nic poza tworz...

Dzisiaj pokażę, jak od strony programistycznej wygląda AppDomain. Zwykle tworzymy aplikację host, która trzyma referencje do kilku AppDomain. Stwórzmy najpierw aplikację konsolową wyświetlającą po prostu tekst:namespace ConsoleApplication3 { class Program { staticvoid Main(string[] args) { while (true) { Console.WriteLine(AppDomain.CurrentDomain.FriendlyName); System.Threading.Thread.Sleep(2000); } } }...

Ilu z nas wracając do starego kodu (napisanego wczoraj/ tydzień temu/ miesiąc temu) krzywi się patrząc na bałagan, który po sobie pozostawił? W zasadzie prościej będzie chyba zapytać komu się to nie zdarza. Otóż amerykańscy naukowcy znaleźli na to sposób. No dobra może nie amerykańscy, ale skrót jest z angielskiego - SOLID, rozkłada się on na pięć czynników, a każdy z nich jest znowu jakimś skrótem.

O liczbach losowych Napiszmy prosty program, który rzuca 10 razy kostką. class Program { static void Main(string[] args) { for (int i = 0; i < 10;="" i++)="" console.writeline(gen.next(6)="" +="" 1);="" }="" }="" teraz="" program="" już="" działa="" zgodnie="" z="" oczekiwaniami.="" widzimy,="" że="" zmiana="" polegała="" na="" tym,="" że="" teraz="" mamy="" jeden="" generator,="" generujący="" kolejne="" liczby.="" w="" czym="" kilka="" generatorów="" jest="" ...