The Open-Closed Principle - the Original Version and the Contemporary Version

The Open Closed Principle Part I The Original Version ©
2014 Philip Schwarz https://twitter.com/philip_schwarz [email protected] This work is licensed under a Creative Commons Attribution-‐NonCommercial-‐NoDerivs 3.0 Unported License.

Tension Between known needs of today changes that
will arrive in the future Sandi Metz The Fundamental Target of Design

Code needs to work today just once, and
it needs to be easy to change forever

It is at this point of tension where design matters
today’s needs future changes

its purpose, its entire reason for being, is to
reduce the cost of change.

1999 3rd Apr 2014 @KentBeck design is irrelevant for
today. it only matters when we want to change the software... @KentBeck change is the only reason to organize software at all… Kent Beck

adopted by agile community as a truth about
software development Henrik Christensen 2010

“software must be designed and developed to make it
easy to change”

Let’s examine software qualities that enable ease of change
Look for definitions in ISO 9126 Projects sometimes fail due to not having any clear definitions of "success” This standard tries to develop a common understanding of project objectives and goals, e.g. software qualities

Software is Reliabile if it can maintain a specific
level of performance under specific usage conditions

in our setting… In particular, we are interested in
preserving reliability in the face of change Software is Reliabile if it can perform the required functions without failing

“maintainability is composed of several, finer grained, qualities”

Analysability Maintainability Changeability Stability Testability Software is Analysable if you
can • diagnose it for § deficiencies § causes of failure • identify the parts to be modified “Analysability is basically the ability to understand software”

Analysability Maintainability Changeability Stability Testability Software is changeable if it
allows you to • implement a specific modification • add, modify, or enhance a feature at a reasonable cost “almost all Design Patterns are geared towards increasing design’s changeability”

Analysability Maintainability Changeability Stability Testability “Software is flexible if you
can add/enhance functionality purely by adding software units and specifically not by modifying existing software units” Flexibility a special case of changeability

Changeability Behavioural changes that are introduced by modifying existing
production code Changeability is a desirable quality, but it relies on Change by Modification Change by Modification “The less I ever modify a class, the higher the probability that it will remain free of defects” Modifications carry the risk of introducing defects, and the necessary cost of avoiding them: testing, code reviewing, etc.

Behavioural changes that are introduced by modifying existing production
code Change by Modification Change by Addition Behavioural changes that are introduced by adding new production code instead of modifying existing code Contrast Change by Addition avoids (risky) modifications altogether with

Changeability Change by Addition Change by Modification Changeability
does not take a stand point with regards to the way a specified modification is implemented Flexibility In contrast, Flexibility does take this stand point and requires that no modifications are made

Analysability Maintainability Changeability Stability Testability Software is Stable if it
avoids unexpected effects when modified “I advocate the practice to avoid modifying existing code but preferably add features or modify existing ones by other means” Flexibility “any change to existing software carries a risk of introducing defects”

Changeability Stability Flexibility Reliability Change by Modification Change by
Addition -‐ + -‐ + Summary + supports -‐ risks undermining relies on

Question: how do we promote flexibility, reliability and stability
in our software? Analysability Maintainability Changeability Stability Testability Flexibility Reliability

Answer: we favour ‘Change by Addition’ over ‘Change
by Modification’ Changeability Stability Flexibility Reliability Change by Modification Change by Addition -‐ + -‐ +

I cover techniques that focus on flexibility Christensen
if you require that s/w can adapt to changing requirements without modifying the production code then you need to employ a SPECIAL set of design and programming techniques as well as adopt a SPECIAL mindset

“Another way of characterising Change by Addition that you may
come across is the Open Closed Principle” How do we achieve ? Change by Addition

The Open-‐Closed Principle Modules should be both open and closed
Bertrand Meyer Object Oriented Software Construction The most comprehensive, definitive OO reference ever published 1988

Isn’t there a contradiction between the two terms? Modules should
be both OPEN and CLOSED ¬(p ∧ ¬p)

The contradiction is only apparent The two terms correspond
to goals of a different nature e.g. a Dutch door can be both OPEN and CLOSED It is a

So let’s look at the goals of the OCP OCP

A module is said to be OPEN if
it is still available for extension or add fields to its data structures Data Structures fields + operations e.g. it should be possible to expand its set of operations

