1. Object-Oriented Principles Applications to Programming

2. Main Principles Generate Reusable SW Components Generate Reusable SW Components Strongpoint of OOP technology Strongpoint of OOP technology Supported by inheritance and composition Supported by inheritance and composition Always prepare for change Always prepare for change If your SW is successful, your client will want a new, different version If your SW is successful, your client will want a new, different version Identify the points of change in your application (tension points) and try to minimize them Identify the points of change in your application (tension points) and try to minimize them Isolate and reduce non-portable code Isolate and reduce non-portable code Reduce coupling (later) Reduce coupling (later)

3. More Principles Put your data first Put your data first It is less likely to change over time It is less likely to change over time Tasks are mutable Tasks are mutable Assign responsibilities Assign responsibilities Determine what your classes and methods do Determine what your classes and methods do Decide what needs to be done, then decide who will do it Decide what needs to be done, then decide who will do it Walk through a scenario and assign activity to components as responsibility Walk through a scenario and assign activity to components as responsibility Use CRC cards Use CRC cards

4. Any Yet More Team programming coordination Team programming coordination Keep what each team members knowledge of what other team members provide ata minimum Keep what each team members knowledge of what other team members provide ata minimum Encapsulate, i.e. isolate and insulate data Encapsulate, 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 minimum Keep SW component interaction at a minimum

5. Documentation Document so others after you do not have to reinvent the wheel Document so others after you do not have to reinvent the wheel User Manual: Do this prior to design to make sure the client’s requirements are satisfied User Manual: Do this prior to design to make sure the client’s requirements are satisfied Design Documentation: Make explicit decisions made during the design phase Design Documentation: Make explicit decisions made during the design phase Do this right after assignment of responsibilities Do this right after assignment of responsibilities

6. Software Components State vs Behavior State vs Behavior Behavior consists of the actions the SW can perform. Complete description is the protocol Behavior consists of the actions the SW can perform. Complete description is the protocol State is the data of the component State is the data of the component Most components are a combination of these Most components are a combination of these E.g. a Student (SW component) studies (behavior), but has a record of courses completed (state) E.g. a Student (SW component) studies (behavior), but has a record of courses completed (state)

7. SW Components Cohesion: the degree to which the responsibilities of a SW component cohere, or form a logical unit Cohesion: the degree to which the responsibilities of a SW component cohere, or form a logical unit Associate methods that are logically related Associate methods that are logically related Try to maximize Try to maximize Consider a common data area Consider a common data area Coupling: the degree of program dependence between components Coupling: the degree of program dependence between components Discourage outside methods from accessing private data Discourage outside methods from accessing private data Minimize this dependence Minimize this dependence

8. Interfaces When offering component use, state only what is being offered, not how it is implemented (information hiding) When offering component use, state only what is being offered, not how it is implemented (information hiding) E.g. offer a Vector class that allows insertions, deletions, printing of objects E.g. offer a Vector class that allows insertions, deletions, printing of objects Bottom Line: whether you use a list, an array or whatever is not important, no irrelevant. Bottom Line: whether you use a list, an array or whatever is not important, no irrelevant. Programming with no knowledge of implementation detail is called programming to an interface Programming with no knowledge of implementation detail is called programming to an interface

9. Interface 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 processCommand here!!

10. Interface 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

11. Interface 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

12. Interface Quality Clarity – the interface should be clear to programmers   e.g.,   LinkedList list = new LinkedList (); list.add(“A”); list.add(“B”); list.add(“C”);   …

14. Interface Quality Consistency: the operations in a class should be consistent with each other with respect to names, parameters, return values and behavior Consistency: the operations in a class should be consistent with each other with respect to names, parameters, return values and 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 between 1 and 31 The month is between 0 and 11 but the day is between 1 and 31

15. Parnas’s Principle How something is implemented should never affect other SW components How something is implemented should never affect other SW components Certainly not: side effects Certainly not: side effects Always program to an interface Always program to an interface Interfaces do not have any information on how their specified behavior is implemented Interfaces do not have any information on how their specified behavior is implemented