- Many of today's most popular programming languages are object oriented, but that's not the only way to program. To understand when and why using object oriented languages can be beneficial, it helps to compare it with a common alternative. Procedural programming languages like plain C. In procedural code, the program is written as a long series of operations to execute. Now, some of that might be organized into named functions or sub-routines to make the code modular and maintainable, but the end goal is really just to get from Point A to Point B to complete some task.
It's a straight forward approach that I like to relate to writing a recipe for a cookbook. The program or recipe to say, bake a cake, would list the sequence of steps you need to follow. Mix the ingredients together, pour them into a cake pan, and put it in the oven. Just execute those steps in that order and voila, a cake. I've found that new programmers have a tendency to write code in this procedural manner because it's easy to think of simple programs in terms of sequential steps.
- Right, and to approach that same task of baking a cake in an object oriented manner rather than describing a sequence of steps, I'll describe each of the objects in my kitchen, the pan, the oven, and the mixer, and what each one can do. So, instead of writing a single large program, my object oriented code is split apart into several self contained objects. Almost like several mini programs where each object contains its own data and logic to describe how it behaves and interacts with other objects.
The idea here is that we can talk about and use these programmed objects similar to objects in the real world. The mixer can mix ingredients together. I can pour the mix into the pan and the oven can bake whatever I give it. The end result of Barron's procedural approach and my object oriented approach is the same. We both made a cake, but the way we thought about the problem and organized our code was very different. - Now, neither of these two approaches is better than the other all of the time.
Each has its own advantages and disadvantages that apply to different situations. - One of the main advantages of using an object oriented approach is code re-usability. If we want to make something other than a cake, perhaps muffins, I've already created the functionality to mix and bake things in the mixer and the oven. So I can reuse those objects. I'll need to define one new object to make my muffins, a muffin tray, but I can base the muffin tray on the cake pan object that I already have because they have a lot in common, holding ingredients that go into the oven.
Realize that object oriented programming is not itself a language. Object orientation is referred to as a programming paradigm. A set of ideas that's supported by many languages. - And there are other programming paradigms beyond just procedural and object orientation. If you take a computer science course, you might encounter logic programming languages, like Prolog. Or functional programming languages, like Haskell. However, those both tend to live in very specialized environments.
For the practical, pragmatic world of creating web applications, mobile apps, desktop applications, or game development, you'll almost certainly be using object oriented programming languages. In fact, all of the top high demand languages today are object oriented. Now, many of those languages support multiple paradigms. Meaning you can use them to write code in an object oriented way or in a procedural way. Your choice. When I was first learning object oriented programming in college with Java, I found that most of the small classroom programs I had to write, would have been way quicker and easier to hack together using a procedural approach.
The amount of object oriented code I had to write to get things working often felt bloated and way beyond the scope of those projects. And you may find yourself feeling the same way as you're learning, just keep in mind we use small, simple examples to learn but the real value of object orientation will appear as your projects grow in scale and require changes.
- Object-oriented basics: objects, classes, and more
- Defining requirements
- Identifying use cases, actors, and scenarios
- Domain modeling
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Developing software with object-oriented design principles