CSC 211 Introduction to Design Patterns

Intro to the course Syllabus About the textbook – Read the introduction and Chapter 1 Good attendance is the key to an easy ride

Background CS1 - Programming and Control Structures CS2 - Data Structures - common patterns for storing and retrieving data CSC211 - Design Patterns - common architectural patterns – Broader, more sophisticated view

A little about design patterns This course is an introduction to software design patterns. Each pattern represents a best practice solution to a software problem in some context. Design patterns are just convenient ways of reusing object oriented code between projects and programmers. Write down and catalog common interactions between objects that programmers have frequently found useful.

What’s a design pattern? Model, view, controller (MVC) pattern in Java Swing In other words, design patterns describe how objects communicate without become entangled in each other’s data models and methods. Keeping this separation has always been an objective of good OO programming

OOP – Review of Basics Abstraction Class Object Instance

Inheritance When one class is defined to include methods and fields from another class Subclass vs. Superclass – Child vs. parent How do we code that in Java?

Substitution Principle Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T In other words, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program

Substitution Principle’s Effects Preconditions cannot be strengthened in a subclass. Remember method preconditions? Postconditions cannot be weakened in a subclass. No new exceptions should be thrown by subclass methods – except where exceptions are subtypes of superclass exceptions

Abstract Class A class that cannot be instantiated Why would we do that?

Interface Defines a set of method signatures A class that implements the interface promises it will implement signature methods Response to Java not allowing inheritance from multiple superclasses Essentially allows a subclass to be substituted for multiple superclasses. – However only one of those superclasses can contain more than method signatures.

Interface and abstract class Java has a class like form called an interface that can be used to encapsulate only abstract methods and constants. Think of an interface as a blueprint or a design specification. A class that uses this blueprint is a class that implements the interface. Another way of thinking of an interface is as a pure abstract class, wherein all the details are deferred. An interface is allowed to have only abstract methods and constants. Interface methods can’t be static. An interface is allowed to have only public methods, and by convention the keyword public is omitted. Because all methods in an interface are abstract, the keyword abstract is also omitted. A new class implementing the interface uses the keyword implements. The class that implements the interface must provide an implementation for all methods in the interface. The difference between an interface and an abstract class becomes very important when you want to create a class that implements more than one interface. You can’t extend more than one class, but you can use a class to implement many interfaces, in addition to extending one class.

Type Polymorphism Declaring an instance of a subclass to be of a type of its superclass or an interface its class implements Ex. Purrer kitty = new HouseCat();

Is-A versus Has-A A sub-class has an “Is-A” relationship with its superclass A class has an “Is-A” relationship with any interface it implements A class has a “Has-A” relationship with any class that is the type of one of its instance variables

What are design patterns? Common ways that classes are structured to solve similar types of problems Frameworks for classes, objects, and interfaces that can be applied to a wide variety of situations Thinking about the design of the system at a higher level A solution to a problem in a context -- (textbook def.)

Design Patterns Give us Vocabulary Shared vocabulary that we use to discuss design alternatives Data structures began that vocabulary at a lower level That vocabulary lets us describe alternatives efficiently

What design patterns aren’t They aren’t data structures – Data structures can be implemented once and shared between many applications – Even if two applications use the same patterns, each will have to implement the details for their own problems. They aren’t libraries or APIs

Design Patterns and Thought Design Patterns are ways of thinking about potential solutions to complex problems They obey good OO design principles and have been shown to be widely applicable We need to be able to think at a higher level

Our interest What makes a design “good”? What design principles support good designs? Proven design techniques

Strategy for Building Big Systems How do we know what to build? How will we know that it works? How will we deal with changes that come up as we learn more about the requirements and the system?

Test Driven Development Write automated tests before writing the code Iterative Development: – Red - write a test and watch it fail – Green - write the simplest code that can make the test pass – Refactor - clean up the code to eliminate duplication

Why do we write the test first? Help us plan the code we’re going to write Help us focus on how people will use our code (not just what it has to do)

How do the tests help? We know the system works We can refactor with confidence Serve as design documentation – Javadocs document structure – Tests document behavior – These work well together

Homework For lab (We’ll do a lab to practice TDD) – Read about JUnit testing framework at For next week – Read book from beginning through the Strategy Pattern In general – Quizzes on Tuesday – Cover a pattern Starting on Tuesday with a lab later in the week – Read about the pattern BEFORE you come to class on Tuesday (it’s on the quiz!)