A module is said to be CLOSED If
it is available for use by other modules Has a well-‐defined, stable description (its interface – in information hiding sense) public part secret part interface 1 can be compiled, stored in a library, and made available for clients to use 2 in the case of a design or specification module: • approved • baselined in version control • its interface published for benefit of other module authors 3

OPEN if it is still available for extension
CLOSED If it is available for use by other modules Recap – A module is…

It is impossible to foresee all the elements that
a module will need in its lifetime X The need for ness so developers wish to keep the module open for as long as possible so that they can address changes, and extensions by changing elements or adding new elements

The need for ness if a module is
never closed until it is certain that it contains all the needed features x every developer would always be waiting for completion of another developer's job then multi-‐module s/w can never reach completion x in a system consisting of many modules, most modules will depend on some others but it is also necessary to close modules

Modules should be both open and closed We want modules
to be both for extension and for modification

the two goals of openness and closedness with traditional
techniques are incompatible

either you keep a module open and others cannot
use it yet and any change or extension can trigger a painful chain reaction of changes or you close it in many other modules which relied on the original module directly or indirectly

A B C D E A module and its clients
A’ F G H I New clients which need A’, an adapted or extended version of A Typical situation where the needs for Open and Closed modules are hard to reconcile = client of

With non-‐OO methods, there seem to be only 2
solutions, equally unsatisfactory

A B C D E A F G H I
Solution 1

A B C D E A’ F G H I
Solution We have taken a copy of A and modified it, turning it into the desired A’

Solution Meyer’s Assessment the consequences are appalling an explosion of
variants of the original module, many of them very similar, but never quite identical if you extrapolate its effects to • many modules • many modification requests • a long period of time

Solution (Source tree copy) Christensen’s Assessment Probably the main reason
it is encountered so often in practice Easy to explain to colleagues & new developers No implementation interference X

Solution (Source tree copy) Christensen’s Assessment Quick but very dangerous
In the long run it is often a real disaster… The solution has severe limitations.

because it leads to the multiple maintenance problem

Solution (Source tree copy) Christensen’s Assessment when you want to
add/modify logic you have to: • Do it for each source tree • Write the same test cases for each source tree you have to do it in each source tree when you need to remove a defect

DRIFT Practice shows that over time the source trees
evolve into completely different directions: they drift apart. After a while it is more or less like maintaining a set of completely different applications At that point, before you do any of the operations, you have to first analyse each source tree!!

Used in airports to generate reports of local weather one
variant for each airport in Denmark init and config code Example SAWOS -‐ Semi Automatic Weather Observation System 8 copies!!!

Analysability Stability Reliability solution -‐ -‐ -‐ Summary multiple maintenance
problem

That was Meyer’s first unsatisfactory solution to the problem of
making modules both OPEN and CLOSED Let’s turn to the second one

A module and its clients New clients which need A’, an adapted or extended version of A = client of Problem

Solution 2 A B C D E A’ F G
H I Change by Modification

A+ B C D E A’ F G H I
We have modified A into A+, which can switch between two modes of execution In one mode it behaves like A, and in the other it behaves as expected of A’ Solution

if (variant == VARIANT_1) then { …. } else { …. } At points of variation, A+ looks like this: We have modified A into A+, which can switch between two modes of execution In one mode it behaves like A, and in the other it behaves as expected of A’ Alternatively, this can be a switch Solution

Solution – Meyer’s Assessment

The potential for disaster is obvious: changes to A may invalidate the assumptions on the basis of which the old clients used A. So the changes may start a dramatic series of changes in clients, client of clients....etc Solution – Meyer’s Assessment

A+ A’ F G H I Solution – Meyer’s Assessment
The potential for disaster is obvious: changes to A may invalidate the assumptions on the basis of which the old clients used A. So the changes may start a dramatic series of changes in clients, client of clients....etc B C E D this is a nightmare for the proj. mgr. the system regresses and several modules have to be re-‐ opened for dev/test/debug/documentation

Even though the Change solution has this problematic ripple
effect, it is still better than the Copy solution. On the surface, the copy solution seems better because it avoids the ripple effect of change but in fact it may even be more catastrophic…it only postpones the day of reckoning We saw earlier the risks of an explosion of variants, many of them very similar, but never quite identical: Solution – Meyer’s Assessment solution solution

Solution (Parametric solution) Christensen’s Assessment Conditionals are easy to understand.
So approach is easy to describe to other developers. Avoids Multiple Maintenance Problem Only one code base to maintain solution solution

