The three characteristics of OOP


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.

Continue reading “The three characteristics of OOP”

“Null References: The Billion Dollar Mistake”

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?

Continue reading ““Null References: The Billion Dollar Mistake””

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”

Gọi qua lại giữa code C và C++


Chúng ta vẫn biết rằng C++ là “C with Classes”, vẫn thường xuyên viết code trộn giữa C++ và C. Trong C++ chúng ta gọi C dễ dàng, ví dụ như hàm printf của stdio.h được gọi trong code C++ bình thường. Tuy nhiên, ở chiều ngược lại, trong C mà muốn gọi C++ thì đòi hỏi phải nắm được một số quy tắc.

Continue reading “Gọi qua lại giữa code C và C++”