[edanm]

I found a few problems with the article.

Firstly, right at the end, he says: "Remember, unless you unlucky enough to be using Java or another archaic language with no proper property support, you can always refactor your class to replace a public field with a protected one with a public accessor property if requirements change". Is Java really considered archaic nowadays? C++ and Java probably make up a fairly large portion of programs written today, and this article doesn't address them. Probably should have mentioned that at the top of the article.

Secondly, his example of why the principle of “open for extension but closed for modification” is a not great. He gives an example of a class with a "div" method that is found to contain a bug. Instead of fixing the bug, a "div2" method is added which fixes that bug.

The problem is, that's exactly the approach I would advocate in plenty of situations. When I was in charge of QA for an embedded system, if he'd have come to me with a bug 1 week before a release, I would never have agreed to fix it. In a big enough system, you can never tell what code relies on bugs to work, and would break if that bug was removed. This is a lesson that was hard to teach most of the programmers, but in the end, whether the system actually works or not matters a lot more than whether the code contains any bugs.