2 Options for software
Change (continuously maintained) or die (thrown away)
Important concepts for accessing the quality of code
coupling and cohesion
coupling
- 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
cohesion
-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)
code duplication Issues
- indicator of bad design
- maintenance harder
- can lead to errors during maintenance
loose coupling
- 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
tight coupling
- 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
Responsibility Driven Design
- 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
Localizing Change
- the aim of reducing coupling and for RDD
- when a change is needed, as few classes as possible should be affected
Implicit coupling
- 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
Thinking ahead
- think what changes are likely to be made in the future
- aim to make changes easy
cohesion applied at different levels
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
High cohesion
- 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
Refactoring
- 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
Refactoring & testing
- 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
What does an enumerated type definition consist of
-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
}
Enumerated variable names
- 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
enumerated types
-
