The DRY principle advocates the separation of concerns principle and aims to eliminate redundancy in code as well. It promotes the idea that each piece of knowledge or logic should have a single, unambiguous representation within a system.So, when you have duplicated logic in your system, encapsulate it and reuse that new encapsulation in multiple places instead. If you find yourself writing the same or similar code in multiple places, refactor that code into a reusable component instead. Leverage functions, classes, modules, or other abstractions to refactor the code.Adhering to the DRY principle makes your code more maintainable, less error-prone, and easier to modify because a change in logic or bug fix needs to be made in only one place, reducing the likelihood of introducing errors or inconsistencies.However, it is imperative to regroup duplicated logic by concern, not only by the similarities of the code itself. Let’s look at those two classes:
public class AdminApp
{
public async Task DisplayListAsync(
IBookService bookService,
IBookPresenter presenter)
{
var books = await bookService.FindAllAsync();
foreach (var book in books)
{
await presenter.DisplayAsync(book);
}
}
}
public class PublicApp
{
public async Task DisplayListAsync(
IBookService bookService,
IBookPresenter presenter)
{
var books = await bookService.FindAllAsync();
foreach (var book in books)
{
await presenter.DisplayAsync(book);
}
}
}
The code is very similar, but encapsulating a single class or method could very well be a mistake. Why? Keeping two separate classes is more logical because the admin program can have different reasons for modification compared to the public program.However, encapsulating the list logic into the IBookPresenter interface could make sense. It would allow us to react differently to both types of users if needed, like filtering the admin panel list but doing something different in the public section. One way to do this is by replacing the foreach loop with a presenter DisplayListAsync(books) call, like the following highlighted code:
public class AdminApp
{
public async Task DisplayListAsync(
IBookService bookService,
IBookPresenter presenter)
{
var books = await bookService.FindAllAsync();
// We could filter the list here
await presenter.DisplayListAsync(books);
}
}
public class PublicApp
{
public async Task DisplayListAsync(
IBookService bookService,
IBookPresenter presenter)
{
var books = await bookService.FindAllAsync();
await presenter.DisplayListAsync(books);
}
}
There is more to those simple implementations to discuss, like the possibility of supporting multiple implementations of the interfaces for added flexibility, but let’s keep some subjects for further down the book.
When you don’t know how to name a class or a method, you may have identified a problem with your separation of concerns. This is a good indicator that you should go back to the drawing board. Nevertheless, naming is hard, so sometimes, that’s just it.
Keeping our code DRY while following the separation of concerns principles is imperative. Otherwise, what may seem like a good move could become a nightmare.