GoF Builder Pattern

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.

Continue reading “GoF Builder Pattern”



Kage - Shadow of the Ninja
Kage – Shadow of the Ninja

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 class inheritance is fundamental to OOP thus they blame OOP in order to praise ECS as a preference of composition over inheritance.

Continue reading “OOP vs. ECS”

Acceptance tests vs. Unit tests

Hey dude, what are the differences between acceptance tests and unit tests?

Well, an acceptance test – aka scenario test – may involve many units of our software, while a unit test is a test for only one unit.

What if the acceptance test involves only one unit? Now the acceptance test and the unit test are the same?


Continue reading “Acceptance tests vs. Unit tests”


Many software developers — especially .NET developers — have a habit of putting the “I” prefix when naming interfaces. At first glance, this is good because it helps us to identify quickly whether a class is an interface or not.

But why do we — as clients of the class — need to know about this?

Clearly, typical clients really don’t care. Just invoking the methods provided, and that’s it, knowing that it is an interface is useless. However, there are special clients who do care so that they know the class cannot be instanced — by the new keyword — and need to be implemented or extended.

In most cases, the typical force dominates the other one, thus the “I” prefix is unnecessary. Sometimes it is annoying: if we decide to change the interface to a normal class (or abstract class), we have to remove the prefix. As we know, renaming a type is often awkward!

As a rule of thumb, good names come from problem domains, not solution domains.

Functions & Data

All software are about functions operating on data. Data come with the concepts of structure [1] 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.

Continue reading “Functions & Data”

Imperative vs Declarative

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.

Continue reading “Imperative vs Declarative”

What is the problem with static methods?

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.

Static-X was an American industrial-metal band from Los Angeles, California formed in 1994.
Static-X was an American industrial-metal band from Los Angeles, California formed in 1994.

Continue reading “What is the problem with static methods?”

Bitcoin – đồng tiền tự do (P.2)

Transaction-based system

phần trước, chúng ta đã biết rằng database system của Bitcoin không gì khác hơn là bao gồm rất nhiều các transaction. Chính vì vậy, system này đôi khi còn được gọi là transaction-based system. Mỗi transaction về cơ bản cho biết số tiền bao nhiêu được chuyển đi từ những tài khoản nào sang những tài khoản nào. Cho nên để trả lời câu hỏi: “số dư tài khoản này hiện tại là bao nhiêu?”, system phải truy vấn tất cả các transaction có dính líu tới tài khoản đó.

Thoạt nhìn qua, cách làm này có vẻ dở ẹc vì nó chậm. Tại sao không làm theo cách truyền thống? Tức là mỗi một tài khoản luôn đi kèm theo nó một số dư, mỗi khi muốn chuyển tiền từ tài khoản A sang tài khoản B, chỉ cần trừ bớt vào số dư của A và cộng thêm vào số dư của B. Cách truyền thống này không phù hợp trong một môi trường distributed như Bitcoin, bởi vì:

Continue reading “Bitcoin – đồng tiền tự do (P.2)”