One of popular interview questions is: “please describe the four characteristics of object-oriented programming”. In my observation, not many candidates — even the senior ones — can explain well Abstraction, Encapsulation, Polymorphism, and Inheritance. Worse, little did they know the drawback of Inheritance.
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.
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.
In recent years, Entity-Component Systems (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:
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. They think that inheritance is fundamental to OOP thus they blame OOP in order to praise ECS as a preference of composition over inheritance.
All software are about functions operating on data. Data come with the concepts of structure and state; concepts of functions include prototype and implementation. We can change data structures at coding-time and change data states at run-time. But the prototype and implementation of a function cannot be changed at run-time, they are allowed to be changed at coding-time only. Another different is that data are passive while functions can access data and/or call other functions. These differences between functions and data should be carefully considered when designing software.
Many programmers when concerning about OO design usually say: “Static methods are bad because they encourage procedural paradigm”. In this article, I would argue that static methods are not always bad and they have nothing to do with procedural paradigm.