Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Design Patterns

Advantages of Design Patterns

Andrew Soanes

on 25 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Design Patterns

Design Patterns OO Provides a lot of benefits only if
they follow good design principles. Simply using Object Orientation is not enough!
Prepared by Andrew Soanes
Bell Canada Design Patterns allow:- Reusable, Extensible and Maintainable code.
Use of Proven OO experience.
Address Issues with Changes in Software.
Shared Language between developers.
Greater time to be spent in Design than in the
low level details. Mario has a lot of abilities Boot Suit Frog Suit Penguin Suit Tanooki Suit Here's an example Fire Suit Cape Through the normal Object Orientation approach (i.e. the wrong way) Let's Design It! Character display()
loseLife() Mario run()
abstract doSpecial() doSpecial() {
} Fire Mario Star Mario doSpecial() {
} Raccoon Mario doSpecial() {
} Regular Mario doSpecial() {
//do nothing
} Big Mario Small Mario Costume Mario doSpecial() {
//do nothing
} doSpecial() {
//do nothing
} doSpecial() {
//do nothing
} Change is the only constant in software development What's wrong with this design? Forces us to override methods that do nothing!
Adds redundant code.
Makes the code confusing.
Reduces the readability.
Impacts the maintainability of the project.
Reduces flexibility. Identify the aspects that change and separate them from those that don't.
Program to an interface, not an implementation.
Favour composition over inheritance. What principles should we follow? Strategy Pattern: "Defines a family of Algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it." Here's the Redesigned solution Character display()
loseLife() Mario SpecialAbility sa
doSpecial() Abstract Class Abstract Class <<Interface>> Special Ability doSpecial() doSpecial() {
} Fire Ability doSpecial() {
} Frog Ability doSpecial() {
} Raccoon Ability doSpecial() {
//do nothing
} NoAbility Let's compare code sa.setSpecialAbility = new FireAbility(); Fire Mario Star Mario sa.setSpecialAbility = new StarAbility(); Raccoon Mario sa.setSpecialAbility = new RaccoonMario(); Regular Mario sa.setSpecialAbility = new NoAbility(); Basic OO Approach Design Pattern abstract class Mario {
abstract doSpecial();

class FireMario extends Mario {
doSpecial() {
} abstract class Mario {
SpecialAbility sa;
doSpecial() {

class FireMario extends Mario {
sa.setSpecialAbility = new FireAbility();
} Questions? class FireAbility implements SpecialAbility {
doSpecial() {
} "Head First Design Patterns"
"Design Patterns: Elements of Reusable Object-Oriented Software"
Full transcript