Class Design

1
Class Design

• Dr. Tim Margush
• University of Akron

2
Goals

• Be able to create appropriate classes to support
  algorithm development
• Understand cohesion, coupling, and side-effects
• Know the difference between class and instance
  members and be able to apply that knowledge
• Appreciate scope rules and the use of packages

3
Programming With Class

• A class captures the essential attributes of and
  actions related to a single concept
• Class definitions are used to
• Instantiate objects
• Group related functions
• Separate 'form' from 'function'
• Bind actions to data collections

4
'Form' vs. 'Function'

• The public interface of a class defines its
  'form'
• How it 'looks' from the outside
• What its capabilities are
• The private members hide the implementation
  details 'function' and 'structure'
• How it does what it does (method implementation)
• How it represents (internal data structures) the
  class concept

5
Classification of Classes

• Abstractions represent physical objects
• The focus is on the attributes
• Rectangle, BankAccount, Person
• Actors represent objects that perform a useful
  function
• The focus is on a sequence of actions or process
• Scanner, Random, FactorGenerator
• Utility classes group related methods and
  constants
• The focus is on calculations or values
• Math, Array, System

6
Cohesion

• The degree to which the public members of a class
  are related to a single purpose, concept, or
  function
• Strive for a high degree of cohesion
• Separate concepts deserve their own class
• Example A car has a radio and a gas pedal
• Do not simply include the details for these
  objects in a Car class
• Group radio related info in a Radio class
• Group acceleration related info in a GasPedal
  class
• Use these classes inside the Car class

7
Coupling

• The degree to which two classes depend on each
  other
• A class depends on another if it uses its methods
• Attempt to minimize coupling
• The Car class depends upon the GasPedal and Radio
  classes, however these classes do not depend on
  each other
• They might call methods in the Car class as well
  (increasing the degree of coupling)

8
Unified Modeling Language

• A graphical representation of classes/objects and
  their interrelationships

B
A
Dashed line with open arrow tip indicates
dependency (coupling) "A depends on B"
9
Mutable - Immutable

• An object whose state can change is a mutable
  object (Rectangle)
• A method that causes a change of state is a
  mutator
• Mutators generally return void

• An immutable object cannot be changed once
  created (String)
• A method that does not change the state is an
  accessor
• Accessors generally return a copy of internal
  information

10
Side-Effect

• When a method call causes a change to anything
  other than the implicit object or class, a
  side-effect is said to have occurred
• A method that causes console output
• Couples the class with System and PrintStream
• A method that modifies a different object,
  especially one belonging to a different class
• Couples the two classes

11
Great Expectations

• Every method should clearly state any
  pre-conditions - something that is required to be
  true for proper operation
• Are parameter values limited in any way?
• Positive, non-null, less than 1000,
• Must something else have happened first?
• Call init() before calling this method
• Requires a successful find() operation prior to
  use

12
Verify Pre-Conditions?

• An exception may be created (thrown) if any
  pre-condition is not met
• if (amount lt 0) throw new IllegalArgumentExce
  ption()
• Don't test and then simply ignore illegal values
• (unless specifications allow this)
• Testing pre-conditions makes programs bigger and
  slower, but more reliable
• Test during debugging, remove tests later

13
The Bottom Line

• A post-condition is something that is true when a
  method call completes
• Assuming the pre-conditions were met!
• Assuming the method is correct!
• State non-trivial post-conditions in method
  documentation
• Post-conditions are like a contract to be
  fulfilled
• Post-conditions help guide the programming
  process
• Post-conditions aid in program maintenance

14
Be Assertive

• The assert command can be used to verify that
  pre- and post-conditions are met
• Assertion checking can be enabled at runtime
• Assert syntax
• assert condition
• An assertion error is thrown if assertion
  checking is enabled and an asserted condition
  evaluates to false

15
Class Variables
Class variable

• Declared using the static keyword
• Each class variable
• Is shared by all objects of the class
• Lives in the "object factory" not in an object
• Accessed from instance or class methods

• class Student
• private static int sCount 0
• private String id
• public Student()
• sCount
• id "ST"sCount
• public static int getCount()
• return sCount

Accessed from instance method
Accessed from class method
16
Static Storage
1
2

• int x Student.getCount()
• Student a new Student()
• Student b new Student()
• String aID a.getID()

