This document provides an overview of the SOLID principles of object-oriented design:
- SOLID is an acronym that stands for five design principles introduced by Robert C. Martin. The principles are Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.
- Applying these principles helps make software more maintainable, reusable, and understandable by reducing coupling between modules and increasing cohesion within modules. This addresses issues like rigidity, fragility, and immobility that make code difficult to change over time.
- The principles should be applied when refactoring existing code that shows signs of rot, such as code smells, in order to remove these
SOLID Design Principles applied in JavaIonut Bilica
Video: https://www.youtube.com/watch?v=0cU-4LrcWI0
SOLID Design Principles applied in Java: rules to develop scalable and easily maintainable code
Speaker: Ionut Bilica - Senior Software Developer @ Luxoft Romania.
During this talk we will discuss about the SOLID Principles described by Robert C. Martin, applying them in the Java programming language. Each principle will be explained in detail, with practical Java examples.
We will asses how these principles make it easy to develop the software for the entire duration of the project, and how some problems can appear if these principles are not applied. We will present common code fragments that do not respect these principles, and we'll see how we can correct them. Taking the SOLID principles into consideration, we will also analyse a real Java project using a Static Code Analyzer tool (e.g. STAN).
Finally, we will discuss the strategies on how to apply these design principles in "greenfield" projects, as well as "legacy" projects, while offering some tips and tricks.
The theory of SOLID principles was
introduced by Robert C. Martin in his 2000
paper “Design Principles and Design
Patterns”.
SOLID => Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.
SOLID Design Principles applied in JavaIonut Bilica
Video: https://www.youtube.com/watch?v=0cU-4LrcWI0
SOLID Design Principles applied in Java: rules to develop scalable and easily maintainable code
Speaker: Ionut Bilica - Senior Software Developer @ Luxoft Romania.
During this talk we will discuss about the SOLID Principles described by Robert C. Martin, applying them in the Java programming language. Each principle will be explained in detail, with practical Java examples.
We will asses how these principles make it easy to develop the software for the entire duration of the project, and how some problems can appear if these principles are not applied. We will present common code fragments that do not respect these principles, and we'll see how we can correct them. Taking the SOLID principles into consideration, we will also analyse a real Java project using a Static Code Analyzer tool (e.g. STAN).
Finally, we will discuss the strategies on how to apply these design principles in "greenfield" projects, as well as "legacy" projects, while offering some tips and tricks.
The theory of SOLID principles was
introduced by Robert C. Martin in his 2000
paper “Design Principles and Design
Patterns”.
SOLID => Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.
SOLID Principles and The Clean ArchitectureMohamed Galal
This presentation is held at @blablaconnect Cairo office, Monday 31 December 2018.
In this presentation we will discuss the following topics:
- SOLID principles.
- Design Pattern vs. Clean Architecture.
- Successful software architecture characteristics.
- The Clean Architecture.
- Real life example.
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
Over the last year there has been a lot of buzz about Clean Architecture in the Android community, but what is Clean Architecture? How does it work? And should I be using it? Recently at Badoo we decided to rewrite our messenger component.
Over the years this core piece of functionality in our app has become large and unwieldy. We wanted to take a fresh approach to try and prevent this from happening again. We choose to use Clean Architecture to achieve our goal. This talk intends to share our journey from theory to implementation in an application with over 100 million downloads. By the end, you should not only understand what Clean Architecture is, but how to implement it, and whether you should.
Learning solid principles using c#
S Single Responsibility Principle
O Open Closed Principle
L Liskovs Substitution Principle
I Interface Segregation Principle
D Dependency Inversion principle
This presentation is based on a blog post I made:
http://eyalgo.com/2014/02/01/the-single-responsibility-principle/
More details are in that blog post.
I had a presentation at work with these slides.
From framework coupled code to #microservices through #DDD /by @codelytvCodelyTV
Slides from the talk about our evolution as developers. We start talking about the first spaghetti code that we made and end up talking about which are the differences between:
* Framework coupled code
* DDD modules
* Bounded Contexts
* Microservices
Blog post: http://codely.tv/screencasts/codigo-acoplado-framework-microservicios-ddd
YouTube video (Spanish): https://www.youtube.com/watch?v=o0w-jYun6AU
Twitter: https://twitter.com/CodelyTV
This is a basic tutorial on Spring core.
Best viewed when animations and transitions are supported, e.g., view in MS Powerpoint. So, please try to view it with animation else the main purpose of this presentation will be defeated.
A introduction to Microservices Architecture: definition, characterstics, framworks, success stories. It contains a demo about implementation of microservices with Spring Boot, Spring cloud an Eureka.
Continuous integration using Jenkins and SonarPascal Larocque
Continuous Integration can help your to team release features faster. It reduces the risk of deployment issue and will speed up your development cycle. In this presentation we take a look at how Jenkins and Sonar can help you Test, Analyze, Deploy and gather performance metrics that will help your team increase their development quality and reduce deployment time
SOLID Principles and The Clean ArchitectureMohamed Galal
This presentation is held at @blablaconnect Cairo office, Monday 31 December 2018.
In this presentation we will discuss the following topics:
- SOLID principles.
- Design Pattern vs. Clean Architecture.
- Successful software architecture characteristics.
- The Clean Architecture.
- Real life example.
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
Over the last year there has been a lot of buzz about Clean Architecture in the Android community, but what is Clean Architecture? How does it work? And should I be using it? Recently at Badoo we decided to rewrite our messenger component.
Over the years this core piece of functionality in our app has become large and unwieldy. We wanted to take a fresh approach to try and prevent this from happening again. We choose to use Clean Architecture to achieve our goal. This talk intends to share our journey from theory to implementation in an application with over 100 million downloads. By the end, you should not only understand what Clean Architecture is, but how to implement it, and whether you should.
Learning solid principles using c#
S Single Responsibility Principle
O Open Closed Principle
L Liskovs Substitution Principle
I Interface Segregation Principle
D Dependency Inversion principle
This presentation is based on a blog post I made:
http://eyalgo.com/2014/02/01/the-single-responsibility-principle/
More details are in that blog post.
I had a presentation at work with these slides.
From framework coupled code to #microservices through #DDD /by @codelytvCodelyTV
Slides from the talk about our evolution as developers. We start talking about the first spaghetti code that we made and end up talking about which are the differences between:
* Framework coupled code
* DDD modules
* Bounded Contexts
* Microservices
Blog post: http://codely.tv/screencasts/codigo-acoplado-framework-microservicios-ddd
YouTube video (Spanish): https://www.youtube.com/watch?v=o0w-jYun6AU
Twitter: https://twitter.com/CodelyTV
This is a basic tutorial on Spring core.
Best viewed when animations and transitions are supported, e.g., view in MS Powerpoint. So, please try to view it with animation else the main purpose of this presentation will be defeated.
A introduction to Microservices Architecture: definition, characterstics, framworks, success stories. It contains a demo about implementation of microservices with Spring Boot, Spring cloud an Eureka.
Continuous integration using Jenkins and SonarPascal Larocque
Continuous Integration can help your to team release features faster. It reduces the risk of deployment issue and will speed up your development cycle. In this presentation we take a look at how Jenkins and Sonar can help you Test, Analyze, Deploy and gather performance metrics that will help your team increase their development quality and reduce deployment time
Extreme programming (xp) | David TzemachDavid Tzemach
It’s simply the best presentation that explains the agile methodology of Extreme Programming!
Overview
1. What is Extreme programming?
2. Extreme programming as an agile methodology.
3. The values of Extreme programming
4. The Activities of Extreme programming
5. The 12 core practices of Extreme programming
6. The roles of Extreme programming
Enjoy :)
Second "code school lesson" for Eurosport's developers.
1. Refactoring : when? why? how?
2. Single Responsability
3. Practical case : clean architecture.
You’re finally doing TDD, but your past mistakes are catching up with you. No matter what you do, you can’t get rid of the gaping black holes caused by your legacy code.
In this presentation, we learn about the causes of legacy code and the reasons it is so difficult to work with. Then we discuss various techniques to test untestable code, revive and simplify incomprehensible code, redesign stable yet untested code, and repair that rift we created in the time-space continuum.
Software is not a Building - Designing Technical Architecture for ChangeCantina
In this presentation, we talk about the symptoms that make software hard to change and remedies to cure them. Topics like tension between patterns in modern, rapid development frameworks and the patterns and practices used to keep software malleable are discussed.
Slides by David Fox, Director of Technical Design
Things Every Professional Programmer Should KnowDaniel Sawano
This presentation was given by Daniel Sawano at the Omegapoint Student Conference 2015 (http://www.studentkonferens.omegapoint.se http://lanyrd.com/2015/opstudkonf/)
It has also been presented on other occasions for example at the Swedish Java Duchess meetup.
---
Pack your bags and be prepared to join a wonderful journey that will take you back to the very fundamentals of programming. We will explore everything from patterns and software design principles to memory management and data structures. We will take a look at why concepts, ideas and knowledge that has been around for decades has become more important than ever before. We will understand why they are more than just a base for common vocabulary, why they matter (for real), how they all relate to each other, and why they are all necessary for a professional programmer to master in order to build the systems of tomorrow.
Get Loose! Microservices and Loosely Coupled Architectures DevOps.com
The recently published results from the 2017 State of DevOps Survey shows that loosely coupled architectures and teams are the strongest predictor of continuous delivery. Microservices and Containers are a great choice for creating these loosely coupled systems. But, many teams find it hard to decompose monolithic applications into Microservices, and they find it harder still to coordinate deployments and releases into the emergent “hyper-hybrid” operating environments.
Get Loose! Microservices and Loosely Coupled ArchitecturesDeborah Schalm
The recently published results from the 2017 State of DevOps Survey shows that loosely coupled architectures and teams are the strongest predictor of continuous delivery. Microservices and Containers are a great choice for creating these loosely coupled systems. But, many teams find it hard to decompose monolithic applications into Microservices, and they find it harder still to coordinate deployments and releases into the emergent “hyper-hybrid” operating environments.
Recently I was asked to explain what dev-ops is at a large enterprise software vendor undergoing transformation.
In these slides, I present the concepts, tools and mindset that drive DevOPS.
Architecting for Enterprise with JavaScriptKurtis Kemple
Enterprise JavaScript—business-critical applications powered by JavaScript—is a developing area that is starting to make waves in the tech industry. What makes enterprise JavaScript such an engaging topic is that there isn’t really a go-to source for understanding the differences between operating JavaScript at scale and in business-critical settings. Many developers, VPs, and CTOs are left guessing or scraping blog posts in order to try and make informed decisions with regard to JavaScript in a large organization.
3. DEFINITIONS
• SOFTWARE ENTITY
• STATEMENT / LINE / METHOD / CLASS / PACKAGE / SERVICE
• COMPONENT
• LOGICAL GROUP OF SOFTWARE ENTITIES.
• PACKAGE
• PHYSICAL (E.G. DIRECTORY, PHAR, JAR, GEM) GROUP OF SOFTWARE ENTITIES
• COLLOCATION:- PUTTING THINGS IN THE SAME COMPONENT / PACKAGE
• COHESION :- THINGS THAT ARE CHANGED TOGETHER
• COUPLING :- DEPENDENCY THAT POTENTIALLY PROPAGATES CHANGE
4. COHESION
• Cohesion is Intra – Module Concept.
• Its Indication of the relationship within module.
• Cohesion shows the module’s relative functional
strength.
• Cohesion is a degree (quality) to which a component /
module focuses on the single thing.
• Low cohesion would mean that the class does a great
variety of actions and is not focused on what it should
do.
• High cohesion would then mean that the class is
focused on what it should be doing.
• Strive for High Cohesion i.e. a cohesive component/
module focus on a single task (i.e., single-mindedness)
with little interaction with other modules of the system.
COUPLING
• Coupling is Inter -Module Concept.
• Its Indication of the relationships between modules.
• Coupling shows the relative independence among the
modules.
• Coupling is a degree to which a component / module is
connected to the other modules.
• Low coupling would mean that changing something
major in one class should not affect the other.
• High coupling would make your code difficult to make
changes as well as to maintain it
• Strive for Low Coupling i.e. dependency between
modules should be less.
All good software design will go for HIGH COHESION and LOW COUPLING.
5. WHAT IS SOLID?
• SOLID IS A MNEMONIC ACRONYM INTRODUCED BY MICHAEL FEATHERS
• FOR THE "FIRST FIVE PRINCIPLES" NAMED BY ROBERT C. MARTIN (UNCLE BOB) IN THE EARLY 2000.
• SINGLE RESPONSIBILITY PRINCIPLE (SRP)
• OPEN/CLOSED PRINCIPLE (OCP)
• LISKOV SUBSTITUTION PRINCIPLE (LSP)
• INTERFACE SEGREGATION PRINCIPLE (ISP)
• DEPENDENCY INVERSION PRINCIPLE (DIP)
• IT IS PART OF AN OVERALL STRATEGY OF AGILE AND ADAPTIVE SOFTWARE DEVELOPMENT
6. WHY SOLID?
• CHANGE IS ONLY THE CONSTANT.
• YOUR SOFTWARE IS BOUND TO CHANGE.
• WHEN YOU MAKE CHANGES TO OUR SOURCE IT TENDS TO ROT, IF ITS NOT PROPERLY DESIGN.
• IF THIS ROT ISN’T CORRECTED AS CHANGES HAPPEN THE SOURCE BECOMES UNMAINTAINABLE.
• CODE SMELLS ARE ARE SYMPTOMS OR ANTI-PATTERNS IN YOUR CODE WHICH INDICATE ROT.
• SOLID PRINCIPLES HELPS US TO WRITE CODE WHICH IS
• LOOSELY COUPLED
• HIGHLY COHESIVE
• MAINTAINABLE
• EASY TO EXTEND
• EASILY TESTABLE
7. WHEN SHOULD SOLID BE APPLIED?
• WHILE WORKING ON SOFTWARE TO REMOVE CODE SMELLS
• BY PROVIDING A FRAMEWORK THROUGH WHICH THE PROGRAMMER MAY REFACTOR THE SOFTWARE'S SOURCE CODE UNTIL
IT IS BOTH LEGIBLE AND EXTENSIBLE.
• REMEMBER THE AGILE PRINCIPAL YAGNI (“YOU'RE NOT GOING TO NEED IT”).
• ONLY APPLY SOLID WHEN REQUIRED OR
• ONLY WHEN YOU SMELL ROT IN YOUR CODE.
• USE TEST DRIVEN DEVELOPMENT (TDD) AND START WITH THE SIMPLEST THING THAT COULD POSSIBLY WORK.
• CODE SMELLS & DESIGN SMELL WILL DEVELOP AS YOU ADD NEW TESTS AND APPLY CHANGE TO YOUR CODE.
• THIS IS THE TIME TO APPLY SOLID.
8. DESIGN SMELL
• RIGIDITY
• DIFFICULT TO CHANGE. (EVERY/SMALL CHANGE CAUSES TOO MANY CHANGES IN OTHER PARTS OF THE SYSTEM)
• KNOWN EFFORT
• FRAGILITY
• EASILY BREAKABLE (EACH CHANGE BREAKS DISTANT AND UNRELATED THINGS)
• UNKNOWN EFFORT
• IMMOBILITY
• REUSE IS IMPOSSIBLE (THE CODE IS HOPELESSLY ENTANGLED)
• EXTRA EFFORT
• VISCOSITY
• COST OF ESSENTIAL OPERATIONS (CHECK-IN, CHECK-OUT AND MERGE) IS HIGH.
• CONTINUOUS EXTRA EFFORT(TIME)
• NEEDLESS COMPLEXITY
• BUILD SOFTWARE CONSIDERING FUTURE REQUIREMENT/EXTENSION
9. RIGIDITY
• WHAT IS RIGIDITY?
• EXISTING CODE THAT CAUSES EFFORT (KNOWN EFFORT)
• HARD TO CHANGE; MINOR CHANGE TAKES LOT OF TIME.
• TAKES MORE TIME TO TEST AND REBUILD FOR SMALL CHANGE.
• WHAT CAUSES RIGIDITY?
• COUPLING
10. FRAGILITY
● WHAT IS FRAGILITY?
○ EXISTING CODE THAT CAUSES RISK (UNKNOWN EFFORT)
○ SMALL CHANGE IS ONE MODULE CAUSES MISBEHAVIOUR OF OTHER MODULE.
○ EXAMPLE : ADJUSTING RADIO IN CAR IT OPENS WINDOW GLASS.
● WHAT CAUSES FRAGILITY?
○ COUPLING
○ LACK OF COHESION
11. IMMOBILITY
• WHAT IS IMMOBILITY?
• THE DIFFICULTY (EXTRA EFFORT) TO REUSE SOMETHING.
• RIGIDITY AND FRAGILITY IN THE CONTEXT OF REUSE.
• INTERNAL COMPONENTS CAN’T BE EASILY ABSTRACTED TO USE IN NEW
ENVIRONMENT.
• EXAMPLE : USER LOG-IN MODULE CAN’T BE USED SOMEWHERE.
• WHAT CAUSES IMMOBILITY?
• COUPLING
• LACK OF COHESION
12. VISCOSITY & NEEDLESS COMPLEXITY
• WHAT IS VISCOSITY?
• TOUGHNESS IN PRESERVING DESIGN (DOING THINGS RIGHT IS HARDER THAN DOING
THINGS WRONG)
• CONTINUOUS EXTRA EFFORT (TIME)
• COST OF ESSENTIAL OPERATIONS (CHECK-IN, CHECK-OUT AND MERGE) IS HIGH.
• WHAT CAUSES VISCOSITY?
• COUPLING
• BAD DEVELOPMENT SETUP / TOOLS
• NEEDLESS COMPLEXITY
• BUILD SOFTWARE CONSIDERING FUTURE REQUIREMENT/EXTENSION.
13. SINGLE RESPONSIBILITY PRINCIPLE (SRP)
• A CLASS SHOULD HAVE ONLY A SINGLE RESPONSIBILITY.
• I.E. A CLASS SHOULD HAVE ONLY ONE REASON TO CHANGE.
• THINGS THAT CHANGE FOR THE SAME REASONS, SHOULD BE GROUPED TOGETHER.
THINGS THAT CHANGE FOR DIFFERENT REASONS, SHOULD BE SEPARATE.
• SINGLE RESPONSIBILITY IS ABOUT USERS WHO IS GOING TO USE (CLASS) IT.
• SINGLE-RESPONSIBILITY IS THE UNIX PRINCIPLE "DO ONE THING AND DO IT WELL”.
• USING LAYERS IN YOUR APPLICATION HELPS A LOT.
• SPLIT BIG / FAT CLASSES IN SMALLER ONES, AND AVOID GOD CLASSES.
• FOLLOW KISS (KEEP IT SIMPLE AND STUPID) PRINCIPLE.
• RULE OF THUMB :
• IF YOU CAN’T COME UP WITH A NAME FOR YOUR CLASS, ITS PROBABLY DOING TOO MUCH.
• IF THE NAME CONTAINS WORDS LIKE "AND, OR, BUT OR IF" THEN THAT IS A PROBLEM.
14. OPEN/CLOSED PRINCIPLE (OCP)
• SOFTWARE ENTITIES SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION
• ADDING NEW FEATURE SHOULD ADD NEW CODE RATHER THAN UPDATING THE EXISTING ONE.
• REDUCES THE RISK OF INTRODUCING NEW BUGS TO EXISTING CODE, LEADING TO MORE ROBUST
SOFTWARE.
• REDUCES COUPLING AND INCREASES FLEXIBILITY.
• HELPS TO REMOVE SNAKE OF ‘IF-ELSE` CASES. AND REMOVE THOSE BAD SWITCH CASES.
• PATTERNS FOLLOWS OCP
• OBSERVER
• STRATEGY
• DECORATOR
• VISITOR
15. LISKOV SUBSTITUTION PRINCIPLE (LSP)
• OBJECTS IN A PROGRAM SHOULD BE REPLACEABLE WITH INSTANCES OF THEIR SUBTYPES
WITHOUT ALTERING THE CORRECTNESS OF THAT PROGRAM.
• DERIVED CLASSES SHOULD EXTEND WITHOUT REPLACING THE FUNCTIONALITY OF OLD
CLASSES.
• IF A PIECE OF CLIENT CODE WORKS FOR A TYPE, THEN IT MUST WORK FOR ALL DERIVED
TYPES.
• IS IT FINE IF DERIVED CLASS OVERRIDES BASE CLASS METHOD??
• BY HAVING
• DEGENERATED (DOES NOTHING) FUNCTION
• UNCONDITIONAL THROWS EXCEPTION
• RULES
• IMPLEMENT INHERITANCE BASED ON BEHAVIOR.
• OBEY PRE AND POST CONDITIONS RULES.
16. INTERFACE SEGREGATION PRINCIPLE (ISP)
• MANY CLIENT-SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL-PURPOSE
INTERFACE.
• CLIENTS SHOULD BOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON’T
USE.
• AVOID FAT INTERFACES.
• ISP GUIDES US TO CREATE MULTIPLE, SMALLER, COHESIVE INTERFACES.
• WHICH GIVES FLEXIBLE, LOOSE COUPLED, TESTABLE CODE AND SO ON.
17. DEPENDENCY INVERSION PRINCIPLE (DIP)
• HIGH-LEVEL MODULES SHOULD NOT DEPEND ON LOW-LEVEL MODULES. BOTH SHOULD
DEPEND ON ABSTRACTIONS.
• ABSTRACTIONS SHOULD NOT DEPEND ON DETAILS. DETAILS SHOULD DEPEND ON
ABSTRACTIONS.
• ONE SHOULD “DEPEND UPON ABSTRACTIONS. DO NOT DEPEND UPON CONCRETIONS”.
• HIGH LEVEL POLICY SHOULD BE INDEPENDENT ON LOW LEVEL DETAIL.
• REASONING: HIGH-LEVEL MODULES BECOME MORE REUSABLE IF THEY ARE IGNORANT OF
LOW-LEVEL MODULE IMPLEMENTATION DETAILS.
• FOLLOW PROGRAMMING TO THE INTERFACE PRINCIPLE.
Walking on water and developing software from a specification are easy if both are frozen. “ - Edward V. Berard
Design Principles : Set of guidelines. Its not Rules.
Design Patterns : Solution to commonly occurring problem in a context.
Library : the overall program's flow of control is dictated by the caller (user).
Framework : A framework is a scaffold that you can you build applications around.
Provides some base functionality environment for better and faster development.
Ioc (Inversion of control): the overall program's flow of control is not dictated by the caller, but by the framework
Extensibility
Experience on working with any software/application or legacy code?
Don’t be STUPID.
Singleton
Anti Pattern
Does more than one thing
Introduces global state & Hidden dependencies
Difficult to test
Tight Coupling
Change in one module in your application requires you to change another module.
Untestability
Caused by tight coupling
Premature Optimization
Only cost, and no benefit.
Follow YAGNI principle.
Indescriptive Naming
Write code for people, not for computers.
Strpbrk, strcspn
Duplication
Follow DRY & KISS principle
Mnemonic for OSI layer. Mnemonic device is any learning technique that aids to retain information in human memory.
All People Seem To Need Data Processing.
Application: All
Presentation: People
Session: Seem
Transport: To
Network: Need
Data-link: Data
Physical: Processing
Code smell which indicate not really bugs, but usually are a kind of indicator for problems in the future.
Modular code doesn’t mean good design.
Design is all about managing dependencies.
Unmanaged dependencies kills your application.
Context independent : Can be rearranged.
UML diagrams are not design they are preliminary design.
The source code is the design.
List of possible code smells can be found: https://blog.codinghorror.com/code-smells/
Gives/Generates “Low Coupled”, “Highly Cohesive” code. Removes “Immobility Smell”.
Legible – Clear enough to read
Inheritance, Encapsulation and Polymorphism are mechanism in OO but they are not essential qualities.
Essentials qualities of OO
Ability to Invert key Dependencies, protecting high level policy from low level detail.
OO is all about Dependency management
Increasing productivity or time or money and saving on “waste”.
Primary value of software : Capable to tolerate and facilitate the ongoing change, without bug crashes and delays.
Secondary value of software : Software meets the current needs of the user. CUSTOMER STATISFICATION.
Modules are coupled.
Viscosity : Not having proper Editor, Version System, Code Quality Assurance Tool Setup, Continuous Deployment.
TIGHTLY COUPLED:- Multi tool knife (Screwdriver and hammer) - needed by 2 people or at 2 places.
Problem :- Makes the class harder to understand and harder to test, decreasing cohesion.
Strive for loosely coupled objects so that changing one object reflect changes in other object
Encapsulate what varies from what doesn't..
PRIME Number Printer
Multiple tasks – Not good Quality/better output.
Single tasks - Good Quality/better output.
Functions doing 2 things: Checking for Boolean, Null, If, Switch, Try, . Arguments are Boolean, Null.
Old Camera is not extensible. SLR camera is open for Extension, can attach different lenses.
Observer pattern :
Define a one-to-many dependency between objects so that when one objectchanges state, all its dependents are notified and updated automatically.
Strategy pattern :
defines a family of algorithms,
encapsulates each algorithm, and
makes the algorithms interchangeable within that family.
Undefined behavior means that it works okay during development but blows up in production.
A new subtype should not screw up the client code.
Square is a Rectangle but substitutability fails. Circle is-an Ellipse.
Bullock-cart is not substitution for 4 wheelers (Car). Break, Light, Accelerator, Doors.
Bird & Ostrich/Pigen - Ostrich can’t fly.
Visual 2005 can be substituted by Visual Studio 2010 (Backward Compatibility).
Fat classes - Class has lot of lot methods (Job classes).
Similar to normalizing database like normalizing database from 1NF to 3NF where a big table is broken into tables with related columns.
Without DI class is Brittle, inflexible, and hard to test. Tightly coupled modules are difficult to reuse, and also hard to test.
Code example.
Let’s see classic Button & Lamp application.
Dependency Injection : Putting high-level modules in different packages than the low-level modules it uses.
Dependency Injection Container : A way to auto-wire classes together.
IoC (Inversion of Control) : A software design architecture where the framework controls the program flow.
IOC is used to increase modularity of the program and make it extensible.
http://stackoverflow.com/questions/11316688/inversion-of-control-vs-dependency-injection-with-selected-quotes-is-my-unders
SOLID TEST
SIP - Test should be written for an actor
OCP - Production code should be open for extension and test should be closed for modification
LSP - Derivative classes (Classes derived from some class like Stub class) used for test should follow LSP.
ISP - If require Separate Interface for test cases.
DIP - Test (Low level detail) should depend upon Production Code (High Level detail) so that dependency can be in one direction BUT not vice-versa.
Encapsulate what varies from what doesn't.
Favor Composition over inheritance.
Program to interface not an implementation.
Strive for loosely coupled objects so that changing one object reflect changes in other object.
If you take the SOLID principles to their extremes, you arrive at something that makes Functional Programming look quite attractive.
Objects are a poor man's closures.
Closures are a poor man's objects.
Don’t be STUPID: GRASP SOLID!