COMPUTER SCIENCE 2P05 Programming Languages Planning, - - PowerPoint PPT Presentation

COMPUTER SCIENCE 2P05

Programming Languages Planning, object-orientation... stuff?

Brock University

Brock University (Planning, object-orientation... stuff?)Programming Languages 1 / 26

Object-Oriented(OO) Design

We know the basic approach to writing OO programs, right? First and foremost: Decomposition into classes Definition of functionality Grady Booch formalized much of what’s now standard procedure for OO design, including the creation of OO modeling languages. His approach focused on: Identifying classes Identifying functionality Identifying relationships (any of this seeming a bit... familiar?)

Brock University (Planning, object-orientation... stuff?)Programming Languages 2 / 26

Responsibility-Driven Design

An early-ish (early 90’s) approach was to delegate responsibilities (e.g. for knowing and doing) to classes. A class would be responsible for its own operations

◮ Of course, this relates to the object being the one with the

corresponding state information

Anything else relying on that behaviour would make a request of the class

◮ We can envision many programs as largely being behaviours delegating

to other behaviours

Design would thus require characterizing a task in terms of its desired behaviours (at the system level, and at the component level). When allocating members, we need to balance coupling and cohesion (recall: we want loose coupling, and high cohesion).

Brock University (Planning, object-orientation... stuff?)Programming Languages 3 / 26

Analysis

Prior to absolutely any coding at all, unambiguously establishing all requirements would be necessary. (seriously, anyone else getting deja vu?) One common step would be an analysis, which includes: Defining overall behaviour Identifying major use cases

◮ Top-level behaviours a user might invoke/select

Identifying actors

◮ People or systems external to the project, that participate in use cases Brock University (Planning, object-orientation... stuff?)Programming Languages 4 / 26

Use Cases?

There are two things one might mean when using the term Use Case (in a software context): You covered Use Cases in 1P03:

◮ Describe the action/goal ◮ Actors? ◮ A brief description ◮ Preconditions (what must be true for the use case to apply) ◮ Postconditions (what’ll be true after it finishes) ◮ Summary of steps ◮ Includes (dependencies on other use cases) ◮ Extensions (variations or alternate versions)

But there are also Use Case Diagrams to show dependencies or flow between Use Cases

◮ These give a broader view of how a system operates Brock University (Planning, object-orientation... stuff?)Programming Languages 5 / 26

Use Cases

Use Case: Checking out library book Actors: Patron Summary: User scans a book, to be returned by a later (specified) date. Preconditions: Current membership; no owed fines Postconditions: Book in patron’s custody; book has due date Steps: 1. Swipe library card

• 2. Book is scanned to retrieve record
• 3. If book is not reserved, associated with patron account
• 4. Due date is generated based on date and type of book
• 5. Receipt is printed with due date

Includes: Authenticate patron Extensions: 1–3 Renewal:

• 1. Log into website
• 2. Retrieve current loans
• 3. Assign new due date

Brock University (Planning, object-orientation... stuff?)Programming Languages 6 / 26

Use Case Diagram

Brock University (Planning, object-orientation... stuff?)Programming Languages 7 / 26

Design?

Hold up. It’s obvious what we’re doing. This is the waterfall model It is, and it isn’t. Various software development life-cycles have arisen and fallen out of favour, largely to accommodate (or help create) different applications, languages, usages, etc. You can’t talk about languages without considering how they’re used, nor can you talk about how to write software without considering the tools. Though there are numerous software design philosophies, there are many common elements that come up frequently. What we’re really doing today is looking at those aspects that you’re likely to touch on with any significant OO-based design.

Brock University (Planning, object-orientation... stuff?)Programming Languages 8 / 26

Design!

This is where we’ll start diverging from first-year. There, you filled out CRC cards. We aren’t interested in those, but clearly the principle is still useful: We need to establish classes and responsibilities, right? We need to define relations between classes

◮ Though we’ll now start making distinctions betwen associations and

dependencies

We also need to introduce a new concept to our modeling: lifelines.

Brock University (Planning, object-orientation... stuff?)Programming Languages 9 / 26

Design

Is that like extent?

As discussed earlier, extent is the lifespan of a variable/object. For how long will that piece be available to the enclosing object? A lifeline (or lifespan) denotes two points:

◮ When an object is instantiated, with relation to the lifespans of other,

related, objects

◮ When that object is deallocated

Consider how many times you’ve gotten NullPointerExceptions, because you forgot to initialize a variable?

Brock University (Planning, object-orientation... stuff?)Programming Languages 10 / 26

Sequence diagrams

Brock University (Planning, object-orientation... stuff?)Programming Languages 11 / 26

What about actual classes?

How do we model the classes themselves? Either in terms of structure, or behaviour The classic structural example is class diagrams

◮ Start similar to CRCs ◮ May show inheritance with hollow arrows (a realization includes a

dashed line)

◮ Aggregation is shown via hollow diamond; composition via filled

diamond

◮ An association may be shown via an arrow (or just a line); a

dependency uses a dashed line

◮ Honestly, the diagrams here and here are pretty good

The sequence diagram and use case diagram are good examples of behavioural diagrams

Brock University (Planning, object-orientation... stuff?)Programming Languages 12 / 26

Recognizing relationships

Two of the common concerns are distinguishing between association, aggregation/composition, and inheritancce; and between specifically aggregation and composition. For the former:

◮ Association is a uses relationship ◮ Aggregation is a has a relationship ◮ Inheritance is an is a relationship

For the latter:

