Object-Oriented Object-Oriented PrinciplesPrinciples

Applications to ProgrammingApplications to Programming

Main PrinciplesMain Principles

• Generate Reusable SW ComponentsGenerate Reusable SW Components• Strongpoint of OOP technologyStrongpoint of OOP technology• Supported by Supported by inheritanceinheritance and and compositioncomposition

• Always prepare for changeAlways prepare for change• If your SW is successful, your client will want a new, If your SW is successful, your client will want a new,

different versiondifferent version• Identify the points of change in your application (tension Identify the points of change in your application (tension

points) and try to minimize thempoints) and try to minimize them• Isolate and reduce non-portable codeIsolate and reduce non-portable code• Reduce coupling (later)Reduce coupling (later)

More PrinciplesMore Principles

• Put your data firstPut your data first• It is less likely to change over timeIt is less likely to change over time• Tasks are mutableTasks are mutable

• Assign responsibilitiesAssign responsibilities• Determine Determine whatwhat your classes and methods do your classes and methods do• Decide Decide whatwhat needs to be done, then decide needs to be done, then decide whowho will do will do

itit• Walk through a scenario and assign activity to Walk through a scenario and assign activity to

components as components as responsibilityresponsibility• Use CRC cardsUse CRC cards

Any Yet MoreAny Yet More

• Team programming coordinationTeam programming coordination• Keep what each team members knowledge of Keep what each team members knowledge of

what other team members provide ata minimumwhat other team members provide ata minimum• Encapsulate, i.e. isolate and insulate dataEncapsulate, i.e. isolate and insulate data• Data Hiding (closely related to the above)Data Hiding (closely related to the above)• Keep SW component interaction at a minimumKeep SW component interaction at a minimum

DocumentationDocumentation

• Document so others after you do not have to Document so others after you do not have to reinvent the wheelreinvent the wheel• User Manual: Do this prior to design to make User Manual: Do this prior to design to make

sure the client’s requirements are satisfiedsure the client’s requirements are satisfied• Design Documentation: Make explicit decisions Design Documentation: Make explicit decisions

made during the design phasemade during the design phase• Do this right after assignment of responsibilitiesDo this right after assignment of responsibilities

Software ComponentsSoftware Components

• State vs BehaviorState vs Behavior• BehaviorBehavior consists of the actions the SW can consists of the actions the SW can

perform. Complete description is the perform. Complete description is the protocolprotocol• StateState is the data of the component is the data of the component• Most components are a combination of theseMost components are a combination of these• E.g. a Student (SW component) studies E.g. a Student (SW component) studies

(behavior), but has a record of courses (behavior), but has a record of courses completed (state)completed (state)

SW ComponentsSW Components

• CohesionCohesion: the degree to which the responsibilities : the degree to which the responsibilities of a SW component cohere, or form a logical unitof a SW component cohere, or form a logical unit• Associate methods that are logically relatedAssociate methods that are logically related• Try to maximizeTry to maximize• Consider a common data areaConsider a common data area

• CouplingCoupling: the degree of program dependence : the degree of program dependence between componentsbetween components

• Discourage outside methods from accessing private Discourage outside methods from accessing private datadata

• Minimize this dependenceMinimize this dependence

InterfacesInterfaces

• When offering component use, state only When offering component use, state only what what is being offered, not is being offered, not howhow it is it is implemented (information hiding)implemented (information hiding)• E.g. offer a E.g. offer a VectorVector class that allows insertions, class that allows insertions,

deletions, printing of objectsdeletions, printing of objects• Bottom Line: whether you use a list, an array or Bottom Line: whether you use a list, an array or

whatever is not important, no irrelevant.whatever is not important, no irrelevant.• Programming with no knowledge of Programming with no knowledge of

implementation detail is called implementation detail is called programming to programming to an interfacean interface

Interface QualityInterface Quality

• Cohesion – all of its methods are related to a single abstraction

e.g., public class MyContainer {}public void addItem(Item anItem) {….}public Item getCurrentItem() { … }public Item removeCurrentItem() { … }public void processCommand(String command) { … }…}

Don’t need Don’t need processCommandprocessCommand here!! here!!

Interface QualityInterface Quality

• Completeness – interface should support all operations that are a part of the abstraction that the class represents. e.g., The Stack class should contain a method to

check if the Stack is empty

Interface QualityInterface Quality

• Convenience – ensure that the interface makes it convenient for clients to do associated tasks, especially common tasks. e.g., Prior to Java 5 System.in could not read lines of

text or numbers. This was fixed by the addition of the java.util.Scanner class

Interface QualityInterface Quality

• Clarity – the interface should be clear to programmers e.g., LinkedList<String> list = new LinkedList<String>();

list.add(“A”);

list.add(“B”);

list.add(“C”); …

ListIterator<String> iterator = list.listIterator();While (iterator.hasNext())

System.out.println(iterator.next());…ListIterator<String> iterator = list.listIterator(); // cursor is just before the first elementiterator.next(); // advance cursoriterator.add(“X”); // AXBC…iterator.remove(); // the documentation is confusing – is X or A removed?

Interface QualityInterface Quality

• ConsistencyConsistency: the operations in a class : the operations in a class should be consistent with each other with should be consistent with each other with respect to names, parameters, return values respect to names, parameters, return values and behaviorand behavior• e.g.e.g.• from the Java Library:from the Java Library: new GregorianCalendar(year,month-1,day);new GregorianCalendar(year,month-1,day);

• The month is between 0 and 11 but the day is The month is between 0 and 11 but the day is between 1 and 31between 1 and 31

Parnas’s PrincipleParnas’s Principle

• How something is implemented should How something is implemented should never affect other SW componentsnever affect other SW components

• Certainly not: side effectsCertainly not: side effects• Always program to an interfaceAlways program to an interface• Interfaces do not have any information on Interfaces do not have any information on

how their specified behavior is implementedhow their specified behavior is implemented