OOP was designed to allow programmers to more elegantly model their programs upon real-world scenarios. It allows programmers to define things (objects) in their world (program), set a few basic properties, then ask them to do things. Consider an object of type Dogthere are many dogs in the world, but only one animal "dog." As such, we could have a blueprint for dogs, from which all dogs are made. While dogs have different breeds that vary a great deal, at the end of the day they all have four legs, a wet nose, and a dislike of cats and squirrels.
So, we have our dog blueprint, from which we might create a Poodle breed, a breed, and an Alsatian breed. Each of these is also a blueprint, but they are all based upon the Dog blueprint. From our Poodle breed, we can then create a Poodle, which we will call Poppy. Poppy is an actual dog, based upon the Poodle breed, and therefore also based upon the Dog blueprint. We can create other Poodles simply by creating an instance of that breed.
As all dogs are able to bark, we can add a bark( ) function (known as a "method," as it is inside a class) to our dog blueprint, which, in turn, means that the Poodle breed has a bark( ) method. Therefore, Poppy can bark( ) too. We can also define variables (known as "properties" inside objects) inside the dog blueprint, such as $Name, $Age, and $Friendliness. These also become available in the Poodle breed, which stems from the dog animal, and therefore into Poppy. Each object of type Poodle would have its own set of proprieties own $Name, its own $Age, etc.
Because the breeds stem from the Dog blueprint, we can also add methods and properties to breeds individually without having them in the Dog blueprint. For example, Poodles come in three general sizes: standard, miniature, and toy. Last time I checked, you don't get toy Alsatians, so putting a $Size property into the Dog blueprint would just create a property that is not used in a third of the dogs.
If you are still with me, then you are on the way to fully understanding how object-oriented code works.
So, we have our dog blueprint, from which we might create a Poodle breed, a breed, and an Alsatian breed. Each of these is also a blueprint, but they are all based upon the Dog blueprint. From our Poodle breed, we can then create a Poodle, which we will call Poppy. Poppy is an actual dog, based upon the Poodle breed, and therefore also based upon the Dog blueprint. We can create other Poodles simply by creating an instance of that breed.
As all dogs are able to bark, we can add a bark( ) function (known as a "method," as it is inside a class) to our dog blueprint, which, in turn, means that the Poodle breed has a bark( ) method. Therefore, Poppy can bark( ) too. We can also define variables (known as "properties" inside objects) inside the dog blueprint, such as $Name, $Age, and $Friendliness. These also become available in the Poodle breed, which stems from the dog animal, and therefore into Poppy. Each object of type Poodle would have its own set of proprieties own $Name, its own $Age, etc.
Because the breeds stem from the Dog blueprint, we can also add methods and properties to breeds individually without having them in the Dog blueprint. For example, Poodles come in three general sizes: standard, miniature, and toy. Last time I checked, you don't get toy Alsatians, so putting a $Size property into the Dog blueprint would just create a property that is not used in a third of the dogs.
If you are still with me, then you are on the way to fully understanding how object-oriented code works.
0 comments:
Post a Comment