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…
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…
Keeping Class Behavior Focused As part of the S.O.L.I.D. design principles, the Liskov Substitution Principle (LSP) ensures when designing classes, the user interface must operate by contact by ensuring during run-time, each object should be replaceable by objects instantiated by a subtype of that class or vice versa. For example, subtype classes (derived) must not…
Supporting Change Without Breaking Software As part of the S.O.L.I.D. design principles, the Open–Closed Principle (OCP) ensures parts of software (classes) are open for extension, but closed for modification. In other words, you should be able to modify a class’ behavior without modifying its code. New methods are added by adding new classes without changing…
Limiting Class Scope As part of the S.O.L.I.D. design principles, the Single Responsibility Principle (SRP) ensures each class should only have one responsibility. This principle proactively ensures classes begin with a narrow focus, preventing future changes from affecting other parts of the application. In my previous article OOP: Class Design, I illustrated how a class…
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,…
Please see my other Object-Oriented Programming (OOP). S.O.L.I.D. Design Principles DESIGN PATTERNS Adapter Factory Inversion of Control Service Locator Singleton
Please see my other Design Pattern articles. Ensuring single instance use during instantiation. Every so often in development, a business rule dictates that instantiation of a certain type produce only one instance during the lifetime of the application. The Singleton design pattern, one of the Creational Patterns, ensures that regardless of many instantiations of a…
Please see my other Design Pattern articles. Completing the IoC Design Pattern. In my Design Patterns: Inversion of Control article, I illustrated how to decouple classes from having dependencies – the CustomerPayment class contained a dependency on the IPayment interface. Any class which has intimate knowledge of another is tightly-coupled to that class. By implementing…
Please see my other Design Pattern articles. Providing flexibility into the domain by abstracting implementation. Using abstraction between concrete and class implementation, avoid tightly-coupled classes, which leads to changes in once class to ripple throughout your application. One method of doing this is the Inversion of Control design pattern which allows the class calling the…
TechMbaBi 