Common frameworks, libraries and design patterns I use

In this short post, I share some of the core frameworks, libraries and design patterns I worked with on a regular basis.

Notes on component coupling

In this post, I write about the three principles regarding component coupling that I have learned from reading the book “Clean Architecture : A Craftsman’s Guide to Software Structure and Design” by Robert Martin. The three principles are: Acyclic Dependencies Principle, Stable Dependencies Principle and Stable Abstractions Principle.

Notes on Component Cohesion

In this post, I summarize the three component principles regarding component cohesion which I learned from reading the book “Clean Architecture : A Craftsman’s Guide to Software Structure and Design” by Robert Martin. The three principles are: The Reuse/Release Equivalence Principle, The Common Closure Principle, and The Common Reuse Principle.

More on inheritance

Inheritance is something that comes up quite often during my programming experience. Whenever I have classes that share some logic or properties, I think of inheritance. However, sometimes, using inheritance ends up making a design more brittle. Through my experience and reading, I have learned a few things about inheritance.

Template method example

In a project I work on, I need to programmatically fill out some PDF forms. The forms are very similar in terms of structure, content, and fields’ names. Using iTextSharp library, I can go through the fields in the PDF and set the values. The logic for filling out a PDF form can be generic, as I just need to know what are the fields’ names and the corresponding values of the PDF. I come up with a generic model and common logic for filing out the form, as demonstrated in the below snippets.

Notes on The Clean Architecture

In this post, I’m going to share my understanding of clean architecture after reading about it in the book “Clean Architecture” and other posts, as well as how I implement the clean architecture in an ASP.NET core project.

Notes on the Interface Segregation Pattern

The Interface Segregation Pattern (ISP) is one of the principle in SOLID. As a recap, SOLID is an acronym which stands for the five software design principles:

• The Single Responsibility Principle
• The Open Closed Principle
• The Liskov Substitution Principle
• The Interface Segregation Principle
• The Dependency Inversion Principle

The Liskov Substitution Principle

In the previous post, I wrote about Barbara Liskov research paper on data abstraction and hierarchy. In the paper, the author states a property which exists between type and subtype. That property later becomes known as the Liskov Substitution Principle. In this post, I continue to go over the principle in more details and give examples. The principle is one out of the five software design principles in SOLID:

• S: Single Responsibility Principle
• O: Open Closed Principle
• L: Liskov Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle

The Open Closed Principle

In this post, I continue to share what I have learned about the SOLID principles in the book “Clean Architecture A Craftsman’s Guide to Software Structure and Design”. As a recap, six principles make up the SOLID acronym:

• The Single Responsibility Principle.
• The Open Closed Principle.
• The Liskov Substitution Principle.
• The Interface Segregation Principle.
• The Dependency Inversion Principle.

In the previous post, I wrote about the Single Responsibility Principle. In this post, I write about the Open Closed Principle.

The Single Responsibility Principle

Recently, I read the book “Clean Architecture” by Robert C. Martin. Overall, this is a great book with a wealth of information on software design principles to guide developers to build scalable, maintainable and flexible applications. A core part of the book discusses about six design principles which together make up the acronym SOLID.