by kirupa | 17
December 2008
If you look around you, you will see a lot of things. These things may
seem pretty simple and straightforward, but when looked at carefully,
they are probably made up of other things. Let's take a lamp as an
example:
If I were to take the lamp apart, I would be left with the following
three pieces:
The base and the shade are pretty much it - there isn't much to them.
The lightbulb inside my lamp is different though. It is a pretty
complicated item with various parts of its own:
Putting all of these things together though, I have collectively what
one would call a lamp despite the individual parts being different and
of varying complexity.
Now, I just used a simple lamp as an example of something that is
made up of many other things. If you were to take something more
complicated like your laptop or desktop, the hierarchy of parts and
components would take many pages to just list!
Ever since the widespread adoption of
interchangeable parts and the
assembly line, many things we use today are divided up and broken
into smaller components. The reasons for this are many. Some of the
common ones are the following:
- Maintenance
If something were to go wrong, instead of replacing the whole thing,
you just replace the part that does not work. When your lamp's
lightbulb goes out, you just change the lightbulb. You don't change
the entire lamp itself.
- Specialization
One person or company no longer had to have all of the expertise in
manufacturing everything. Different people and companies could focus
on the things that they were good at.
- Fault Isolation
While this may be a double-edged sword, having various distinct
components each doing their own task makes it easier to isolate and
detect errors that crop up.
There are other advantages, but to be relevant for this article, the
above three are good for now.
The level of componentization many everyday things contain extends to
the world of software as well. A lot of the software you use is also
made up of many components working together. Very few things are written
in one giant, monolithic piece.
In the series of articles that I will be discussing here, you will
learn the basics of how to write software by breaking them down into
smaller objects and making them work together. This way of writing
software is known as Object Oriented Programming, or OOP for short.
There are many sub-topics that go into object oriented programming.
The most basic of which is the idea of classes and objects - the actual
blocks that make up your application:
You then have things like inheritance where one object is based on
another object:
To help standardize the communication between classes, you have
things such as interfaces where you define a contract that each class
must implement:
Within each of these topics, there are many more details that you
would need to know. Such details include properties, methods, functions,
abstract data types, constructors, class modifiers, polymorphism,
overloading, etc. If all of these terms seem scary to you, don't worry.
In time, all will make sense after you see them presented in a
friendlier fashion outside of a long sentence meant to intimidate you.
I should confess that, while I tried to show you the relationship
between the real world and object oriented programming, the mapping
isn't exact. You can find examples and counterexamples easily.
What is important is the big-idea behind OOP that everything is
represented as objects. Instead of having large blocks of functionality,
you will often have many smaller pieces that combine to create the
functionality you desire instead. How those pieces are defined, how they
come together, and how they play with each other will be covered in
greater detail in future articles.
Need Help?
If you have questions, need some assistance on this topic, or just want to
chat - please drop by our friendly forums
and post your question. There are a lot of knowledgeable and witty people who
would be happy to help you out. Plus, we have a
large collection of smileys
you can use
Share
Did you enjoy reading this and found it useful? If so, please share it with
your friends:
If you didn't like it, I always like to hear how I can do better next time.
Please feel free to contact me directly at kirupa[at]kirupa.com.
Cheers!
|
Introduction to OOP
