LECTURE NOTES CHAPTER 9 CHOOSING CLASSES - OO programming focuses on "things" and "doings" (entities and actions) - how are actions represented? - methods - what do all methods belong to? - a class - class is a collection of objects - objects are entities 1 a : BEING, EXISTENCE; especially : independent, separate, or self-contained existence b : the existence of a thing as contrasted with its attributes 2 : something that has separate and distinct existence and objective or conceptual reality - mix and match: - class names - nouns - method names - verbs - good class - represents how many concepts? (1) - name: describes concept - example uses of classes - Deb: - datatype: Pile, NimPlayer, Nim - datatype tester: PileTester, NimPlayerTester - application: Nim - utility - no objects - collection of related static methods and constants - main method only (application) - start a program - degenerate example of design - so why is Nim good design? - bad class - can't tell from name what does - try to turn an action into a class COHESION AND COUPLING - class represents how many concepts? (1) - interface features: closely related to represented concept - what to do if interface refers to multiple concepts? - turn into multiple classes - UML - Unified Modeling Language - notation for classes and objects - distinguish object diagrams and class diagrams - underline object name - don't underline class name Example: - Pile class - Pile object - dependency - dotted arrow - from class to class it depends on Example: - Nim depends on Pile - coupling - level of dependency - how many classes of a program depend on each other - high: many classes of a program depend on each other - low: few classes depend on each other - chains: A-->B B-->C A-->C? - conflicting goals - OO approach - encapsulate things as different classes and have them interact - more classes - avoid having changes to one class affect (propagate to) others - resolution: good definition of public interface - should be able to make internal changes without affecting dependences - good initial design critical, because stuck supporting it! - part of good design: consistent scheme for method names and parameters 9.3 ACCESSORS, MUTATORS, AND IMMUTABLE CLASSES - mutator method: modifies the object on which it was invoked - accessor method - accesses information without making modifications - behavior is very predictable - immuatable class - has no mutator methods - safe to give out references to its objects freely 9.4 SIDE EFFECTS - mutator modifies object on which it is invoked - access leaves object on which it is invoked unchanged - side effect: - any kind of modification of data that is observable outside the method - mutators: modification of implicit parameter - updating an explicit parameter - best to avoid whenever possible - output - still need get method if want to use for other reason - forces strong assumptions - violates the rule of minimizing coupling - methods can't update primitive parameters - because they are not references - minimize side effects - accessors: no side effects - mutator - no changes to explicit parameters - acceptable side effect - change explicit parameter: avoid when possible - methods that change another object: should be avoided - don't change the contents of parameters - don't use them as temporary values - treat as though constant - introduce new local variables instead 9.5 PRECONDITIONS AND POSTCONDITIONS - precondition - requirement that the method caller must obey - method not responsible for correct results if caller violates - must document: add to description or appropriate @param tag - typically provided to - restrict parameters - require that a method is only called when in the appropriate state - what to do if violated - check and throw an exception - assume fulfilled; corruption isn't the method's fault - assertion - condition that you believe to be true at all times in a particular program location - assertion check - test whether assertion is true - syntax: assert - if assertion fails and assertion checking enabled, program terminates with AssertionError - diabled by default - definitely turn on during development and testing - good because forces caller to notice problem - postcondition - if called in accordance with preconditions, ensures that postconditions are true - kinds - return value is comptued correctly - object is in a certain state after method call - add to description or @return tag - don't repeat if @return already specified - only give in terms of interface - contractual terms between method and caller 9.8 SCOPE 9.8.1 SCOPE OF LOCAL VARIABLES - multiple variables/fields with same name - possibility of conflict - scope - region of a program in which the variable can be accessed - from the point of its declaration to the end of the block that encloses it - disjoint variables - scopes don't overlap - OK to have same name - scope of a local var can never contain definition of another local var of the same name 9.8.2 SCOPE OF CLASS MEMBERS - class members == fields and methods - class scope - private members - accessible in all methods of the class - use public member outside of class - qualify the name - static: specify the class name - instance: specify the object name - inside method - needn't qualify members of the same class - instance fields automatically refer to implicit param - static fields automatically refer to the same class - "self-call" - unqualified method call - implicit parameter is this 9.8.3 OVERLAPPING SCOPE - two identical variable names with overlapping scope - can happen with a local variable and an instance field - local variable shadows instance field - compiler assumes local variable meant - because can still refer to instance field with this - common in constructors 9.9 PACKAGES 9.9.1 ORGANIZING RELATED CLASSES INTO PACKAGES - java program consists of a collection of classes - packaging - add more structure to large programs - package: set of related classes - put classes in a package - syntax: package ; - must be first instruction in source file - must be one or more identifiers separated by periods - default package - has no name - all classes are placed here if no other package is specified 9.9.2 IMPORTING PACKAGES - use a class from a package - refer to it by it's full name . - inconvenient - import a name - syntax import .; - lets you refer to a class of a package by its class name, without the package prefix - import all the classes of a package import .*; - never need to import classes in the java.lang package explicitly - automatically always imported for you - don't need to import other classes in the same package 9.9.3 PACKAGE NAMES - packages - convenient mechanism to organize classes - avoid name clashes - there can be more than one class of the same name as long as each is in a different package - ensure that package names are unique - take advantage of uniqueness of internet domain names - turn the name around - or, write email address backwards 9.9.4 HOW CLASSES ARE LOCATED - want to add your own packages - compiler cannot locate a particular class or package - package is located in a subdirectory that matches the package name - parts of the name between periods represent successively nested directories - if only one program, just create this tree somewhere - if multiple programs - want only one tree - point compiler to this place - add directories that might contain packages to the class path - base directories only - not complete package - depends on compilation environment