Object-Oriented Programming
Please see my other Object-Oriented Programming (OOP) articles. Apply Contracts Between Objects with Interfaces In this article I’ll demonstrate how to ensure consistent behavior when designing an application. I’m going to build an airport that only accepts types of craft which behave in a consistent manner. Also, when the airport is in operation, I want to ensure…
Architecting Behavior for Extensibility When designing class behavior, it’s important to remember in the implementation of those objects, future changes are certain, necessitating flexibility to evolving requirements. Extensibility in Design When designing behavior in classes, you can simply define functions to be used as object methods, but that assumes the details of each function need…
Please visit my other Object-Oriented Programming articles. Reaping the most benefits from refactoring Use the following quick cheat-sheet when refactoring. Topic Task Remove unhelpful comments Remove comments which state the obvious or replace unfocussed blocks of code with clearly-named methods following the Singe Responsibility Principle (SRP).Remove zombie code – code commented-out to no longer be…
Extend .NET Framework
Please see my other Object-Oriented Programming (OOP) articles. Ensuring Separation of Concerns When refactoring a web application, the following table represents a high-level overview of technologies/tools and the appropriate use of each, along with examples of how their boundaries for us may be violated. Keep in mind for each tool is intended boundary and look…
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…
TechMbaBi 