Tag Design
The best way to implement a Main Something property
In this post, we will explore a common design problem: implementing a Main Something property. There’s an equally common solution to this problem which is sub-optimal in most cases.
Growing Object-Oriented Software, Guided by Tests Without Mocks
This is a review of the Growing Object-Oriented Software, Guided by Tests book (GOOS for short) in which I’ll show how to implement the sample project from the book in a way that doesn’t require mocks to be tested. Growing Object-Oriented Software, Guided by Tests Without Mocks Let me first explain why I’m doing a review of this book. If you read this blog regularly, you probably noticed that I’m pretty much against using mocks in tests.
Defensive programming: the good, the bad and the ugly
In this post, I want to take a closer look at the practice of defensive programming.
Having the domain model separated from the persistence model
In this post, I’d like to write about a pretty common discussion in DDD circles: should one have the domain model separated from the persistence model? In other words, should you map your domain objects to the DB tables directly using an ORM or would it be better to use a separate set of Data Access Objects (DAOs) instead?
Is SQL a good place for business logic?
<TL;DR> No, it isn’t. While SQL is a Turing-complete language and we can use it to encode any business logic we want, placing business (domain) logic into SQL leads to a less maintainable solution comparing to one that uses an OO or functional language. Because of that, I advocate to limit the use of SQL to read-only queries (which can potentially contain business logic, that’s fine) and simple CRUD statements where possible.
Most valuable software development principles
I’d like to wrap up the "Most valuable software development principles" article series with this post.
Making implicit assumptions explicit
Another software development principle I advocate you follow is making implicit assumptions explicit in your code. Let’s see what that means.
Fail Fast principle
The fail fast principle is underlying for many other software development practices. It comes out so often that it’s hard to cover all its appearances in a single article. Nevertheless, that is exactly what I’m going to do here :)
DRY revisited
Another principle we should follow when building a software project is the DRY principle. The abbreviation stands for Don’t Repeat Yourself. While it seems pretty straightforward and intuitive, this principle is more than meets the eye. Let’s see how it is so.
Encapsulation revisited
The third most important software development principle is Encapsulation.
