Software Construction: Object-oriented programming basics

Enable small, incremental changes by designing software around stable abstractions and interchangeable parts.

Object-oriented design is an iterative and exploratory process. Don’t worry if your initial design is ugly. If you apply the OO design principles consistently, your final design will be beautiful!

Every domain concept that plays a role in the application & assumes a responsibility is a potential object in the software design.

Well-designed objects have clear responsibilities.

Objects are responsible to maintain information & provide services.

Drive design by asking:

• What actions is this object responsible for?
• What information does this object share?

Every method should perform one, well-defined task.

A good design exhibits:

• high cohesion of operations and data within classes
• low coupling between classes and subsystems

An object should have no more than one key responsibility.

• The Scandinavian view is that an OO system is one whose creators realize that programming is modeling.
• The mystical view is that an OO system is built out of objects that send messages to each other, and computation is the messages flying between objects.
• The software engineering view is that an OO system is one that supports data abstraction, polymorphism by late- binding of function calls, and inheritance.

• Encapsulation
• Composition
• Responsibility Distribution
• Message Passing
• Inheritance

• Identify minimal requirements
• Make the requirements testable
• Identify objects and their responsibilities
• Implement and test objects
• Refactor to simplify design
• Iterate!

Formalize client / server contract as obligations.

Class invariant formalize valid state.

Pre- & post-conditions on all public services:

• Clarifies responsibilities
• Simplifies design
• Simplifies debugging

Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly keeping its meaning or behavior.

• Renaming methods, variables and classes
• Redistributing responsibilities
• Factoring out helper methods
• Pushing methods up or down the hierarchy
• Extracting class

• Duplicated code
• Long methods
• Large classes
• Public instance variables
• No / useless comments
• Unreadable code

• Formalize requirements
• Know when you are done
• Simplify debugging
• Enable changes
• Document usage