How often in your code do you see ifs checking whether the object is not null? Often? Very often? What would happen if you didn’t have to check it out? Surely code would be easier to maintain – no ifs = no test cases. This can all be achieved using Null Object pattern.
Design patterns which I would like to present in this post are well described in the book Design Patterns. Elements of Reusable Object-Oriented Software written by The Gang of Four (Gramma, Helm, Johnson, Vlissides). In my opinion this book is must read for every developer, regardless what programming language you are using. Besides the fact that this book was written more than 20 years ago, it still contains a lot of useful details for developers of all levels. I often revisit this book to keep in touc...
Zaczynając swoją przygodę z ASP.NET MVC (oraz w ogóle z programowaniem) miałem sporo problemów z utrzymaniem porządku w moich akcjach na kontrolerach. Bardzo często pojawiało się tam mnóstwo warunków i niepotrzebnej logiki. Ten problem trzeba było sensownie rozwiązać, więc z kolegami wypracowaliśmy sobie pewną konwencję, której twardo się trzymaliśmy...
Which one of us doesn’t like to give commands? It’s the natural way to ask (in a polite way) for a specific task that needs to be completed. Therefore, it shouldn’t be surprising that the command pattern can be also easily implemented within our software, which might provide some serious benefits in terms of loose coupling the existing code.
Do you ever feel like (well, you should) these huge switch + case statements or too many ifs seem to be wrong? What if I told you, there’s one simple trick that will change your life, by getting rid of them? Ok, seriously – I have nothing against switch or if as the way of controlling the flow (I use them quite often) however, there are certain occasions at which the things could be done better. And let me show you another way to achieve the same goal which is much cleaner in terms of code readability a...
Immutability is a quite old concept that is mostly related to the functional programming, however, it’s also (maybe not so widely) used in the object oriented programming. An immutable variable/object can not be mutated, which means that once it’s been initialized it will never change it’s original value/reference (unless it’s deallocated). This approach results in some great benefits such as out of the box thread safety, yet in the OOP world, it does seem to be quite often abused or even not used at al...
Recently I’ve had this idea that came into my mind while working on the Sentry – let the users of my library (if there will be any) to configure not only the set of rules, connection strings, urls etc. but also the underlying providers that do all of the heavy lifting (e.g. the HttpClient responsible for communicating with the API). It means that as long as you’re not satisfied with the default solution, please feel free to provide your own engine that will for example talk to the database and perform a ...
CQS stands for the command query separation. There’s a chance that you may have not heard about it, but on the other hand the CQRS might ring a bell. Even though these 2 patterns have very much in common, there is a significant difference (definitely a bigger one than the additional “R” character within the CQRS acronym) in how do they apply to the architecture of our system. In this post I’ll focus on the CQS – the older brother of the CQRS – that will help you understand how to design the software that...
In one of my previous posts I’ve told about my feelings for the repository pattern. Complaining about something is one thing (please, don’t even try to tell me, that you have never seen some piece of code, that made you cry like a baby), however, if we want to (pretend to) be professionalists, it is very important to come up with some ideas in order to solve the given problem (at least partially). In this post, I’ll present to you one of my solutions to the commonly misused repository pattern.
Many of the programmers falls into the trap of creating too many unnecessary abstractions in code, that may introduce even more chaos and maintenance issues, instead of simplifying overall project structure and providing some real benefit. One of such abstractions, that have been discussed countless number of times, is the (one and only) repository pattern.
Today I want to introduce a Circuit Breaker – one of the reactive design patterns, especially useful in areas such as web services interop. They main role is to act as a decorator around your code to ensure, that you can quickly respond on any reliability problems.
Today I want to present a different point of view on C# applications design. If you are programming in that language most of the time, it’s probably not what you’re used to see. However I found it interesting, because it allows to achieve a few important goals...
Agile Principles, Patterns, and Practices in C# by Uncle Bob is the best book about modern Software Development I have ever read. First section (chapters 1-6) is an Overview of Agile, Extreme Programming (XP), and TDD. Very good introduction to modern software development. Chapter 6. shows all these techniques by example, by creating “The Bowling Game” application...
Jednym z częściej opisywanych zagadnień na blogach programistycznych są wzorce projektowe. Często jednak ich opisy są bardzo krótkie, bez przykładów konkretnego zastosowania w prawdziwym kodzie, a czasem nawet niepoprawne. Dzisiaj przedstawię jak wykorzystanie wzorców projektowych może przyczynić się do ograniczenia powtórzeń w kodzie testów. Nie będzie to wprowadzenie do tych wzorców (opisanych setki razy w innych miejscach), ale opis moim zdaniem nietypowego ich zastosowania.
Kiedyś przeczytałem o antypaternie jakim jest tworzenie nowego typu wyjątku, który jest per aktualny projekt, czyli np. GitHubException, ktory dziedziczy z System.Exception i nie dodaje własnych pól ani zachowania. Tworzymy go ponieważ wszystko co już jest nie pasuje nam, a wiadomo, że rzucanie Exception też jest złem. Taki wyjątek nic nie wnosi. Łatwo powiedzi...
Ostatnio na blogu
macko (32 816,53)
http://pawlos.blo... (31 510,42)
pzielinski (27 178,29)
gordon_shumway (21 178,87)
paduda (20 336,33)
psz750 (13 018,14)
rroszczyk (10 383,84)
Damian (9 011,08)
danielplawgo (7 235,99)
arek (6 642,85)
burczu (6 214,22)
PaSkol (5 393,84)
lukaszgasior (4 097,38)
jj09 (3 418,06)
jedmac (3 238,38)
http://jakub-flor... (3 224,66)
CaMeL (2 954,87)
mnikolajuk (2 596,93)
lkurzyniec (2 466,12)
FutureProcessing (2 460,11)