150 likes | 243 Views
Object-Oriented Principles. Applications to Programming. 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
E N D
Object-Oriented Principles Applications to Programming
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)
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
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
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
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)
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
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
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!!
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
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
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”); • …
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
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