It’s that time of year again. It seems like about once a year I get interested designing a schema library. This post is a collection of my latest ideas and design goals, mostly based on what I’ve learnt from the previous three or four implementations.
This topic is probably interesting to a tiny subset of developers, and super boring to everyone else. I’ve tried to write this post in a way that is accessible to a wider developer audience, but you have been warned!
This is a short parable I came up while discussing linters, in response to someone asking if I think it’s good to be inconsistent.
Why use private at all? What is the benefit of trying to stop other
people from using code that works perfectly well? It’s to reduce
future maintenance costs by discouraging coupling to unstable
dependencies.
I know. FizzBuzz has been done to death. But I want to use it as a familiar base upon which we can explore some of the common tradeoffs involved in writing and maintaining software. In this article, I’ll show multiple implementations of FizzBuzz, all designed to achieve different goals, and discuss the implications of each.
There was an interesting question on StackOverflow this morning: Why doesn’t NSOrderedSet inherit from NSSet? It’s interesting because the reason is so easy to miss. I thought it would make a good blog post because it turned out to be a nice, real-life example of the Liskov substitution principle (herein abbreviated to LSP).
In the competition to make the worst acronym, RAII probably comes second after HATEOS. Nevertheless, it is an important concept because it allows you to write safer code in C++ — a harsh, unforgiving language that is all too happy to help you shoot yourself in the foot.
This article will explain exception-safety and common pitfalls in C++. As we work out how to avoid these problems, we will accidentally discover RAII. Then, we will finish by defining exactly was RAII is, and where it is already being used.
This is that last part of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Interface Segregation Principle.
The Interface Segregation Principle (ISP): Clients should not be forced to depend upon interfaces that they do not use.
This is part four of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Dependency Inversion Principle.
The Dependency Inversion Principle (DIP): High level modules should not depend upon low level modules. Both should depend upon abstractions.
This is part three of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Liskov Substitution Principle.
The Liskov Substitution Principle (LSP): functions that use pointers to base classes must be able to use objects of derived classes without knowing it.
This is part two of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Open Closed Principle.
The Open Closed Principle (OCP): You should be able to extend a classes behavior, without modifying it.
This is part one of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Single Responsibility Principle.
The Single Responsibility Principle (SRP): A class should have one, and only one, reason to change.
Model view controller (MVC) is a very useful and popular design pattern. If you’re writing software, you should know it. Unfortunately it’s also one of the hardest to truly understand. In this article I will provide what I think is the simplest explanation of MVC, and why you should use it.