Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

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.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Software Design Patterns Presentation

No description
by

Jeffrey Bornemann

on 8 March 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Software Design Patterns Presentation

History....Continued Presented 23 classic design patterns that are in common usage today First...Some History Popularization of design patterns arose with a book published in 1994 Lets Get To It... Good software is always open to change The Facts Good software design is worth it Principles Open-Closed Principle Jeff Bornemann Software Design Patterns Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides "Gang of Four" Bad software is rigid, and overly situational - Maintainable, easy to read, easily modified by others - Scalable - Portable - A good, quality product - Components are tightly coupled, immalleable - Lack of modularity - hard to read, hard for others to modify, increasingly hard to maintain - Not built to anticipate change. "Hugs a use-case" - A low quality, fragile product It makes your job easier It makes your coworkers job easier Work gets done faster = happy customer It makes a better product No different than designing a bridge, or a car; all design patterns attempt to subscribe to a set of principles Software components should be open for extension, but closed for modification Extension through inheritance Example Template Method Pattern Dependency-Inversion Principle Be careful with inheritance Children should not access parent Couples the child to the parent. Child needs to leave the nest one day Components should be black boxed Gang of Four warns of white boxing with inheritance. They suggest object composition instead. More on this later... Also called the Hollywood Principle "Don't call us, we will call you" Template Method Example See Netbeans... What was wrong with my example? Another Principle "Program to an interface, not an implementation" I was coupling my cars with an engine and accelerator implementation. This should be abstracted out. See Revision One... Notice we are still applying the Open-Closed Principle. Rather than extension by inheritance, this is extension by "object composition" "Object composition over inheritance" Gang of Four prefers this There are still problems.. Whens the last time you saw a car create it's own engine? Engine's are created in factories, and placed in the car Same Idea in Software Engineering. At the point of binding an implementation to an interface, remove the details of object creation from the model (Bugatti) Factory Patterns!! Factory Patterns Factory Method Pattern Abstract Factory Pattern Think of this as a factory pattern for factory method patterns. Patternception Lets stick with this one for now Show Revision Two... More to Cover Next Time... - Strategy Pattern (Dynamic Algorithms O my!) - Facade Pattern (One Point Access) - Architectural/Conglomerate Patterns (E.G MVC) - Singleton Pattern (For constructors that want to be left alone) - Adapter Pattern (For those who practice wizardry)
Full transcript