Introduction to OOP

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:

1. 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.
2. 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.
3. 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.

Entering the Software World
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.

Conclusion
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.

Just a final word before we wrap up. If you have a question and/or want to be part of a friendly, collaborative community of over 220k other developers like yourself, post on the forums for a quick response!