Thinking about programming Understand the specification - - PowerPoint PPT Presentation

▶

Aug 12, 2023 123 likes •190 views

Thinking about programming Understand the specification Ambiguities? Missing pieces? Finding classes focus on what, not how what are responsibilities? collaborations? Planning for change what classes can help make

SLIDE 1

Duke CPS

5. 1

Thinking about programming

Understand the specification

➤ Ambiguities? ➤ Missing pieces?

Finding classes

➤ focus on what, not how ➤ what are responsibilities? collaborations?

Planning for change

➤ what classes can help make extensions easier?

SLIDE 2

Duke CPS

5. 2

Designing Classes and Programs

Where do classes come from?

➤ nouns: brainstorm, cull, combine, divide ➤ attributes vs. classes, keep cohesion high

Things to watch out for

➤ kitchen sink classes: keep classes highly cohesive ➤ God classes: know about everything in the app ➤ classes with little behavior (only get/set), and few collaborators

CRC cards: classes, responsibilities, collaborators

➤ 3x5 card, class name at top, list responsibilities and

collaborators

SLIDE 3

Duke CPS

5. 3

CRC Card template

SLIDE 4

Duke CPS

5. 4

Some CBOOCA Questions

Should a given directory be searched recursively?
Is there a maximum length on a phrase?
What constitutes a word?
How should you deal with the following:

the sandman the sand man

When building phrases, should you observe sentence boundaries?

File boundaries?

How to deal with errors?

➤ cannot find corpus ➤ does corpus need to be a text file? ➤ illegal phrase length

SLIDE 5

Duke CPS

5. 5

Some CBOOCA Specification Changes

Additional command line options

➤ -a

sort alphabetically

➤ -n

sort numerically (default)

➤ -d <dictionary>

use only words found in dictionary

Order of command-line arguments may change (next week)
Optional features

➤ use web page(s) as corpus ➤ read preferences from .cboocarc file by default, overridden

by command-line arguments

SLIDE 6

Duke CPS

5. 6

Working in teams

Work together until it is time not to work together

➤ debate the design ➤ do not code until everyone in the group understands design ➤ separate coding into individual tasks

Controlling the source code

➤ use RCS or CVS (see online resources ➤ build stable version everyday ➤ using afs groups

Who’s in charge?