Liabilities, most of which deal with long term maintainability Change
by Modification Reliability Concerns – solution relies on with risk of introducing new defects Analysability concerns – as more and more requirements are handled by parameter switching, the code becomes less easy to analyse … Responsibility erosion – the software has, without much notice, been given an extra responsibility drives towards Procedural Design Blob aka God Class Solution (Parametric solution) Christensen’s Assessment

A reasonable approach at first, but one with serious problems
for applications that need to grow over time Solution (Switches) Shalloway’s Assessment Not too bad as long as you just keep adding cases… 2004

but soon you need to introduce fall-‐throughs… …and then the
switches are not as nice as they used to be

Eventually you need to start adding variations within a case.
I like to call this switch The flow of the switches themselves becomes confusing, hard to read, hard to decipher. When a new case comes in the programmer must find every place it can be involved (often finding all but one of them). Suddenly things get bad in a hurry.

Analysability Stability Reliability solution -‐ -‐ -‐ Summary Analysability Stability
Reliability solution -‐ -‐ -‐ With non-‐OO methods, there are only only 2 solutions available to us, BOTH UNSATISFACTORY multiple maintenance problem Change by Modification CHANGE COPY

If non-‐OO methods are all we have, then Meyer
says we face a change or copy dilemma CHANGE COPY

So how can we have modules that are both and ? How can we keep A and everything in the top part of the figure unchanged, … …while providing A’ to the bottom clients, and avoiding duplication of software?

With the OO concept of inheritance Inheritance allows us to get out of the CHANGE OR COPY dilemma… …because inheritance allows us to define a new module A' in terms of an existing module A, …by stating only the differences between the two A’ defines new features, and redefines (i.e. modifies) one or more of A’s features inherits from Change by Addition

Thanks to inheritance, OO developers can adopt a much more
incremental approach to software development than used to be possible with earlier methods OO inheritance

Hacking = Slipshod approach to building and modifying code Slipshod
= Done poorly or too quickly;; careless. The Hacker may seem bad but often his heart is pure.

He sees a useful piece of software, which is almost
able to address the needs of the moment, more general than the software’s original purpose. Hacker Spurred by a laudable desire not to redo what can be reused, our hacker starts modifying the original to add provisions for new cases solution

The impulse is good but the effect is often
to pollute the software with many clauses of the form if that_special_case then… if (<special case D>) then … if (<special case C>) then … if (<special case B>) then … if (<special case A>) then … switch

so that after a few rounds of hacking, perhaps by
different hackers, the software starts resembling a chunk of Swiss cheese that has been left outside for too long in August – it has both holes and growth Hacking

Open-Closed Principle = One way to describe the OCP and
the consequent OO techniques is to think of them as organised hacking Hacking The organised form of hacking will enable us to cater to the variants without affecting the consistency of the original version. Inheritance Change by Modification Change by Addition

if you have control over original s/w and
can rewrite it so that it will address the needs of several kinds of clients …you should do so Caveats at no extra complication

The OCP principle and associated techniques are intended for the
adaptation of healthy modules If there is something wrong with a module you should fix it… …not leave the original alone and try to correct the problem in the derived module Derived Base neither OCP nor redefinition in inheritance is a way to address design flaws, let alone bugs Design Flaw

its purpose, its entire reason for being, is to
reduce the cost of change.

Question: how do we promote flexibility, reliability and stability
in our software? Analysability Maintainabilit y Changeability Stability Testability Flexibility Reliability

Answer: we favour ‘Change by Addition’ over ‘Change
by Modification’ Changeability Stability Flexibility Reliability Change by Modification Change by Addition -‐ + -‐ +

How do we achieve
? Change by Addition which uses OO inheritance Inheritance We apply the Open-‐Closed Principle

multiple maintenance problem Change by Modification CHANGE solution COPY
solution Hacker Change by Addition OCP solution Chooses Chooses switch

The Open Closed Principle Part 2 An Introduction to the
Contemporary Version © 2015 Philip Schwarz https://twitter.com/philip_schwarz [email protected] This work is licensed under a Creative Commons Attribution-‐NonCommercial-‐NoDerivs 3.0 Unported License.

multiple maintenance problem Change by Modification CHANGE solution COPY
solution Hacker Change by Addition OCP solution Chooses Chooses switch extends is evil!!!!! But…

extends is evil!!!!! But, using inheritance is no longer the
main approach to satisfying the OCP Allen Holub 2004 2003

