Chapters 1 and 26 General Introduction

Chapters 1 and 26General Introduction Summary prepared by Kirk Scott

This general introduction covers two chapters in the book: • Chapter 1: Introduction • Chapter 26: Introducing Extensions

Chapter 1 covers general information about the contents and organization of the book • In addition to mentioning this, I outline the organization of the course, which differs from the book • Chapter 26 talks about over-arching object-oriented design principles which will be exemplified by the patterns that will be covered

Design Patterns in JavaChapter 1Introduction Summary prepared by Kirk Scott

Intended Audience, Coverage, etc. • The classic book, Design Patterns, was written by Gamma, Helm, Johnson, and Vlissides • This book covers the same set of 23 patterns • The book is intended for software programmers/developers who know Java and want to improve their skills as designers

What is a Pattern? • A pattern is a way of doing something • It can be thought of as a technique for accomplishing some goal • This book dwells on the intent of patterns as an organizing characteristic • The chapters have been reorganized for the purposes of this course to emphasize common structure rather than common intent

Where do Patterns Come From? • Software development is repetitive: Quite often, different programmers have to solve the same problem • Experienced programmers have compared notes and discovered that they arrived at common solutions to the same problem • Over time, these common solutions have been documented as the best known approach to solving a given problem

Why Design Patterns? • Observe that in school, you learn to program first and learn about design later • When you compare your solution to a problem with someone else’s solution, you may realize that the other solution is simpler, more efficient, or more desirable in some other way • In practice, it is helpful to have knowledge of design before trying to code a solution to a problem

Why Design Patterns? Cont’d. • Design patterns are one step up from straight code writing • They represent recognized software solutions in terms of (small) collections of classes related in a certain way and containing certain sets of methods • It is important to keep in mind that the implementation is not the pattern—a pattern is the abstract design which embodies the intent

Why Design Patterns? Cont’d. • Design patterns have been developed most extensively in the object-oriented realm • The authors point out that there are currently over 100 documented design patterns • The 23 covered in the book have been chosen for historic reasons • They are certainly worth knowing, whether they are absolutely the most important

Why Design Patterns? Cont’d. • In particular, whether the most important or not, the 23 chosen patterns provide a broad introduction to and illustration of what patterns are and what they’re good for • The authors assert that if a person wants to become a good Java programmer, it is necessary to study design patterns • Design patterns are the first step out of the swamp of syntax that an introduction to programming is

Why Java? • Java is a consolidation language • This means that it is a kitchen sink language in the footsteps of C and C++, and for this reason, if no other, it is popular • Object-oriented programming is based on classes and instances, and this paradigm is currently the most popular approach to implementing graphical user interfaces, for example • Java’s characteristics make it likely that future popular languages will follow in Java’s footsteps

UML • Implementations of patterns are done in code • However, the pattern itself consists of the relationships among classes and so on • UML is one of several notations for diagramming object-oriented designs • It is probably the most popular one currently • The point is that some abstract representation of patterns is desirable, rather than appealing always to the code of a particular implementation

Challenges • The book contains questions • These may be short answer questions • They may also be programming questions based on the book’s example code • This course will not give these challenges as assignments • Instead, the challenges and the authors’ solutions will be examined to see what can be gained from them

The Organization of the Book • This book organizes the patterns according to the intent which the authors ascribe to them • This raises the question of how to classify intent • The authors suggest that categories of patterns can be recognized according to how the patterns make it possible to go beyond the basic characteristics built into the structure of Java

The Organization of This Book, cont’d. • The authors use as an initial example the idea of interfaces • Suppose you have a class/method which requires an object of a class which implements a given interface • Suppose you have an object of a class which does not implement the required interface • Is there a way of applying the method defined in the interface to an object of a class that doesn’t implement the interface?

The Organization of This Book, cont’d. • The obvious answer is to rewrite the class to implement the interface • If that is not possible, there is an alternative • There is a design pattern known as the Adapter pattern (not to be confused with adapter classes in Java) which accomplishes this goal • The Adapter pattern, and others with similar intents, are classified in an intent category known as Interfaces • In the authors’ scheme, all of these patterns belong together

The Organization of This Book, cont’d. • The book classifies patterns into these five categories based on intent: • Interfaces • Responsibility • Construction • Operations • Extensions

The Organization of This Book, cont’d. • The book, as a consequence is organized in the same way • The authors admit that various patterns may fit more than one category • In such cases, the pattern is given in detail in the first category where it fits, and is mentioned briefly in subsequent sections • The classification of patterns is not an absolute, but some classification is useful and necessary, and is a starting point for suggesting alternative classifications

The Organization of This Book, cont’d. • What follows is a complete preview of the contents of the book • Intent Category: Interfaces. • Patterns: Adapter, Façade, Composite, Bridge • Intent Category: Responsibility. • Patterns: Singleton, Observer, Mediator, Proxy, Chain of Responsibility, Flyweight

The Organization of This Book, cont’d. • Intent Category: Construction. • Patterns: Builder, Factory Method, Abstract Factory, Prototype, Memento • Intent Category: Operations. • Patterns: Template Method, State, Strategy, Command, Interpreter • Intent Category: Extensions. • Patterns: Decorator, Iterator, Visitor

The Organization of the Course • In this course the patterns will be organized and presented by structural similarity, not by intent • Also, this course covers some Java/object-orientation topics which aren’t necessarily design patterns and are not necessarily covered in the book

The grouping of patterns in the course is given on the following overheads • The groups are given—but the order of the groups is not necessarily the order in which the groups will be covered in class

Structural Category: Threads. • Patterns: Strictly speaking, this is not a pattern • Note: This is included immediately in order to support the first homework assignment • Structural Category: Construction and Cloning. • Patterns: Singleton, Prototype, Builder, Proxy

