Object Oriented Programming (OOP) is one of the most useful high level concepts that a programmer can know. This article looks to give a short introduction into what it is, and how to use it.
While class is certainly important to have in real life, it is equally important to have while programming. Taking advantage of an Object Oriented Programming method (or OOP method) may very well be one of the most important higher concepts to learn and understand. This article helps cover what OOP is, its benefits, and how to use it.
In the real world each thing, or object, acts independently of everything else with no interconnected reliance. Objects can react to other objects, but do not necessarily depend on other objects. Note: there are objects which are entirely dependent on other objects, but we'll get to that. If you have just started programming you likely will have noticed that the program as a whole runs in a very linear fashion with events occurring in a very specific order. To get around this many programming languages have implemented a class based architecture. Even Objective-C has structs which function in a similar manner.
What is a class exactly? Succinctly, a class is whatever you want it to be. At its most basic level, a class is an object that you define yourself. What a class does is entirely up to you, but you will want to put some thought into constructing it to make sure it behaves as you intended. Classes allow you to group functions, variables, and even other classes into one contained object that does not interfere with other objects.
Does not interfere? What if it needs to? Well, that's where access identifiers come in. They let you determine what can access the particular variable/function. There are three main access modifiers, and one that is less well known. The three main modifiers are (ordered by access level):
Public
Protected
Private
The last modifier is internal, it is not very well known, and has limited to no use in smaller projects and therefore will only be covered briefly.
First is the public access modifier. Public variables, functions, classes, etc. Can be accessed and modified by anything and everything. Some will say that one should never have public data, and others will say to use it with extreme caution. I fall in the latter camp personally. Ideally you only ever want to have a variable public if you want it to be modified by an external process, otherwise it is better to have it be a protected or private variable and then define a public function that allows the data to be read by other processes. To some this does seem much, but it all depends on your security needs, and whether or not you are the only one who will ever work on the project. A good rule of thumb is, "if you do not want it modified by just about anything, don't make it public." One exception is in Unity where a variable must be public in order to allow modification of said variable within the inspector tab(s).
Protected methods can be accessed by the class they are defined in, as well as any other class that is built on top of the class. This brings us to the topic of inheritance, which will be covered briefly before moving on to the private and internal definitions.
To better understand inheritance we need to look at a real world example. Chances are you know what a car is, what it does, and generally how to use one. Most cars function the same, but yet are very different. One main difference is Manual vs. Automatic transmission. Aside from that there are sports cars, luxury cars, commercial vehicles, and many many more. Yet these are all cars, and they all have many things in common: wheels, brakes, an engine, the need for gasoline, a battery, drive shaft, steering wheel, lights, horn, and on and on. To represent this in programming you would create a car class, then you would probably make several other classes based on these for the different vehicle types. To do this you would use the extends keyword followed the class which this class is to be based upon. This new class will have access to absolutely everything that its parent has access too, except private members. As mentioned above, protected members can be accessed only by a class and its sub-classes.
This brings us to the last of the three main access modifiers: private. The private modifier lets the defined method only be accessed by the class itself, and absolutely nothing else, not even derived classes. Taking the real-world car example, the basic car class would probably define how the engine works to produce thrust, but any sub-class would simply access the accelerate function instead of directly modifying the various engine components required to make acceleration happen. Thus, opening the valves, controlling airflow, fuel injection, ignition sequence, and exhaust are private, and for good reason too. Imagine having to control all of that every single time you wanted one of the cars to accelerate, instead of just pushing a handy little pedal.
The internal modifier is not very well known because it limits access to the assembled package. This means that only this program, and no other program, can access the method. This can be handy if you are building a DLL file and want certain methods public within the DLL, but not available outside of its local program scope. Reading that definition may make you wonder why internal is needed at all since most everything is limited by its scope. The key thing here is classes. In particular you want a class accessible within a DLL for instantiation, but not available outside of it because the name it uses might clash with something else, or because it is a security concern. As aforementioned, this modifier is used very little in smaller projects.
"That's all well and good," you might say, "but how do I actually use classes in my workflow?" There are a few things to keep in mind when constructing a class, and it can help to diagram out what is to do what well ahead of actually implementing anything. This will prevent you from having to come back and restructure the class an untold number of times.
Classes typically require a public function of the same name as the class which acts as the instantiation method. What this means is that when you define "ClassName obj = new ClassName(a, b, c);" the parameters listed by your favorite IDE are pulled from the function with the same name as the class you are creating, which in this case is ClassName. It is possible, at least in every language I have encountered besides Objective-C, to have multiple, or overloaded, functions with the class name. This will allow for different ways to create the object depending on the circumstances and the amount of information actually required.
In many cases it is also beneficial to have at least one commonly named update function whose function name exists in all necessary classes to provide a simple means of running standard loop logic. That way in the main body of the program you could just iterate through all objects and call their update functions, if they exist.
Likewise it is a good idea to come up with a naming convention for various types of input. Windows allows you to register a listener function for keyboard, mouse, and other input. Within the function it would be very easy to call the respective listener functions of everything in your program if they all had similarly named listener functions.
Ultimately classes are the best way to have a modular system, and there are very few applications that could not benefit from such an approach. I strongly suggest reading more about classes and the OOP method for your respective programming language. It can only help.
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