Using inheritance is still one of the ways of satisfying
the OCP, and was considered THE approach for a long while Why extends is evil 1988 -‐ 1st ed. 1997 – 2nd ed. 1995 That started changing with the emergence of the design techniques presented in Design Patterns 2003 2004

“One major value of studying patterns is that they
all, whatever else is true about them, tend to be more open-‐closed than the alternatives” 2008 1995

An object's class defines how the object is implemented (state
and operation implementation) It's important to understand the difference between an object's class and its type An object's type only refers to its interface -‐ the set of requests to which it can respond

Of course, there is a close relationship between class and
type. Because a class defines the operations it can perform, it also defines the object's type. public class Person { private String name; private Date birthdate; public Person(String name, Date birthdate) { this.name = name; this.birthdate = birthdate } public String getName() { return name; } public String getBirthdate() { return birthdate ; } } Any class C, implicitly forms a type C. Languages like C++ and Eiffel use classes to specify BOTH an object's type AND it's implementation.

An object can have many types Objects of different classes
can have the same type

Generalization: a relationship between a more specific and a more
general description, used for inheritance and polymorphic type declarations Realization: a relationship between a specification and its implementation Derived inherits implementation from Base Derived inherits type (interface) from Base Derived inherits type from Base Current and future specializations of Base are substitutable for Base in clients Current and future realizations are substitutable for Base in clients “[in a Type hierarchy] the supertype’s behavior must be supported by the subtypes: subtype objects can be substituted for supertypeobjects without affecting the behavior of the using code.” Liskov Substitution Principle (Barbara Liskov – 1988)

It's also important to understand the difference between class
inheritance and interface inheritance (or subtyping) In contrast, interface inheritance (or subtyping) describes when an object can be used in place of another Class inheritance defines an object's implementation in terms of another object's implementation. In short, it's a mechanism for code and representation sharing Class Inheritance AND Interface Inheritance JUST Interface Inheritance

It's easy to confuse these two concepts, because many
languages don't support the distinction between [them] In languages like C++ and Eiffel, inheritance means BOTH interface inheritance and implementation inheritance [ interface inheritance and implementation inheritance]

If Java were like C++, it would only support realization
with extends Class Inheritance AND Interface Inheritance JUST Interface Inheritance

Most statically typed OO languages conflate the two concerns of
inheritance and subtyping into a single mechanism. That's a kludge. Interfaces decouple the two concerns – Nat Pryce The interface construct is one the few things that Java really got right (that and GC) – Steve Freeman But Java improves on C++ by also supporting realization with implements Class Inheritance AND Interface Inheritance JUSTInterface Inheritance JUSTInterface Inheritance

James Gosling was once asked "if you could do
java over again, what would you change?" His answer: "I'd leave out classes" After the laughter died down, he explained that the real problem wasn't classes per se but rather implementation inheritance (the extends relationship). Class Inheritance AND Interface Inheritance JUST Interface Inheritance JUST Interface Inheritance Interface inheritance (the implements relationship) is much preferred. Avoid implementation inheritance whenever possible.

Although most programming languages don't support the distinction
between interface [inheritance] and implementation inheritance, people make the distinction in practice Many of the design patterns Depend on this distinction

The GoF broke the patterns into two scopes CLASS PATTERNS
require implementation inheritance (extends) to be reified OBJECT PATTERNS should be implemented using nothing but interface inheritance (implements)

GoF Design Patterns implementation inheritance interface inheritance

Template Method Pattern Object Modeling Technique
Unified Modeling Language implementation inheritance

Strategy Pattern OMT UML interface inheritance

The GoF Design Patterns book is, in fact, largely about
replacing implementation inheritance (extends) with interface inheritance (implements) Allen Holub 2004 It's not an accident that there are many more Object patterns than Class patterns. implementation inheritance interface inheritance

Robert Martin (Uncle Bob) 2002 Single Responsibility Principle Open Closed
Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle Rigidity. The design is difficult to change. Fragility. The design is easy to break. Immobility. The design is difficult to reuse. Viscosity. It is difficult to do the right thing. Needless complexity. Overdesign. Needless repetition. Mouse abuse. Opacity. Disorganized expression. Symptoms of poor design (or Design Smells): Often, the smell is caused by the violation of one or more OO Design Principles: OO Design Principles help developers eliminate Design Smells The Contemporary Version of the OCP

