CSC 313 – Advanced Programming Topics

Open-Closed Principle Classes should be open for extension, but closed to modification  So, what does this mean?

Reality Check Classes should be open for extension… other’s  Want to update other’s code  Other is important emphasis  Everyone is other to someone  Easily create subclasses to:  Add functionality  Include additional fields  Specialize behavior via overriding

More Reality Check …But closed to modification

More Reality Check …But closed to modification your  Nobody better mess with your code  YOUR code being beauty incarnate usually  Only add errors & will soil your perfection  Never let anyone:  Make changes which violate basic assumptions  Alter tasks it performs perfectly already  Anything that might introduce bugs

Strategy Pattern & OCP  Pattern stays true to open-closed principle  Using pattern, context open for extension  New functionality created by changing strategy  If more data is needed, subclasses can add fields  Context closed to modification despite all this  Actions limited by data provided to strategies  Strategies focused on task & cannot do other acts

Observer Pattern & OCP  Observer pattern devotee of principle, too  Using this pattern, subject open for extension  Responding to events open to each Observer  In pull model, extend Subject to make more info  Cannot modify Subject using this pattern  Limits of pattern means Observers only RE - ACT  Subject chooses events to expose to Observers

Warning Remainder of lecture unsafe for: Beginning programmers Unwilling to consider new viewpoints Stubbornly dogmatic Stupid Liberal arts majors

Inspiration For Pattern

Making a Cultured Pearl  Pearl made when piece of shell enters oyster  Irritant required to start making of pearl  To avoid irritation, shell grown around it  Layer after layer of material added by the oyster  As it grows, each layer adds new affect  Color, shine, shape modified by every layer added but always a pearl  So each layer adds something, but always a pearl

Problem At Hand  Have single key main concept  Coffee  Paycheck  Pizza  Characters  But many ways to adjust and extend concept  Cream, sugar, soy, mocha, caffeine, whip, chains  Federal & State income tax, FICA, health insurance  Bacon, pineapple, ham, anchovies, mushrooms  Bold, italic, underline, color, SMALL CAPS, error

Add Fields for properties  Add field for each possible property  Is double whip, decaf, soy water possible?  Multiple states need taxes; how to handle this?  Using fields is both hard & inefficient  Must modify class for each new property we need  Creates huge number of rarely used fields

Add Fields for properties  Add field for each possible property  Is double whip, decaf, soy water possible?  Multiple states need taxes; how to handle this?  Using fields is both hard & inefficient  Must modify class for each new property we need  Creates huge number of rarely used fields  Class open to everyone to play with & change  This very clear violation of open close principle

Create Subclasses  Define subclass for each possible situation  Need both MochaWhipCoffee & WhipMochaCoffee?  Every pizza topping combination must be written  Good news: this follows open-close principle  But code duplicated in many places  Who’ll modify classes to update New York tax rate?  Maintaining this code will be pain for someone

Decorator Pattern Intent

Decorator Pattern Usage

For Next Lecture  Lab #2 due before next lab  Asks you to implement the Strategy Pattern  Read rubric  Read pages 95 – 105 in the book  How do we implement the design pattern?  Can anyone actually use this?  What is the main point of this pattern?