Object-Oriented

Object-Oriented design and programming stands at times as confusing and\ or theoretical at best. Even greatly-experienced coders find themselves muttering "What the *$%& ?" occasionally, lost in a self-created world of classes, objects, and callbacks. The below paragraphs were taken from a programming forum and briefly explain a simple manner in which to view some of these areas of contention:

Originally Posted by Poisos (unedited)

Think of classes as your BLUEPRINTS for later manufactured objects! In your class definition you describe how you would build i.e. a car ... but since then there is no real car, right(only the pice of paper with your blueprint on it)? So you have to build a car according to this BP. This is done by making an instance of it.In Python: myCar = blueprint_of_a_car()

Now the little "data elves" in your computer actually build a car named "myCar". Now you would be able to drive that car or accellerate it and so an (ever drove a blueprint !?). This brings us to inheritance and polymorphism. If you would like to build a new car with special tires, seats or a different motor you wouldn't design a whole new car, now would you? Instead you would just change your motor or your tires and leave the rest as it is.

This is done by creating a new class (or blueprint) which inherits all the attributes and methods from your original car class (copy all information of your original blueprint to another) and then overrides the information i. e. of the type of motor what should be in the car (erase the data of your motor on
your copied blueprint and specify another one).