Object-Oriented Programming (You either GET IT or YOU DON’T) Part 3
This is the thrid and final post in a series of three that I am writing about the basics and understanding of Object Oriented programming and thinking.
Why Objects?
Simply put, because objects are so easy! I hope by now you are beginning to think objects are as easy as I do. The reason objects are so easy is because when you start thinking about your program or problem you can easily define business objects out of requirements and use cases defined from the business model. You can also follow these guidelines while you are programming. If you find yourself stuck wondering how an object should behave in the program all you have to do is find out how the object works in the real world and write the code to mimic that.
Objects build new Abstractions
What is Abstraction? In computer science, abstraction is a mechanism and practice to reduce and factor out details so that one can focus on a few concepts at a time. A good simple example of abstraction is square root. We don’t have to know how to get the square root of 144 we just know that it is 12. Good objects build new abstractions. What this means is that when you build an object that stores it’s own data, writes it’s own data to storage, validates itself, changes its’ own state, etc…; you have just built an abstraction. A fellow programmer can take that object and count on the fact that it will work the way it is supposed to.
The most powerful part of OO programming is that you don’t have to start from scratch on anything. Almost every language has objects that you can inherit from. You can also use frameworks and design patters to make your objects better. When you can inherit another object and simplify your coding and maintenance process then you have truly become an Object-Oriented programmer.
Putting it all together
As I am about to show, an object is just a class. If you have been writing classes and think those are different than objects that is a mistake. As I said above you can also make your own objects that extend other objects or classes. Then you can take your custom objects and write a custom collection to store, iterate, and use the custom objects you have created.
One of the most powerful thoughts in all of OO design is Encapsulation. The quick and dirty explanation of encapsulation is that as a programmer you get to control the method in which other programmers access your private variables and methods. I know that may have seemed a little complicated but it is really as simple as this:
private int _bookNumber = 0;
public int BookNumber
{
get { return _bookNumber; }
set
{
if(_bookNumber != value)
{
_bookNumber = value;
}
}
}
What this code does is encapsulate my private variable which is an integer inside a public integer that has some two “methods” get and set. Inside the get method I am telling the program to return the private variable _bookNumber just as it is. Inside the set method however I am making sure that the values are not the same before I waste the time to reallocate the same value to the private variable.
This code is just a small snippet of what you will find in an object. A good object has a bunch of these encapsulated variables and a lot of private and public functions. As you can see in the following code snippet I have created a complete object.
public class Book
{
private int _bookNumber = 0;
public int BookNumber
{
get { return _bookNumber; }
set {
if(_bookNumber != value)
{
_bookNumber = value;
}
}
}
private string _bookName = string.Empty;
public string BookName
{
get { return _bookName }
set
{
if(_bookName != value)
{
_bookName = value;
}
}
}
public Book()
{
//Empty Constructor
}
}
The code above is an extended version of the code snippet showing encapsulation. In this sample I have coded a complete object, simple but complete. Objects / Classes require three things to be valid: Name, Attributes, Methods. This class has all three.
I think that is about all the rambling I can do on this subject for now. Thanks for reading.