sCount id "ST"sCount
0
Click to view animation steps
Animation Complete
17
Instance and Class Methods

• Instance methods
• generally access at least one instance variable
• Have access to an implicit object
• Are able to access class variables
• Require an object to be invoked

• Class methods
• Cannot access instance variables
• Have no implicit object
• Can access only class variables (and parameters)
• Are usually called using the class name rather
  than an object

18
Scope

• The scope of an identifier declaration is the
  region of the program in which that identifier
  can be accessed using its simple name
• Local variables have local scope which begins at
  the declaration and extends to the end of its
  block
• A parameter's scope is the body of its method
• Class members (defined in or inherited) have
  class scope, meaning they are available
  throughout the entire class body

19
Shadowing

• A declaration of an identifier named x within the
  scope of an identifier named x shadows the first
  identifier for the scope of the declaration
• Access to a shadowed identifier requires
  qualification

• public class Shadow
• private boolean knows
• public Shadow(boolean knows)
• //the parameter shadows
• //the field
• this.knowsknows

20
Scope It Out

• public class A
• private int x
• public A()
• for (int x0 xlt9 x)
• use(x)
• use(x)
• private void use(int x)
• this.xx
• public int getX()
• return x

• What is the scope of the field x?
• What is the scope of the loop variable x?
• What is the scope of the parameter x?
• What is the scope of the method use?

Click to view animation steps
Animation Complete
21
Local Variables

• You may reuse the same local variable in a method
  as long as their scopes do not overlap
• Overlapping scopes for local variables results in
  compile error

• public class NonOverlap
• public void madness()
• for (int x0 xlt9 x)
• totalx
• //scope of x ends here
• double x //reuse of x - OK
• if (legal)
• int x0 //illegal overlapping

22
Packages

• A Package is a collection of related classes
• A program is a collection of packages
• Every class belongs to some package
• If none is specified, this is the default package
• Packages must be named uniquely and stored in
  particular locations
• The path to a package file must match the name of
  the package
• Package a.b.c must be located in classpath/a/b/c
  where classpath is known to the compiler and JVM

23
Specifying a Package

• A file is assigned to a package by
• Adding the package statement to the top of the
  file
• package a.b.c
• Storing the file in an appropriate folder
• classpath/a/b/c/some_package_file.java
• If the package is used for only one project, you
  can place the package folder inside the source
  folder

24
Setting the ClassPath

• Depends on environment or operating system
• jGrasp allows different ClassPath settings for
  projects and workspaces
• SettingsgtPATH / CLASSPATH
• Workspace or Project
• C\
• C\java\packages\
• This will look for the package starting at these
  base locations
• C\a\b\c or C\java\projects\a\b\c

25
Importing Packages

• The import statement informs the compiler that
  part or all of a package will be used in another
  package
• import a.b.c.ClassName
• import a.b.c.
• Allows use of ClassName without further
  qualification
• All programs implicitly import java.lang.
• You can use packaged classes without an import if
  you fully qualify each name
• a.b.c.ClassName x new a.b.c.ClassName()

26
Static Imports

• The static import allows the use of static
  methods and fields without their class name
  prefix
• static import java.lang.Math
• //allows
• double x sqrt(y)
• //in place of Math.sqrt(y)

27
Package Names

• Must be unique to avoid clashes
• Choose a domain name or email address (such as
  cs.uakron.edu)
• Although this need not exist, it needs to be
  unique to you (perhaps joe.franklin.cs.uakron.edu
  ?)
• Reverse it to create a prefix for your packages
• edu.uakron.cs.package_name
• edu.uakron.cs.franklin.joe.package_name
• com.yahoo.minty_toothpaste93.package_name
• Create your package area under an appropriate
  base path and add it to your ClassPath setting

28
Summary

• Classes are defined to capture attributes of and
  actions related to a single concept
• Classes should be cohesive and minimize coupling
• Classes can be mutable or immutable
• Methods can be mutators or accessors
• Pre and post conditions are important for program
  development and maintenance

29
Summary

• Class variables are shared by all objects of the
  class while instance variables are replicated in
  each object that is created
• Class variables and methods are not connected to
  objects
• Scope rules define the extent of an identifier
  declaration
• Packages are used to group related classes and
  avoid name clashes