Null is clearly evil. We as human tend to forget to check null, and boom… crash!!! Documentation may help, but again we still forget reading documents. Worse, not all documents are correct and up-to-date 100%. Even if we remember to do every null check, our code would be very messy. So what is the solution? Checked-exceptions can help but must be used with care otherwise nearly every function/method in our programs could throw checked-exceptions, and try/catch statements would appear everywhere.

Exceptions are a very common concept in most of languages nowadays. In this article we will discuss why exceptions are needed, checked vs. unchecked exceptions, and why C# doesn’t have checked exceptions. In the old days, defensive code were a mess Before exceptions were invented, defensive code had been overwhelmed with a lot of error checking and recovery from those errors, for example: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 void handle() { // style #1: error is embedded in the return value int errFoo = foo(); if (errFoo == -1) { // recovery and may return } // style #2: error is assigned to the output parameter unsigned int errBar; int value = bar(.

This article is about my personal explanation of the famous design patterns: Model View Controller (MVC), Model View Presenter (MVP), Presentation Model (PM), and Model View ViewModel (MVVM). Let’s start with Model. Model: the core of an application At the core of an application is a component called Model where business objects and use-case objects live. Normally, the outside world interacts with the Model by sending input to the use-case objects, these objects then manipulate the business ones and finally return output back to the outside world.

Builder Pattern and Factory Pattern are pretty similar in a way: both of them encapsulate the details of object-creation processes. However, in cases there are many complicated processes to create various representations of objects, and those processes share a common trait, Builder Pattern is the better choice. Let’s say we have two processes to build a house: Asian process and European one. We will start with Factory Pattern and gradually adapt it to Builder Pattern.

In recent years, Entity-Component System (ECS) has been recognized as the most notable architecture for game development. There are many good articles about the architecture that can be found on the Internet, some of them are: Entity Systems are the future of MMOG development What is an entity system framework for game development? Why use an entity system framework for game development? Understanding Component-Entity-Systems gamedev.stackexchange.com Entity Systems Wiki Entity component system Of course these articles are excellent and well-written, but one thing I don’t like about them is that they are not fair at comparing OOP and ECS.

Wikipedia defines imperative and declarative programming as: imperative programming is a style that uses statements that change a program’s state… focuses on describing HOW a program operates. declarative programming is a style that expresses the logic of a computation without describing its control flow… focuses on describing WHAT the program should accomplish in terms of the problem domain. When we read the definition of something, we tend to focus on terms that are already familiar to us, and then use those terms as a metaphor in order to understand the definition.