Decoding Object Oriented Design
OOD has been around since mid 60’s. The concept didn’t really pick up until early 90’s with C++. It’s receiving a lot of attention in Rails/Ruby community as well.
The following is a guest post by Jenya Zueva and originally appeared on her blog. Jenya is currently a student a The Flatiron School. You can follow her on twitter here.
OOD has been around since mid 60’s. The concept didn’t really pick up until early 90’s with C++. It’s receiving a lot of attention in Rails/Ruby community as well. The concept might appear hard to understand, but it’s important. Below, I have attempted to collected resources and statements that suppose to make it clear to me.
OOD includes:
- Code that is broken down into separate objects that help to organize data
- Data isolated into restricted area where only specific procedured had access to it
- Objects that encourage reuse of code (minimal inner dependancies)
- Data that stays separate from actions
- Objects that represent one item
Object Oriented Language should include:
Class Blueprint/prototype that defined variables or methods common to all objects of a certain kind.
Object An instance of a class. A class must be instantiated into an object before it can be used in the software. More than one instance of the same class can be in existence at any one time.
Encapsulation Placing data and the operations that perform on that data in the same class. The class becomes a ‘capsule’ or container for the data and operations.
Inheritance The reuse of base classes (superclasses) to form derived classes (subclasses). Methods and properties defined in the superclass are automatically shared by any subclass.
Polymorphism Same interface, different implementation. The ability to substitute one class for another. This means that different classes may contain the same method names, but the result which is returned by each method will be different as the code behind each method (the implementation) is different in each class.
What ODD helps you do is to delegate most of the repetititve logical work to the data itself. Data is becoming active, instead of staying passive.
Lost yet?
Ask yourself the following questions. If you answer yes to any, refactor:
- Is it the role of this class to know how to do something?
- What should be defined as a class?
- What sort of class hierarchy would be best?
What’s that smell? (simplified)
If you see any of the following in your code, refactor:
- Duplication of code
- Extensive length of class or method
- Large amount of parameters
Resources:
1. Object Oriented Design Li Ouyang
2. Code Smells by Jeff Atwood
Disclaimer: The information in this blog is current as of November 9, 2012. Current policies, offerings, procedures, and programs may differ.
