Design Patterns: S.O.L.I.D. Dependency Inversion Principle

Avoiding Dependencies Between Layers As part of the S.O.L.I.D. design principles, the Dependency Inversion Principle (DIP) provides guidance for ensuring layers within the application avoid unnecessary dependencies from coupling. DIP ensures each layer’s modules remain independent of one another and should depend on abstractions instead of concrete details, increasing usability and flexibility to change. In…

Design Patterns: S.O.L.I.D. Interface Segregation Principle

Providing Focused Behaviors for Classes As part of the S.O.L.I.D. design principles, the Interface Segregation Principle (ISP) supports other S.O.L.I.D. principles in providing classes with focused behavior by ensuring interfaces inherited by classes remain lean and focused on specific behaviors. To illustrate ISP, I’ll use examples from the Single Responsibility Principle (SRP) article. I’ll begin…

Design Patterns: S.O.L.I.D. Overview

Please see my other Design Pattern articles. Ensuring software remains understandable, flexible, and maintainable In response to common design difficulties inherit within many software systems, a series of design patterns were integrated together to form the acronym, S.O.L.I.D., which representing a specific principle. In addition to producing programming code and architecture which is understandable, flexible,…

OOP: Class Design – Step 3 – Encapsulation

Please see my other Object-Oriented Programming (OOP) articles. Leveraging Encapsulation to Protecting Data & Behavior Implementation With my class requirements defined in my Class Design – Step 1 – Requirements article, I’m now ready to define the details of my Employee class. As demonstrated in my Inheritance article, I designed an Employee class which serves…

OOP: Class Design – Step 2 – Naming Convention

Please see my other Object-Oriented Programming (OOP) articles. Using Object-oriented Programming (OOP) to Design Robust Classes At the beginning of a software project, ensure you capture requirements in a manner which developers may easily interpret. Stating requirements using a story format allows users and actions to be clearly identified. When telling the story, ensure you…

OOP: Class Design – Step 1 – Requirements

Please see my other Object-Oriented Programming (OOP) articles. Using Object-oriented Programming (OOP) to Design Robust Classes At the beginning of a software project, ensure you capture requirements in a manner which developers may easily interpret. Stating requirements using a story format allows users and actions to be clearly identified. When telling the story, ensure you…

OOP: Abstract Classes vs Interfaces

Please see my other Object-Oriented Programming (OOP) articles. Knowing How to Leverage Abstractions Topic Abstract classes Interfaces Implementation details: Some members (methods). No. Fields: Yes No. Inherit from: Abstract class, interface Interface only. Members can have access modifiers: Yes. Abstract members private by default. No. Interface members public by default. Implementation Details: Abstract Classes As…