Notes on The Dependency Inversion Principle

The Dependency Inversion Principle is the last principle in SOLID. As a recap, SOLID is an acronym that stands for the five software design principles which Robert Martin discusses in his book “Clean Architecture – A Craftsman’s Guide to Software Structure and Design”.

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

Migrating from Microsoft.AspNetCore.Authentication.AzureAD to Microsoft Identity Web authentication library to integrate with Azure AD.

I recently had a chance to clean up some of the deprecated libraries I used for validating a JWT access token or obtain one via the client-credentials flow or the on-behalf-of flow. The libraries I used were under the Microsoft.AspNetCore.Authentication.AzureAD packages. Per the document, since ASP.NET core 5.0, users should use the Microsoft.Identity.Web package to integrate with Azure AD and Azure ADB2C.

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

Rendering a PDF in angular that works with mobile browsers using ng2-pdf-viewer

In several applications I worked on, we used iframe to display PDFs. The PDF displays fine on desktop browsers. However, on a mobile browser such as Safari on iPhone and iPAD, only the first page shows up. Many people have run into the same issue, as discussed in this stackoverflow post and also on the apple communities page.

Three essential libraries for unit testing a .NET project

In this post, I share the three libraries I find useful for unit testing a .NET project: EF Core SQLite Database Provider, Bogus and Moq.

Notes on Barbara Liskov paper on data abstraction and hierarchy

In October 1987, Barbara Liskov published a research paper in which she discussed about different but related concepts: data abstraction, inheritance, encapsulation, implementation hierarch, type hierarchy and polymorphism. I’ve found the paper to be insightful and informative. In this post, I simply give a recap of what I have learned and share my thoughts from reading the paper.

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.

Differences between a Promise and an Observable

In this post, I outline a few fundamental concepts I have learned about an Observable and how it is different than a Promise.

Before discussing the differences between an Observable and a Promise, let’s talk about what they have in common. Both Observables and Promises are frameworks for producing and consuming data. They follow the push protocol which means the producer determines exactly when to send the data to the consumer. In comparison, in a pull protocol, the producer only produces data when the consumer asks for it.