Structural Category: Model-View-Controller Related Patterns. • Patterns: Observer, Memento • Note: This does not involve many patterns, but it’s of great importance • It is included early in order to have the second homework assignment be based on this

Structural Category: Generic Interfaces and Encapsulation. • Patterns: Mediator, Façade, Adapter, Flyweight, Decorator, State • Structural Category: Java Interfaces. • Patterns: Iterator, Template, Strategy

Structural Category: Interfaces, Dynamic Binding, and Polymorphism. • Patterns: Factory Method, Abstract Factory, Command, Bridge • Structural Category: Composite and Related Patterns. • Patterns: Composite, Chain of Responsibility, Interpreter, Visitor

Welcome to Oozinoz! • The book’s examples are based on an integrated code base which is collectively known as Oozinoz (oohs and ahs), which deals with software needed for the production of fireworks • The authors’ examples will be presented and explained

Principles of Object-Oriented Design • For people interested in the topic of patterns, the book cites this Web site: www.c2.com • There is no need to go there for the purposes of this course • From that page there is a link to a Wiki with a collection of patterns that goes beyond the ones covered in the book

Summary • This is the book’s summary of the chapter, verbatim: • “Patterns are distillations of accumulated wisdom that provides a standard jargon, naming the concepts that experienced practitioners apply. • The patterns in the classic book Design Patterns are among the most useful class-level patterns and are certainly worth learning.

Summary, cont’d. • This book explains the same patterns as those documented in Design Patterns but uses Java and its libraries for its examples and challenges. • By working through the challenges in this book, you will learn to recognize and apply an important part of the wisdom of the software community.”

Design Patterns in JavaPart VExtension PatternsChapter 26Introducing Extensions Summary prepared by Kirk Scott

The Introduction Before the Introduction • In the book’s overall scheme, the purpose of this chapter is to introduce extension patterns • The chapter also reviews some patterns that have been introduced already, assuming you’ve gone through the earlier chapters • Because this course is organized differently, these two purposes are not important

The chapter also discusses some high-level object-oriented design principles • These are important • This is why I put this chapter at the beginning • These high-level concepts build on object-oriented ideas that were introduced in CSCE 202

Object-Oriented Constructs and Principles • Here are four concepts/terms encountered in CSCE 202 that are relevant to this discussion: • 1. Encapsulation • = Declare instance variables private—nothing can be touched except by a method call • 2. Interfaces • = An object of a given class may be referred to by an interface which it implements

3. Polymorphism • = A given superclass reference may refer to various kinds of objects which are instances of subclasses • 4. Dynamic binding • = At runtime the system determines the right version to use when a method is called on a polymorphic reference

The book will introduce these 4 additional ideas, which are related to the problem of arriving at a good object-oriented design: • Responsibility • Coupling • The Liskov Substitution Principle • The Law of Demeter

Responsibility • In simple terms, responsibility means that classes/objects should be self-contained • Their definitions should contain all of the instance variables and methods needed in order to manipulate them fully and accomplish desired goals with them • This is the norm, known as distributed responsibility

Responsibility can also be usefully concentrated in some cases • Various design patterns will illustrate both distributed and concentrated responsibility • In other words, the generally desirable goal of distributed responsibility will be relaxed in some patterns in order to achieve some particular goal

Coupling • There is a related concept, known as coupling • Ideally, objects are independent of each other • This generally desirable condition is known as loose coupling • Loose coupling might be thought of as meaning fewer connections • This would mean fewer places where you had to worry about a change in one object propagating to another

Inevitably, sometimes a change in one object will trigger a change in another • As usual, there are also cases where tighter coupling is desirable • Various design patterns will illustrate both loose and tight coupling

The Liskov Substitution Principle and the Law of Demeter • This chapter adds two major items to the list of object-oriented design principles: • The Liskov Substitution Principle • The Law of Demeter

These principles are interesting in their own right • They draw together some important insights that apply to object-oriented design in general • As the design patterns are introduced, at various points it may become apparent that the patterns, in general, are bounded by these principles • There may also be places where a given pattern can be seen to push the boundaries of one of the principles in order to achieve a particular goal.

Extending Code and the Design Principles • You rarely write code in a vacuum • You have an existing code base and your task is to add new features, classes, applications to it • Remember the idea presented in CSCE 202 of “inspired copying” • Extension means programming within the context of given code

Not only is it important to have rules of thumb to help you write good code from scratch • As a programmer, extending a code base, it would be helpful to have some rules of thumb to decide whether or not the code you are adding is any good

The LiskovSubsitution Principle (LSP) • One of the aspects of object-orientation that should be familiar to you is the following: • A subclass is in an “is-a-kind-of” relationship with its superclass • In general, a subclass is a more specific kind of the superclass • At the very least, it has the same set of instance variables, since instance variables can’t (or shouldn’t) be overridden

The subclass is made more specific by having more instance variables • It is also made more specific by adding or overriding methods, if necessary • In Java, it’s always syntactically possible to have a superclass reference to a subclass object

The superclass reference won’t have access to the instance variables and unique methods of the subclass • However, the superclass reference will have access to any methods inherited by the subclass • It will also have access to any methods overridden in the subclass

The ability to have superclass references is important when defining method parameters in an inheritance hierarchy • A method defined in a superclass with a superclass explicit parameter doesn’t have to be overridden in the subclass, with the explicit parameter re-typed to the subclass • It can simply be used with a subclass explicit parameter

The book states that subclasses should be logical, consistent extensions of their superclasses • Trying to define the meaning of logical and consistent leads to the Liskov Substitution Principle • The book paraphrases the principle as follows: • “An instance of a class should function as an instance of its superclass.”

Chapters 1 and 26 General Introduction