The document discusses refactoring code to follow the SOLID principles of object-oriented design. It provides an overview of the Single Responsibility Principle (SRP), gives an example of how to refactor code to follow SRP, and summarizes that following SRP leads to lower coupling and higher cohesion. It also discusses the Open/Closed Principle (OCP) and the Liskov Substitution Principle (LSP), providing examples of how to apply each principle when refactoring code.
Object Oriented Design Principles
~ How to become a SOLID programmer ~
~ A guide to make a well-designed application with Laravel ~
"Proper Object Oriented Design makes a developer's life easy, whereas bad design makes it a disaster"
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 presentation discusses software design. It discusses the characteristics of a good and bad design. Then it talks about how to achieve a good design. Then finally we discuss the SOLID Principles of Object Oriented Design. These are 5 principles compiled by Rober Cecil Martin aka Uncle Bob. The benefit of these principles is to achieve a good OO design which is high in cohesion and low in coupling thus easily adaptable to change
Object Oriented Design Principles
~ How to become a SOLID programmer ~
~ A guide to make a well-designed application with Laravel ~
"Proper Object Oriented Design makes a developer's life easy, whereas bad design makes it a disaster"
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 presentation discusses software design. It discusses the characteristics of a good and bad design. Then it talks about how to achieve a good design. Then finally we discuss the SOLID Principles of Object Oriented Design. These are 5 principles compiled by Rober Cecil Martin aka Uncle Bob. The benefit of these principles is to achieve a good OO design which is high in cohesion and low in coupling thus easily adaptable to change
An ultimate guide to SOLID Principles, developers must know.ONE BCG
SOLID Principles represent a set of guidelines that helps us to avoid having a bad design. It is a set of design principles in object-oriented software development.
Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing and apply design principles for creating high-quality designs. This presentation provides insights gained from performing refactoring in real-world projects to improve refactoring and reduce the time and costs of managing software projects.
SOLID Principles of Refactoring Presentation - Inland Empire User GroupAdnan Masood
Abstract: SOLID is a mnemonic acronym coined by Robert C. Martin (aka Uncle Bob) referring to a collection of design principles of object-oriented programming and design. By using these principles, developers are much more likely to create a system that more maintainable and extensible. SOLID can be used to remove code smells by refactoring. In this session, you will learn about the following SOLID principles with code examples demonstrating the corresponding refactoring.
S – Single Responsibility Principle – An Object should have only one reason to change.
O – Open/Closed Principle – A software entity(module, library, routine) should be closed to any modification but be open to extension
L – Liskov Substitution Principle – Derived classes should be substitutable for the base classes
I – Interface Segregation Principle – Having more fine grained interfaces over fat interfaces
D – Dependency Inversion Principle – Depending on abstractions, not concrete implementations.
This paper briefly talks about SOLID design principles. It aims to discuss the implementation of IoC to invert dependencies. The paper explains Dependency Injection, its types and building IoC Containers in detail.
SOLID is a mnemonic device for 5 design principles of object-oriented
programs (OOP) that result in readable, adaptable, and scalable code.
S - Single Responsibility Principle.
O - Open Closed Principle.
L - Liskov Substitution Principle.
I - Interface Segregation Principle.
D - Dependency Inversion Principle.
An ultimate guide to SOLID Principles, developers must know.ONE BCG
SOLID Principles represent a set of guidelines that helps us to avoid having a bad design. It is a set of design principles in object-oriented software development.
Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing and apply design principles for creating high-quality designs. This presentation provides insights gained from performing refactoring in real-world projects to improve refactoring and reduce the time and costs of managing software projects.
SOLID Principles of Refactoring Presentation - Inland Empire User GroupAdnan Masood
Abstract: SOLID is a mnemonic acronym coined by Robert C. Martin (aka Uncle Bob) referring to a collection of design principles of object-oriented programming and design. By using these principles, developers are much more likely to create a system that more maintainable and extensible. SOLID can be used to remove code smells by refactoring. In this session, you will learn about the following SOLID principles with code examples demonstrating the corresponding refactoring.
S – Single Responsibility Principle – An Object should have only one reason to change.
O – Open/Closed Principle – A software entity(module, library, routine) should be closed to any modification but be open to extension
L – Liskov Substitution Principle – Derived classes should be substitutable for the base classes
I – Interface Segregation Principle – Having more fine grained interfaces over fat interfaces
D – Dependency Inversion Principle – Depending on abstractions, not concrete implementations.
This paper briefly talks about SOLID design principles. It aims to discuss the implementation of IoC to invert dependencies. The paper explains Dependency Injection, its types and building IoC Containers in detail.
SOLID is a mnemonic device for 5 design principles of object-oriented
programs (OOP) that result in readable, adaptable, and scalable code.
S - Single Responsibility Principle.
O - Open Closed Principle.
L - Liskov Substitution Principle.
I - Interface Segregation Principle.
D - Dependency Inversion Principle.
There are many design principles that have become best practices over the years. Using these principles we can develop scalable and maintainable enterprise application with time tested approaches.
Design Principle and Design Pattern examples on C# .NET Core.
(Note: Not all the contents are original, I copied some of them from online tutorials while learning and found great explanations. A great thanks to all for this information.)
Improving the Quality of Existing SoftwareSteven Smith
Given at DogFoodCon 2016 in Columbus, Ohio
As developers, most of our time is spent working on existing software – even if it’s just the software we wrote ourselves, yesterday. And over time, software rots. If were not diligent, our beautiful code can degrade into a worthless mess. Keeping our code in working condition is no different than changing the oil in our car “ its preventive maintenance. In this session, Steve will cover some common places to look for signs of degradation in existing applications, and describe the steps we can take to improve our code. Examples will use C# and primarily ASP.NET.
Model Attribute Check Company Auto PropertyCeline George
In Odoo, the multi-company feature allows you to manage multiple companies within a single Odoo database instance. Each company can have its own configurations while still sharing common resources such as products, customers, and suppliers.
Introduction to AI for Nonprofits with Tapp NetworkTechSoup
Dive into the world of AI! Experts Jon Hill and Tareq Monaur will guide you through AI's role in enhancing nonprofit websites and basic marketing strategies, making it easy to understand and apply.
2024.06.01 Introducing a competency framework for languag learning materials ...Sandy Millin
http://sandymillin.wordpress.com/iateflwebinar2024
Published classroom materials form the basis of syllabuses, drive teacher professional development, and have a potentially huge influence on learners, teachers and education systems. All teachers also create their own materials, whether a few sentences on a blackboard, a highly-structured fully-realised online course, or anything in between. Despite this, the knowledge and skills needed to create effective language learning materials are rarely part of teacher training, and are mostly learnt by trial and error.
Knowledge and skills frameworks, generally called competency frameworks, for ELT teachers, trainers and managers have existed for a few years now. However, until I created one for my MA dissertation, there wasn’t one drawing together what we need to know and do to be able to effectively produce language learning materials.
This webinar will introduce you to my framework, highlighting the key competencies I identified from my research. It will also show how anybody involved in language teaching (any language, not just English!), teacher training, managing schools or developing language learning materials can benefit from using the framework.
Welcome to TechSoup New Member Orientation and Q&A (May 2024).pdfTechSoup
In this webinar you will learn how your organization can access TechSoup's wide variety of product discount and donation programs. From hardware to software, we'll give you a tour of the tools available to help your nonprofit with productivity, collaboration, financial management, donor tracking, security, and more.
Macroeconomics- Movie Location
This will be used as part of your Personal Professional Portfolio once graded.
Objective:
Prepare a presentation or a paper using research, basic comparative analysis, data organization and application of economic information. You will make an informed assessment of an economic climate outside of the United States to accomplish an entertainment industry objective.
Operation “Blue Star” is the only event in the history of Independent India where the state went into war with its own people. Even after about 40 years it is not clear if it was culmination of states anger over people of the region, a political game of power or start of dictatorial chapter in the democratic setup.
The people of Punjab felt alienated from main stream due to denial of their just demands during a long democratic struggle since independence. As it happen all over the word, it led to militant struggle with great loss of lives of military, police and civilian personnel. Killing of Indira Gandhi and massacre of innocent Sikhs in Delhi and other India cities was also associated with this movement.
Palestine last event orientationfvgnh .pptxRaedMohamed3
An EFL lesson about the current events in Palestine. It is intended to be for intermediate students who wish to increase their listening skills through a short lesson in power point.
1. REFACTORING CODE TO A SOLID
FOUNDATION
Adnan Masood
http://blog.adnanmasood.com
@adnanmasood
adnanmasood@acm.org
Presented at Inland Empire .NET UG –
12/11/2012
3. CREDITS & REFERENCES
• Robert C Martin – Clean Coder https://sites.google.com/site/unclebobconsultingllc/
• Pablo’s SOLID Software Development | LosTechies.com
Derick Bailey - McLane Advanced Technologies, LLC
• PluralSight Training - SOLID Principles of Object Oriented Design
http://pluralsight.com/training/Courses/TableOfContents/principles-oo-design
• Marcin Zajączkowski - http://solidsoft.wordpress.com/
• Images Used Under License
• http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-development-principles-in-motivational-pictures.aspx
• SRP Article
• http://www.objectmentor.com/resources/articles/srp.pdf
• Solid for your Language
• http://stefanroock.files.wordpress.com/2011/09/solidforyourlanguage.pdf
4. HELP :ABOUT
Adnan Masood works as a system architect / technical lead for Green dot Corporation where he
develops SOA based middle-tier architectures, distributed systems, and web-applications using
Microsoft technologies. He is a Microsoft Certified Trainer holding several technical certifications,
including MCPD (Enterprise Developer), MCSD .NET, and SCJP-II.Adnan is attributed and published in
print media and on the Web; he also teaches Windows Communication Foundation (WCF) courses at
the University of California at San Diego and regularly presents at local code camps and user groups. He
is actively involved in the .NET community as cofounder and president of the of San GabrielValley .NET
Developers group.
Adnan holds a Master’s degree in Computer Science; he is currently a doctoral student working
towards PhD in Machine Learning; specifically discovering interestingness measures in outliers using
Bayesian Belief Networks. He also holds systems architecture certification from MIT and SOA Smarts
certification from Carnegie Melon University.
5.
6.
7.
8. ADDITIONAL RESOURCES
Uncle Bob’s Principle Of Object Oriented Development:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Pablo’sTopic OfThe Month: SOLID
http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-
s-topic-of-the-month-march-solid-principles.aspx
Agile Principles, Patterns,And Practices In C#
by Robert (Uncle Bob) Martin and Micah Martin
Pablo’s SOLID E-Book
http://www.lostechies.com/content/pablo_ebook.aspx
9. COHESION:
“A measure of how strongly-related and focused the various
responsibilities of a software module are” - Wikipedia
OBJECT ORIENTED PRINCIPLES - QUIZ
COUPLING:
“The degree to which each program module relies on each one of the
other modules” – Wikipedia
ENCAPSULATION:
“The hiding of design decisions in a computer program that are most likely
to change” -Wikipedia
12. SRP:THE SINGLE RESPONSIBILITY
PRINCIPLE
The Single Responsibility Principle states that every object should
have a single responsibility, and that responsibility should be entirely
encapsulated by the class.
Wikipedia
There should never be more than one reason for a class to change.
Robert C.“Uncle Bob” Martin
13.
14. COHESION AND COUPLING
Cohesion: how strongly-related and focused are the
various responsibilities of a module
Coupling: the degree to which each program module
relies on each one of the other modules
Strive for low coupling and high
cohesion!
15. RESPONSIBILITIES ARE AXES OF
CHANGE
Requirements changes typically map to responsibilities
More responsibilities == More likelihood of change
Having multiple responsibilities within a class couples
together these responsibilities
The more classes a change affects, the more likely the
change will introduce errors.
17. WHAT IS A RESPONSIBILITY?
“a reason to change”
A difference in usage scenarios from the
client’s perspective
Multiple small interfaces (follow ISP) can
help to achieve SRP
21. SUMMARY
Following SRP leads to lower coupling and higher cohesion
Many small classes with distinct responsibilities result in a more flexible
design
Related Fundamentals:
o Open/Closed Principle
o Interface Segregation Principle
o Separation of Concerns
Recommended Reading:
o Clean Code by Robert C. Martin [http://amzn.to/Clean-Code]
24. OCP:THE OPEN/CLOSED PRINCIPLE
The Open / Closed Principle states that
software entities (classes, modules, functions,
etc.) should be open for extension, but closed
for modification
Wikipedia
25. THE OPEN / CLOSED PRINCIPLE
Open to Extension
New behavior can be added in the future
Closed to Modification
Changes to source or binary code are not required
Dr. Bertrand Meyer originated the OCP term in his 1988
book, Object Oriented Software Construction
26. CHANGE BEHAVIORWITHOUT
CHANGING CODE?
Rely on abstractions
No limit to variety of implementations of each abstraction
In .NET, abstractions include:
Interfaces
Abstract Base Classes
In procedural code, some level of OCP can be
achieved via parameters
27. THE PROBLEM
Adding new rules require changes to the calculator every time
Each change can introduce bugs and requires re-testing, etc.
We want to avoid introducing changes that cascade through many
modules in our application
Writing new classes is less likely to introduce problems
o Nothing depends on new classes (yet)
o New classes have no legacy coupling to make them hard to design or test
28. THREE APPROACHESTO ACHIEVE
OCP
Parameters (Procedural Programming)
o Allow client to control behavior specifics via a parameter
o Combined with delegates/lambda, can be very powerful approach
Inheritance /Template Method Pattern
o Child types override behavior of a base class (or interface)
Composition / Strategy Pattern
o Client code depends on abstraction
o Provides a “plug in” model
o Implementations utilize Inheritance; Client utilizes Composition
29. WHEN DO WE APPLY OCP?
Experience Tells You
If you know from your own experience in the problem domain that a particular
class of change is likely to recur, you can apply OCP up front in your design
Otherwise – “Fool me once, shame on you; fool me twice, shame on me”
Don’t apply OCP at first
If the module changes once, accept it.
If it changes a second time, refactor to achieve OCP
Remember TANSTAAFL
There Ain’t No Such Thing As A Free Lunch
OCP adds complexity to design
No design can be closed against all changes
30. SUMMARY
Conformance to OCP yields flexibility, reusability, and maintainability
Know which changes to guard against, and resist premature abstraction
Related Fundamentals:
o Single Responsibility Principle
o Strategy Pattern
o Template Method Pattern
Recommended Reading:
o Agile Principles, Patterns, and Practices by Robert C.
Martin and Micah Martin [http://amzn.to/agilepppcsharp]
32. LSP:THE LISKOV SUBSTITUTION
PRINCIPLE
The Liskov Substitution Principle states that
Subtypes must be substitutable for their base
types.
Agile Principles, Patterns, and
Practices in C#
Named for Barbara Liskov, who first described the principle in 1988.
33.
34. SUBSTITUTABILITY
Child classes must not:
1) Remove base class behavior
2) Violate base class invariants
And in general must not require calling code to know they are
different from their base type.
35. INHERITANCE ANDTHE IS-A
RELATIONSHIP
Naïve OOP teaches use of IS-A to describe child classes’
relationship to base classes
LSP suggests that IS-A should be replaced with
IS-SUBSTITUTABLE-FOR
38. INVARIANTS
Consist of reasonable assumptions of behavior by clients
Can be expressed as preconditions and postconditions for methods
Frequently, unit tests are used to specify expected behavior of a method
or class
Design By Contract is a technique that makes defining these pre- and post-
conditions explicit within code itself.
To follow LSP, derived classes must not violate any constraints defined (or
assumed by clients) on the base classes
39. THE PROBLEM
Non-substitutable code breaks polymorphism
Client code expects child classes to work in place of
their base classes
“Fixing” substitutability problems by adding if-then
or switch statements quickly becomes a
maintenance nightmare (and violates OCP)
40. LSPVIOLATION “SMELLS”
foreach (var emp in Employees)
{
if( emp is Manager )
{
_printer.PrintManager( emp as Manager );
}
else
{
_printer.PrintEmployee( emp );
}
}
41. LSPVIOLATION “SMELLS”
public abstract class Base
{
public abstract void Method1();
public abstract void Method2();
}
public class Child : Base
{
public override void Method1()
{
throw new NotImplementedException();
}
public override void Method2()
{
// do stuff
}
}
Follow ISP!
Use small interfaces so you don’t
require classes to implement
more than they need!
42. WHEN DO WE FIX LSP?
If you notice obvious smells like those shown
If you find yourself being bitten by the OCP
violations LSP invariably causes
43. LSPTIPS
“Tell, Don’t Ask”
o Don’t interrogate objects for their internals – move behavior to the object
o Tell the object what you want it to do
Consider Refactoring to a new Base Class
o Given two classes that share a lot of behavior but are not substitutable…
o Create a third class that both can derive from
o Ensure substitutability is retained between each class and the new base
44. SUMMARY
Conformance to LSP allows for proper use of polymorphism and produces more
maintainable code
Remember IS-SUBSTITUTABLE-FOR instead of IS-A
Related Fundamentals:
o Polymorphism
o Inheritance
o Interface Segregation Principle
o Open / Closed Principle
Recommended Reading:
o Agile Principles, Patterns, and Practices by Robert C. Martin and Micah Martin
[http://amzn.to/agilepppcsharp]
46. ISP:THE INTERFACE SEGREGATION
PRINCIPLE
The Interface Segregation Principle states that
Clients should not be forced to depend on
methods they do not use.
Agile Principles, Patterns, and Practices in C#
Corollary:
Prefer small, cohesive interfaces to “fat” interfaces
47.
48. WHAT’S AN INTERFACE?
Interface keyword/type
public interface IDoSomething { … }
Public interface of a class
public class SomeClass { … }
What does the client see and use?
49. ISP: INTERFACE
SEGREGATION PRINCIPLE
“THIS PRINCIPLE DEALS WITH THE DISADVANTAGES OF ‘FAT’
INTERFACES. CLASSES THAT HAVE ‘FAT’ INTERFACES ARE CLASSES
WHOSE INTERFACES ARE NOT COHESIVE. IN OTHER WORDS, THE
INTERFACES OF THE CLASS CAN BE BROKEN UP INTO GROUPS OF
MEMBER FUNCTIONS. EACH GROUP SERVES A DIFFERENT SET OF
CLIENTS. THUS SOME CLIENTS USE ONE GROUP OF MEMBER
FUNCTIONS, AND OTHER CLIENTS USE THE OTHER GROUPS.”
- ROBERT MARTIN
53. THE PROBLEM
AboutPage simply needs ApplicationName and AuthorName
Forced to deal with huge ConfigurationSettings class
Forced to deal with actual configuration files
Interface Segregation violations result in classes that depend on
things they do not need, increasing coupling and reducing flexibility
and maintainability
54. ISP SMELLS
Unimplemented interface methods:
public override string ResetPassword(
string username, string answer)
{
throw new NotImplementedException();
}
Remember these violate Liskov Substitution Principle!
56. WHEN DO WE FIX ISP?
Once there is pain
o If there is no pain, there’s no problem to address.
If you find yourself depending on a “fat” interface you own
o Create a smaller interface with just what you need
o Have the fat interface implement your new interface
o Reference the new interface with your code
If you find “fat” interfaces are problematic but you do not own them
o Create a smaller interface with just what you need
o Implement this interface using an Adapter that implements the full interface
57. ISPTIPS
Keep interfaces small, cohesive, and focused
Whenever possible, let the client define the interface
Whenever possible, package the interface
with the client
o Alternately, package in a third assembly client and
implementation both depend upon
o Last resort: Package interfaces with their implementation
58. SUMMARY
Don’t force client code to depend on things it doesn’t need
Keep interfaces lean and focused
Refactor large interfaces so they inherit smaller interfaces
Related Fundamentals:
o Polymorphism
o Inheritance
o Liskov Substitution Principle
o Façade Pattern
Recommended Reading:
o Agile Principles, Patterns, and Practices by Robert C. Martin and
Micah Martin [http://amzn.to/agilepppcsharp]
60. DIP: DEPENDENCY INVERSION
PRINCIPLE
“WHAT IS IT THAT MAKES A DESIGN RIGID, FRAGILE AND IMMOBILE? IT IS THE
INTERDEPENDENCE OF THE MODULES WITHIN THAT DESIGN. A DESIGN IS RIGID IF
IT CANNOT BE EASILY CHANGED. SUCH RIGIDITY IS DUE TO THE FACT THAT A
SINGLE CHANGE TO HEAVILY INTERDEPENDENT SOFTWARE BEGINS A CASCADE OF
CHANGES IN DEPENDENT MODULES.”
- ROBERT MARTIN
61. DIP:THE DEPENDENCY INVERSION
PRINCIPLE
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.
o Agile Principles, Patterns, and Practices in C#
67. EXAMPLE APP: CONSTRUCTOR DEPENDENCIES IN A PROCESSING SERVICE
DIP: DEPENDENCY
INVERSION
PRINCIPLE
68. WHAT ARE DEPENDENCIES?
Framework
Third Party Libraries
Database
File System
Email
Web Services
System Resources (Clock)
Configuration
The new Keyword
Static methods
Thread.Sleep
Random
69. TRADITIONAL PROGRAMMING AND
DEPENDENCIES
High Level Modules Call Low Level Modules
User Interface depends on
o Business Logic depends on
o Infrastructure
o Utility
o Data Access
Static methods are used for convenience or as Façade layers
Class instantiation / Call stack logic is scattered through all modules
o Violation of Single Responsibility Principle
70. CLASS DEPENDENCIES: BE HONEST!
Class constructors should require any dependencies the class needs
Classes whose constructors make this clear have explicit dependencies
Classes that do not have implicit, hidden dependencies
public class HelloWorldHidden
{
public string Hello(string name)
{
if (DateTime.Now.Hour < 12) return "Good morning, " + name; if (DateTime.Now.Hour
< 18) return "Good afternoon, " + name; return "Good evening, " + name;
}
}
71. CLASSES SHOULD DECLARE WHAT
THEY NEED
public class HelloWorldExplicit
{
private readonly DateTime _timeOfGreeting;
public HelloWorldExplicit(DateTime timeOfGreeting)
{
_timeOfGreeting = timeOfGreeting;
}
public string Hello(string name)
{
if (_timeOfGreeting.Hour < 12) return "Good morning, " + name;
if (_timeOfGreeting.Hour < 18) return "Good afternoon, " + name;
return "Good evening, " + name;
}
}
72. THE PROBLEM
Order has hidden dependencies:
o MailMessage
o SmtpClient
o InventorySystem
o PaymentGateway
o Logger
o DateTime.Now
Result
o Tight coupling
o No way to change implementation details (OCP violation)
o Difficult to test
73. DEPENDENCY INJECTION
Dependency Injection is a technique that is used to allow calling code to inject
the dependencies a class needs when it is instantiated.
The Hollywood Principle
o “Don’t call us; we’ll call you”
Three PrimaryTechniques
o Constructor Injection
o Property Injection
o Parameter Injection
Other methods exist as well
74. CONSTRUCTOR INJECTION
Dependencies are passed in via constructor
Strategy
Pattern
Pros
o Classes self-document what they need to perform their work
o Works well with or without a container
o Classes are always in a valid state once constructed
Cons
o Constructors can have many parameters/dependencies (design smell)
o Some features (e.g. Serialization) may require a default constructor
o Some methods in the class may not require things other methods require (design smell)
75. PROPERTY INJECTION
Dependencies are passed in via a property
o Also known as “setter injection”
Pros
o Dependency can be changed at any time during object lifetime
o Very flexible
Cons
o Objects may be in an invalid state between construction and setting of dependencies via
setters
o Less intuitive
76. PARAMETER INJECTION
Dependencies are passed in via a method parameter
Pros
o Most granular
o Very flexible
o Requires no change to rest of class
Cons
o Breaks method signature
o Can result in many parameters (design smell)
Consider if only one method has the dependency, otherwise prefer constructor
injection
78. DIP SMELLS
Use of new keyword
foreach(var item in cart.Items)
{
try
{
var inventorySystem = new InventorySystem();
inventorySystem.Reserve(item.Sku, item.Quantity);
}
}
79. DIP SMELLS
Use of static methods/properties
message.Subject = "Your order placed on " +
DateTime.Now.ToString();
Or
DataAccess.SaveCustomer(myCustomer);
80. WHERE DOWE INSTANTIATE
OBJECTS?
Applying Dependency Injection typically results in many interfaces that eventually need to be instantiated
somewhere… but where?
Default Constructor
o You can provide a default constructor that news up the instances you
expect to typically need in your application
o Referred to as “poor man’s dependency injection” or “poor man’s IoC”
Main
o You can manually instantiate whatever is needed in your application’s
startup routine or main() method
IoC Container
o Use an “Inversion of Control” Container
81. IOC CONTAINERS
Responsible for object graph instantiation
Initiated at application startup via code or configuration
Managed interfaces and the implementation to be used are
Registered with the container
Dependencies on interfaces are Resolved at application startup
or runtime
Examples of IoC Containers for .NET
o Microsoft Unity
o StructureMap
o Ninject
o Windsor
o Funq / Munq
82. SUMMARY
Depend on abstractions.
Don’t force high-level modules to depend on low-level modules through direct
instantiation or static method calls
Declare class dependencies explicitly in their constructors
Inject dependencies via constructor, property, or parameter injection
Related Fundamentals:
o Single Responsibility Principle
o Interface Segregation Principle
o Façade Pattern
o Inversion of Control Containers
Recommended Reading:
o Agile Principles, Patterns, and Practices by Robert C. Martin and Micah Martin
[http://amzn.to/agilepppcsharp]
o http://www.martinfowler.com/articles/injection.html
85. THE PROBLEM
Dependencies FlowToward Infrastructure
Core / Business / Domain Classes Depend on Implementation
Details
Result
o Tight coupling
o No way to change implementation details without recompile (OCP violation)
o Difficult to test
86. DEPENDENCY INJECTION
Dependency is transitive
o If UI depends on BLL depends on DAL depends on Database Then *everything*
depends on the Database
Depend on abstractions (DIP)
Package interfaces (abstractions) with the client (ISP)
Structure Solutions and Projects so Core / BLL is at center,
with fewest dependencies
87. SUMMARY
Don’t Depend on Infrastructure Assemblies from Core
Apply DIP to reverse dependencies
Related Fundamentals:
o Open Closed Principle
o Interface Segregation Principle
o Strategy Pattern
Recommended Reading:
o Agile Principles, Patterns, and Practices by Robert C. Martin and Micah Martin [http://amzn.to/agilepppcsharp]
o http://www.martinfowler.com/articles/injection.html
88.
89. DON’T REPEATYOURSELF
“Every piece of knowledge must have a single, unambiguous
representation in the system.”
The Pragmatic Programmer
“Repetition in logic calls for abstraction. Repetition in process calls
for automation.”
97Things Every Programmer Should
Know
Variations include:
Once and Only Once
Duplication Is Evil (DIE)
95. SUMMARY
Repetition breeds errors and waste
Refactor code to remove repetition
Recommended Reading:
o The Pragmatic Programmer: From Journeyman to Master http://amzn.to/b2gJdK
o 97 Things Every Programmer Should Know http://amzn.to/cAse1Y
96. STATIC METHODS
Tightly coupled
Difficult to test
Difficult to change behavior (violates OCP)
Cannot use object oriented design techniques
o Inheritance
o Polymorphism
97. SUMMARY
Repetition breeds errors and waste
Abstract repetitive logic in code
Related Fundamentals:
o Template Method Pattern
o Command Pattern
o Dependency Inversion Principle
Recommended Reading:
o The Pragmatic Programmer: From Journeyman to Master http://amzn.to/b2gJdK
o 97Things Every Programmer Should Know http://amzn.to/cAse1Y
99. DUPLICATE, COPY PASTED CODE
Too Numerous to List
CommercialTool (free version available)
o Atomiq (http://GetAtomiq.com)
100. CONSIDER CODE GENERATION
T4Templates
o Custom code generation templates
o Built intoVisual Studio 2010
ORMTools (LINQ to SQL, Entity Framework, nHibernate, LLBLGen)
o Reduce repetitive data access code
o Eliminate common data access errors
CommercialTools:
o CodeSmith
o CodeBreeze
o CodeHayStack
101. REPETITION IN PROCESS
Testing
o Performing testing by hand is tedious and wasteful
Builds
o Performing builds by hand is tedious and wasteful
Deployments
o Performing deployments by hand is tedious and wasteful
Are you seeing a trend here?
String.Format(“Performing {0} by hand is tedious and wasteful”,action);
102. SUMMARY
Repetition breeds errors and waste
Use an ORM tool to eliminate repeated data access code
UseTools to Locate Repeated Code
Automate repetitive actions in your processes
Recommended Reading:
o The Pragmatic Programmer: From Journeyman to Master http://amzn.to/b2gJdK
o 97 Things Every Programmer Should Know http://amzn.to/cAse1Y
RelatedTool
o Atomiq http://GetAtomiq.com