◮ If a member component could reasonably exist without the enclosing

• bject, it’s aggregation

◮ Otherwise, it’s composition ◮ e.g. a course may contain any number of students, who are free to

take other courses

⋆ A department is a composition of several courses, that wouldn’t really

make sense independently

Brock University (Planning, object-orientation... stuff?)Programming Languages 13 / 26

Why are we talking about this?

Technically, we’ve been touching on the Unified Modeling Language (UML), but that isn’t really the point. Once you can start formalizing object design and relationships (through whatever mechanisms), you can also start discussing Design Patterns A Design Pattern is somewhat like a programming trope: a time-tested stereotype of how you could go about some piece of a task (or data representation). A complete solution, then, may consist largely of various patterns combined together.

Brock University (Planning, object-orientation... stuff?)Programming Languages 14 / 26

(A quick note on design patterns)

When you get to 3P91, you’ll talk about these in vastly more detail. We just need to understand enough to get context on how it affects our choice

• f language (and vice versa).

Similarly, the concept of design patterns is tightly connected to various other programming idioms

Brock University (Planning, object-orientation... stuff?)Programming Languages 15 / 26

What is a design pattern?

It’s a ‘best-practices’ way to standardize a common relationship. Let’s look at a very common one: Iterator Note that the Iterator pattern doesn’t solely refer to the iterator

• bject itself, but also includes the relationship with the iterated

collection The client associates with both the aggregate (collection) and the iterator

◮ The collection creates the iterator ◮ The iterator has a dependent association with the collection

What would we expect in the class diagram for the iterator? What would the sequence diagrams for the client, collection, and iterator look like?

Brock University (Planning, object-orientation... stuff?)Programming Languages 16 / 26

Model View Controller

We arguably should have started with this. MVC is the design pattern. It even predates ‘design pattern’ as a phrase. To best understand this, let’s instead build up to it. We’ll start by looking at a trivial program: notepad.

Brock University (Planning, object-orientation... stuff?)Programming Languages 17 / 26

Direct editing

Here, we’re directly editing the data There can be only one view/format of the data There are no safeguards What if we wanted to see a better view? (e.g. rendering a markup language)

Brock University (Planning, object-orientation... stuff?)Programming Languages 18 / 26

Abstracting display

Now, some view transforms data into what we see

◮ It might filter data, render, etc.

We now can have multiple views But we still need to edit data directly. Is that how word processors work?

Brock University (Planning, object-orientation... stuff?)Programming Languages 19 / 26

Model-View-Controller (MVC)

This time, we dispatch edits or instructions to a controller, which is suited for manipulating the underlying data representation We could have more than one controller (e.g. controllers for specific tasks) This is the foundation of most graphical interfaces, rich web content, etc.

Brock University (Planning, object-orientation... stuff?)Programming Languages 20 / 26

Observer

This should seem very familiar A subject (Observable) maintains a collection of observers The subject may add or remove observers When the inner data of the subject changes, it notifies its observers (Technically, we have the closely-related publish-subscribe, wherein you add a layer of indirection between the two, and the two sides don’t have direct knowledge of each other, but most people probably won’t make a distinction)

Brock University (Planning, object-orientation... stuff?)Programming Languages 21 / 26

Delegation

(Silly example, but bear with me...) A face card is always a playing card; that’s easy, right? But a playing card is sometimes a starter card. So how do we denote this relationship? We probably wouldn’t want to create new types (StarterFace, StarterAce, etc. ugh) For a problem that small, we’d probably not do anything about the type at all; how we use the object would define its starter-ness But what if we did want roles to be well-defined? One option is delegation. Specifically, classes of specific roles can all refer back to the class that can be a commonality between them. A starter card can keep a playing card as an instance variable Consider an undergrad who becomes a grad student who becomes a lecturer...

Brock University (Planning, object-orientation... stuff?)Programming Languages 22 / 26

Fa¸ cade

Sometimes you just want a (relatively) simple tool. You might be able to find all the behaviour you collectively need, but it’s spread across several different tools... Why not just wrap’em all up in a big ball of duct tape, and add some unified methods as entry points? This is the basis of fa¸ cade: one public-facing tool leverages several others ‘behind the scenes’. Simple example: the ASCIIDataFile you used in first year

◮ There’s a file object, a buffered reader, a tokenizer, a parser...

More drastic example: a compiler

Brock University (Planning, object-orientation... stuff?)Programming Languages 23 / 26

• Improvise. Adapt. Overcome.

Suppose I have a Deque (double-ended queue): You can addFirst, addLast, removeFirst, removeLast, peekFirst, peekLast, and isempty What I want is a Stack. How could I use the Deque for this? Let’s see if we can come up with two different ways?

Brock University (Planning, object-orientation... stuff?)Programming Languages 24 / 26

(Did it work?)

Chances are we probably came up with one (or both) of two options: Inheritance

◮ A Stack Is-A Deque ◮ We simply add extra behaviours for what we want ◮ (Depending on the language, we may be stuck with Deque’s as well)

Composition (yes, we’re using this term twice... sort of)

◮ A Stack Has-A Deque ◮ We only add those behaviours we actually want

Either way, we’re using the Adapter (or Wrapper) design pattern (class adapter for the former; object adapter for the latter). Note that this is not the same thing as Fa¸ cade.

Brock University (Planning, object-orientation... stuff?)Programming Languages 25 / 26

Questions?

Comments?

Anyone picked up Blaster Master Zero 2 yet?

Brock University (Planning, object-orientation... stuff?)Programming Languages 26 / 26