Modules that conform to OCP have two primary attributes: The
Contemporary Version of the OCP Robert Martin (Uncle Bob) Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. • They are open for extension. This means that the behavior of the module can be extended. As the requirements of the application change, we can extend the module with new behaviors that satisfy those changes. In other words, we are able to change what the module does. • They are closed for modification. Extending the behavior of a module does not result in changes to the source, or binary, code of the module. The binary executable version of the module…remains untouched.

The notion that a class is not coupled to another
concrete class or class that can be instantiated. Instead, the class is coupled to other base, or abstract, classes. Kirk Knoernschild Account class is coupled at the abstract level to the AccountType inheritance hierarchy So we can extend the AccountType class, creating a new class such as MoneyMarket, without having to modify our Account class. We have achieved OCP and now can extend our system without modifying its existing code base. Account isn't directly coupled to either of the concrete Savings or Checking classes 2001 In Java, this abstract class can be either a class with the abstract modifier or a Java interface data type. At the heart of the contemporary OCP there is the concept of abstract coupling.

Depend upon abstractions. Do not depend upon concretions. DIP formalizes
the concept of abstract coupling and clearly states that we should couple at the abstract level, not at the concrete level • There exists a striking similarity between DIP and OCP. In fact, these two principles are closely related • High-level modules should not depend on low-level modules. Both should depend on abstractions. DIP: The Dependency-Inversion Principle • Abstractions should not depend on details. Details should depend on abstractions. • Fundamentally, DIP tells us how we can adhere to OCP • if OCP is the desired end, DIP is the means through which we achieve that end.

AccountType is abstract, so the coupling of Account to
AccountType is abstract coupling, and so is the coupling of Savings and Checking to AccountType High-‐level module Account does not depend on low-‐level modules Savings and Checking. Account, Savings and Checking, all depend on an abstraction: AccountType. DIP

LSP: Subclasses should be substitutable for their base classes Think
of LSP as an extension to OCP The LSP is one of the prime enablers of OCP X In order to take advantage of LSP, we must adhere to OCP because violations of LSP also are violations of OCP but not vice versa X X But why?

every violation of the LSP is a latent violation of
the OCP because in order to repair the damage … we are going to have to add if statements and hang dependencies upon subtypes Untrustworthy hierarchies [those violating the LSP] force objects that interact with them to know their quirks when asked to use one … [inexperienced developers] will embed knowledge of its quirks into their own code if (bicycle instanceof MountainBike) { // do XYZ } if (bicycle instanceof MountainBike) { // do XYZ } if (bicycle instanceof MountainBike) { // code that knows about } often by explicitly checking the classes of objects X X Change by Modification

In its simplest form, LSP is difficult to differentiate from
OCP, but a subtle difference does exist. Savings and Checking are substitutable for AccountType OCP is centered around abstract coupling. LSP, while also heavily dependent on abstract coupling, is in addition heavily dependent on preconditions and postconditions, which is LSP's relation to Design by Contract LSP

Abstract coupling is “Program to an interface, not an implementation”
Abstract Coupling the means through which LSP achieves its flexibility the mechanism required for DIP and the heart of OCP

The Template Method and Strategy patterns are the most
common ways of satisfying OCP Template Method Pattern Strategy Pattern Is one as good as the other? Can they be used interchangeably? interface inheritance implementation inheritance

“it is easy to confuse implementation inheritance with interface inheritance
because many languages don’t support the distinction between them” “The GoF Design Patterns book is, in fact, largely about replacing implementation inheritance (extends) with interface inheritance (implements)” “Template Method has little to recommend it in most situations. Strategy for example, typically provides a better alternative.” “Many of the design patterns Depend on this distinction” Interface inheritance (the implements relationship) is much preferred. Avoid implementation inheritance whenever possible.

“Another way of characterizing Change by Addition that you
may come across is the Open Closed Principle” “Meyer is generally credited as having originated the term [OCP], however his focus (being in the golden days of OO inheritance) was on the polymorphic approach” Template Method Pattern Polymorphic solution Change by Addition OCP solution Organized Hacking CHANGE solution COPY solution Source code copy solution Parametric solution multiple maintenance problem Change by Modification Strategy Pattern Compositional solution You encapsulatethe variability points in instance methods. These can then be overridden in subclasses, one for each required variant You encapsulate the variability points in a well defined interface and use delegation to compose the overall behaviour. Concrete classes, implementing the interface, define the variants’ behaviour. Change by Addition Change by Addition

By 1995, it was clear that [implementation] inheritance was very
easy to overuse and that overuse of inheritance was very costly. [The Gang of Four] went so far as to stress: [Template Method and Strategy are] two patterns that epitomize the difference between inheritance and delegation. They solve similar problems and can often be used interchangeably So we cut back on our use of [implementation] inheritance, often replacing it with composition or delegation. “Favourobject composition over class inheritance” Prevents us from making one of the most catastrophic mistakes that contribute to the demise of an object-‐oriented system: using inheritance as the primary reuse mechanism The Composite Reuse Principle

“These two patterns represent a clear separation of generic functionality
from the detailed implementation of that functionality”. The STRATEGYpattern provides one extra benefit over the TEMPLATE METHODpattern. In order to conform to the DIP, we want to make sure that the generic algorithm does not depend on the detailed implementation. Strategy Pattern Template Method Pattern

The sorting algorithm consists of: 1) Generic high level
steps Can be used to sort items of any type 2) Detailed operations/steps Operate on items of a specific type Strategy Pattern Template Method Pattern

