Object-Oriented Principles

1. Object-Oriented Principles Applications to Programming

2. Main Principles • Generate Reusable SW Components • Strongpoint of OOP technology • Supported by inheritance and composition • Always prepare for change • 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 • Isolate and reduce non-portable code • Reduce coupling (later)

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

4. Any Yet More • Team programming coordination • Keep what each team members knowledge of what other team members provide ata minimum • Encapsulate, i.e. isolate and insulate data • Data Hiding (closely related to the above) • Keep SW component interaction at a minimum

5. Documentation • 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 • Design Documentation: Make explicit decisions made during the design phase • Do this right after assignment of responsibilities

6. Software Components • State vs Behavior • Behavior consists of the actions the SW can perform. Complete description is the protocol • State is the data of the component • Most components are a combination of these • 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 • Associate methods that are logically related • Try to maximize • Consider a common data area • Coupling: the degree of program dependence between components • Discourage outside methods from accessing private data • Minimize this dependence

8. Interfaces • 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 • 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

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<String> list = new LinkedList<String>(); 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 • e.g. • from the Java Library: new GregorianCalendar(year,month-1,day); • 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 • Certainly not: side effects • Always program to an interface • Interfaces do not have any information on how their specified behavior is implemented