In object-oriented design, objects encapsulate state and expose behavior that operates on that state. Consequently, if an object must exhibit different behaviors at various stages of its lifecycle, it can be beneficial to represent these transitions by changing its type. For example, consider a system that manages books. A newly created but unsaved book might… Continue reading Changing Object Types to Reflect State Transitions
Interfaces vs Abstract Classes
This article moves beyond the typical “mechanical” distinctions between interfaces and abstract classes, focusing instead on their intended roles in your code. In C#, an interface establishes a contract that implementing classes must follow. When multiple implementations share common functionality, they may encapsulate that shared behavior in an abstract base class. However, not every subclass… Continue reading Interfaces vs Abstract Classes
Generic Discriminator and Factory
As discussed in the Open-Closed Principle article, the final solution included an EmailSender class, that acted as the orchestrator, and required as dependencies a CurrentDayProvider and an EmailSenderFactory. The EmailSender class looked like this: The CurrentDayProvider was not the most complicated class ever: And the EmailSenderFactory was pretty standard containing the decision logic based on… Continue reading Generic Discriminator and Factory
Substitute Switch-Case With Data Structures
As discussed in the Open-Closed Principle article I suggested that in some certain situations, the decision on what email sender type to instantiate in the factory, can be represented in a data structure, instead of using switch-case (or if-else) structures. I will paste the code here, because the changes are not major, and then I’ll… Continue reading Substitute Switch-Case With Data Structures
Open/Closed Principle
The Setup This week we are talking about the Open-Closed Principle. This principle states that a class (or method) should be open to extension and closed to modification. In other words we have to teach it new tricks without changing the actual code. “But that impossible” I hear you say. And I hope for all… Continue reading Open/Closed Principle
The Interface Is Owned by the Client
This one is a less known principle, but with great implications. It is related to the Interface Segregation Principle, as well as to the Dependency Inversion Principle. It also dictates where interfaces should live in a multiple assembly architecture. This is going to be interesting, so hang on to your keyboards. What Do You Mean?… Continue reading The Interface Is Owned by the Client
The Single Responsibility Principle
Definition According to Wikipedia the Single Responsibility Principle is a computer program principle that states that “A module should be responsible to one, and only one, actor”. Robert C. Martin, the originator of the term, expresses the principle as “A class should have only one reason to change”. In my experience as an interviewer, I… Continue reading The Single Responsibility Principle
What is a Constructor?
This article is part of the The Anatomy of a Technical Interview series. The actual question is “What is a constructor, and what role does it play inside of an object?”. Throughout my interview experience I have received a lot of answers to this question. Answers vary in shape and form, but are mostly along… Continue reading What is a Constructor?
How It All Started
This article is part of the The Anatomy of a Technical Interview series. In this series I share with you my experiences and insights that I gathered while holding technical interviews. I’ve seen my fair share of interviews while I was applying for various jobs and positions throughout my carrier. Many of them were either… Continue reading How It All Started