The TEMPLATE METHOD pattern allows a generic algorithm to manipulate
many possible detailed implementations, But Template Method partially violates the DIP because it uses implementation inheritance so the detailed implementations don't depend on an abstraction they depend on the generic algorithm and so they are inextricably bound to it and cannot be reused by other generic algorithms High-‐level modules should not depend on low-‐level modules. Both should depend on abstractions. BubbleSorter’s doSort() method satisfies the DIP because it depends on abstract methods outOfOrder() and swap() DoubleBubbleSorter and IntegerBubbleSorter do not satisfy the DIP because they depend on BubbleSorter, which is NOT an abstraction since it contains a concrete generic algorithm DIP X Design Smell: Immobility Template Method Pattern

The Strategy pattern fully conforms to the DIP because it
uses interface inheritance so the detailed implementations do depend on an abstraction(the interface), so the detailed implementations can be manipulated by (reused for) many different generic algorithms Strategy has this additional benefit over Template Method High-‐level modules should not depend on low-‐level modules. Both should depend on abstractions. DIP Not only does BubbleSorter satisfy the DIP, because its sort() method depends on interface SortHandler, i.e. an abstraction but IntegerSortHandler and DoublSortHandler also satisfy the DIP, because they also depend on the SortHandler abstraction Strategy Pattern

inherits from (OO inheritance) Original OCP The original version of
the OCP used implementation inheritance While the contemporary version of the OCP mostly uses interface inheritance, it sometimes does use implementation inheritance realization Contemporary OCP generalization +

In many ways, the OCP is at the heart of
object-‐oriented design Conformance to this principle is what yields the greatest benefits claimed for OO technology: flexibility, reusability, and maintainability [it is not] a good idea to apply rampant abstraction to every part of the application. Rather, it requires a dedication on the part of the developers to apply abstraction only to those parts of the program that exhibit frequent change. Resisting premature abstraction is as important as abstraction itself.

https://cleancoders.com/episode/clean-‐code-‐episode-‐10/view

References All images sourced from http://www.google.co.uk/advanced_image_search, so see there for
details of which are subject to copyright Object-‐Oriented Software Construction – by Bertrand Meyer; Publication Date: 3 April 1997 | ISBN-‐10: 0136291554 | ISBN-‐13: 978-‐0136291558 | Edition: 2 Flexible, Reliable Software: Using Patterns and Agile Development – by Henrik B. Christensen; Publication Date: 11 May 2010 | ISBN-‐10: 1420093622 | ISBN-‐13: 978-‐1420093629 Design Patterns Explained: A New Perspective on Object-‐Oriented Design; by Alan Shalloway; Publication Date: 12 Oct 2004 | ISBN-‐10: 0321247140 | ISBN-‐13: 978-‐0321247148 | Edition: 2 Less -‐ The Path to Better Design; by Sandi Metz at GoRuCo 2011 goruco_2011_-‐_sandi_metz_-‐_less_-‐ _the_path_to_better_design_1280x720.mp4 Why Extends is Evil -‐ Improve your code by replacing concrete base classes with interfaces; by Allen Holub; http://www.javaworld.com/article/2073649/core-‐java/why-‐extends-‐is-‐evil.html

The Open-Closed Principle - the Original Versio...

The Open-Closed Principle - the Original Version and the Contemporary Version

More Decks by Philip Schwarz

Other Decks in Programming

Featured

Transcript