Chapter 8

Question 1

2 Options for software

Answer 1

Change (continuously maintained) or die (thrown away)

Question 2

Important concepts for accessing the quality of code

Answer 2

coupling and cohesion

Question 3

coupling

Answer 3

• interconnectedness b/t classes
• tight: 2 classes depend closely on many details of each other
• aim for loose
• class diagram provides (limited) hints at the degree of coupling

Question 4

cohesion

Answer 4

-The # and diversity of tasks that a single unit is responsible for
- high cohesion: each unit is responsible for one single logical task
- aim for high
- unit applies to classes, methods and modules (packages)

Question 5

code duplication Issues

Answer 5

• indicator of bad design
• maintenance harder
• can lead to errors during maintenance

Question 6

loose coupling

Answer 6

• aim for
• makes possible to:
  1. understand one class w/o reading others
  2. change one class w/little or no effect on others
• increases maintainability

Question 7

tight coupling

Answer 7

• avoid
• changes to one class bring a cascade of changes to other classes
• classes harder to understand in isolation
• flow of control b/t objects of different classes is complex

Question 8

Responsibility Driven Design

Answer 8

• Where should we add a new method (which class)?
• Each class should be responsible for manipulating its own data
• the class that owns the data should be responsible for processing it
• RDD leads to low coupling

Question 9

Localizing Change

Answer 9

• the aim of reducing coupling and for RDD
• when a change is needed, as few classes as possible should be affected

Question 10

Implicit coupling

Answer 10

• 1 class depends on the internal info of another, but their dependence is not obvious
• changes may not lead to complication errors - hard to detect
• maintenance programmers may not detect changes
• following RDD will avoid implicit coupling

Question 11

Thinking ahead

Answer 11

• think what changes are likely to be made in the future
• aim to make changes easy

Question 12

cohesion applied at different levels

Answer 12

Class level: classes should represent the single, well defined entity
Method level: A method should be responsible for one and only one well defined task

Question 13

High cohesion

Answer 13

• aim for it
• makes it easier to:
  1. understand what a class/method does
  2. use descriptive names for variables, methods & classes
  3. reuse methods & classes

Question 14

Refactoring

Answer 14

• when classes are maintained, often code is added
• classes/methods become longer
• every now & then, classes/methods should be refactored to maintain cohesion & low coupling

Question 15

Refactoring & testing

Answer 15

• when refactoring code, separate the refactoring from making other changes
• 1st do refactoring only w/o changing functionality
• test before & after refactoring to ensure that nothing was broken

Question 16

What does an enumerated type definition consist of

Answer 16

-outer wrapper: uses the word “enum” instead of “class”
-body: a list of variable names denoting the set of values that belong to this type. they are always fully capitalized
- can have fields, constructors & methods

public enum CommandWord
{
// A value for each command word, plus one for unrecognized
// commands.
GO, QUIT, HELP, UNKNOWN
}

Question 17

Enumerated variable names

Answer 17

• we never create objects of enumerated type
• each name represents a unique instance of the type that has already been created for us to use
• we would refer to these instances using the enum CommandWord example as CommandWord.Go, CommandWord.QUIT, etc
• enum type values are proper objects and not the same as integers

Question 18

enumerated types

Answer 18

-