The Trick Of The Mind - Why Objects |
Written by Mike James | ||||||
Wednesday, 26 July 2023 | ||||||
Page 2 of 2
Instances & ClassNow we come to an aspect of objects that confuses the beginner and expert alike. So far we have discussed objects, but we haven’t considered the mechanism by which we can obtain multiple objects of the same type. For example, we might well define a Person object with properties and methods, but we most likely want multiple copies of the object so we can represent multiple people. What we have been calling objects are more properly called “instances” of a particular type of object. The question is how do we formalize the way we can create multiple instances of the same type of object? There are a number of approaches to this problem, but the most commonly encountered is the class mechanism. A “class” is a specification for a particular type of object. Once you have an object defined by a class you can use the class to create as many instances of the object you require. The class is like a template that allows you to “stamp out” as many instances of the object as you need. Typically you might create a Person class: class Person name: string address: string age: number Retire: Return 70-age Notice that following the name of each field we state what sort of data is going to be stored, but this isn’t essential to the idea. Once we have a class defined we can use it to create as many instances as we like: me = new Person(Mike, 1 FORTRAN Drive, 18) mickey = new Person(Mickey, Disney Road, 65) In this case me and mickey have a name field, an address field, an age field and a Retire method. This means you could write things like: me.name mickey.Retire() and so on. Obviously the output of the first is Mike and the second is 5. Notice that the properties and methods all work on their respective instance data, i.e. it may seem obvious that mickey.Retire() computes the retirement based on mickey.age, but in practice this is tricky to implement. The usual solution is to simply pass the instance as the first parameter of the method. That is: mickey.Retire() is actually implemented behind the scenes as: Retire(mickey) This also means that methods all have a default first parameter which is traditionally, but not universally, called this. The use of the term this is widespread, and leads to much confusion, self is also used and is also the cause of much confusion. Sometimes finding good names for things is very important. The introduction of classes also causes a problem with naming, especially for beginners. The problem is particularly acute when you only need one instance of a class, known as a “singleton”. Suppose you need a single object called MasterRecord. You first need to create a class. What do you call it? Probably MasterRecord. Now you have the class you can create an instance. What do you call it? You probably want it to be MasterRecord – but of course you can’t. In a language that takes notice of upper and lower case the best you can do is something like: masterRecord = new MasterRecord() which introduces a convention that classes are named with a starting capital letter. Some find this confusing because it seems we have lots of things called masterrecord with only changes to where the capital letters are. The fact that you need a name for the class and names for each of the instances can sometimes be a problem. In Chapter but not in this extract
Summary
The Trick Of The Mind - Programming & ComputationalThoughtBuy Now From Amazon Chapter List
<ASIN:1871962722> <ASIN:B09MDL5J1S> To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.
Comments
or email your comment to: comments@i-programmer.info |
||||||
Last Updated ( Wednesday, 26 July 2023 ) |