Eliminate enterprise software design instability - protect variations! Nickolay Kofanov
Owning a hammer doesn't make one an architect.
Responsibility-Driven-Design The way of thinking about the design of software objects (and also larger-scale components) in terms of responsibilities, roles, and collaborations
A critical ability in OO development is to skillfully assign responsibilities to software objects. General Responsibility Assignment Software Patterns grasp these principles to successfully design object-oriented software.
2 common patterns that are most often used subconsciously GRASP #1 Creator Question: Who should be responsible for creating a new instance of some class GRASP #2 Information Expert Question: What is a general principle of assigning responsibilities to objects
Yin und Yang of software engineering GRASP #3 Low Coupling Question: How to support low dependency, low change impact, and increased reuse? GRASP #4 High Cohesion Question: How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?
High Cohesion + Low Coupling = Code Orthogonality The killer combination in components of tightly defined responsibilities together with independence from the wider system
Improve coupling? GRASP #5 Indirection Question: Where to assign a responsibility, to avoid direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported and reuse potential remains higher? "Most problems in computer science can be solved by another level of indirection" Improve cohesion? - GRASP #6 Pure Fabrication Question: What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Expert (for example) are not appropriate?
Poly(multiple)-morph(form)-ism GRASP #7 Polymorphism Question: How to handle alternatives based on type? How to create pluggable software components?
GRASP #8 Controller Question: What first object beyond the UI layer receives and coordinates ("controls") a system operation GRASP Controller!= MVC Controller && ( GRASP Controller instanceof App/Domain service GRASP Controller instanceof Domain Model )
GRASP #9 Protected Variation Question: How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements? Identify points of predicted variation or instability and assign responsibilities to create a stable interface around them. Almost every software or architectural design trick/principle/pattern is a specialization of Protected Variations
Simple example uper Delivery! Requirement for the release v1.0: Ukraine only shipment with Requirement for the release v2.0: International shipment with
Arrange Delivery Use Case: 1. Create new parcel 2. Send parcel to address 3.
Something is wrong here Arrange Delivery Use Case: 1. Create new parcel 2. Send parcel to address 3. Coupling to concrete class
Do the right thing (analysis); Do the thing right (design)
GoF Adapter Pattern
Repetition is the mother of all learning: Almost every software or architectural design trick/principle/pattern is a specialization of Protected Variations
Maturation of a developer or architect can be seen in their growing knowledge of ever-wider mechanisms to achieve PV Craig Larman the author of GRASP
Data-Driven Design The system is protected from the impact of data by externalizing the variant, reading it in, and reasoning with it.
Reflective Design The system is protected from the impact of logic or external code variations by reflective algorithms that use introspection and metalanguage services
Uniform Access Principle
Interpreter-Driven Design The system is protected from the impact of logic variations by externalizing the logic, reading it in, and using an interpreter.
Service Discovery / Lookup System is protected from variations in the location of services, using the stable interface of the lookup service Consul makes it simple for services to register themselves and to discover other services via a DNS or HTTP interface.
Liskov Substitution Principle (LSP) LSP formalizes the principle of protection against variations in different implementations of an interface, or subclass extensions of a superclass. CIRCLE What s the relation ship? ELLIPSE The Circle/Ellipse Dilemma Robert C. Martin If your code works with object a of type A it should also work correctly with any object b of type B if B extends (implements) A
Liskov Substitution Principle violation: Circle is not an Ellipse in software perspective
Structure-Hiding Design Law Of Demeter The system is protected from the impact object structure variations. Within a method, messages should only be sent to: 1. this object 2. An attribute of this. 3. An element of a collection which is an attribute of this. 4.A parameter of the method. 5. An object created within the method. when you want a dog to walk, you do not command the dog's legs to walk directly; you command the dog which then commands its own legs
Incorrect Correct
The farther along a path the program traverses, the more fragile it is Why? because the object structure may change! (especially true in young applications or early iterations)
Two points of change: Variation point - variations in the existing, current system or requirements Evolution point - speculative points of variation that may arise in the future, but which are not present in the existing requirements. Protected variations mechanisms are applied to both.
2 dangerous software engineer diseases: 1. Pattern-itis 2. Generalize-itis suffix -itis forming names of inflammatory diseases. You aren t going to need it extreme Programming principle
Novice developers tend toward brittle designs. Intermediate developers tend toward overly fancy and flexible designs. Expert designers choose with insight Sometimes a simple design whose cost of change is balanced against its likelihood.
Links: echo "Thank you!" Error, no keyboard. Press F1 to continue _