Some thoughts on monads (P.1)

I know, I know, the world does not need yet another explanation on monads. There have been a lot of related articles you can find on the Internet. Still, most of them are so math-intensive that we as software developers (we aren’t good at math) don’t want to read. So please give me a try to explain monads to you. I think they are worth knowing about. No math knowledge is required. What I want from you is just a basic knowledge of functional programming.

Continue reading “Some thoughts on monads (P.1)”


“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”