The Trick Of The Mind - The Benefit Of Objects
Written by Mike James   
Wednesday, 01 October 2025
Article Index
The Trick Of The Mind - The Benefit Of Objects
Inheritance

Objects seem to emerge as something almost natural, but what advantages are there in making use of them? This is an extract from my book Trick of the Mind which explores what it is to be a programmer.

The Trick Of The Mind - Programming & ComputationalThought

Buy Now From Amazon

Trick360

Chapter List

  1. The Trick Of The Mind

  2. Little Languages
       Extract: Little Languages Arithmetic
      
    Extract: Regular Little Language

  3. Big Languages Are Turing Complete

  4. The Strange Incident of The Goto Considered Harmful
       Extract: The Goto Considered Harmful

  5. On Being Variable  

  6. Representation

  7. The Loop Zoo
       Extract The Loop Zoo
      
    Extract Advanced Loops

  8. Modules, Subroutines, Procedures and Functions
       Extract Modular Programming

  9. Top-Down Programming 

  10. Algorithms
       Extract: Binary Search 
       Extract: Recursion

  11. The Scientific Method As Debugging 

  12. The Object Of It All
       Extract Why Objects 
       Extract The Benefit Of Objects ***NEW!!

 <ASIN:1871962722>

<ASIN:B09MDL5J1S>

We looked into how objects evolved out of data structures now it is time to see what else we get by adopting objects.

In chapter but not in this extract

  • The Object Of It All
  • Active Data – The Object
  • Instances & Class

Polymorphism

The big advantage of creating and using objects is that the routines are tied to the type of data they are designed to work with. If you have a sort method defined on a list:

List.sort(order)

then it clearly only knows how to sort a list into order. If you want to sort something else that you will need to define a new sort routine associated with that particular type of data. This is sometimes a problem when you need a routine that works on a very wide range of data and it is something that the object-oriented method has yet to find a good solution to. The only real way of doing this is to allow routines to be defined without an associated data object and this goes against the basic ideas of using objects.

This tying of routines to data may have its disadvantages but it is also one of the big advantages of objects. It means you don’t have to worry which sort routine to use in any particular case. For example, suppose you have different types of lists – lists of numbers, lists of names and so on. Then, if there is a different sort routine for each, you have to know which sort routine to use:

mylist.sortNumbers(order)
mylist.sortNames(order)

and so on depending on what sort of list myList was. However, using the object-oriented approach, each type of list has its own implementation of sort and so we can write:

myList.sort(order)

and be sure that the correct routine is being used for the data to be sorted.

This is a simplification in that it stops the programmer from having to think about which particular routine is needed and it is called “polymorphism”. Using polymorphism it is often possible to remove conditionals that would otherwise be needed to test the type of object in use and this is sometimes called “If-less programming”.

Polymorphism is a direct result of the idea that the data should know how to do something to itself and it is one of the attractive features of using objects, but in practice the gains are usually small. Nearly all modern object-oriented languages are class-based but there are exceptions. JavaScript, for example, uses prototype objects and object factories as an alternative.

Encapsulation

Another advantage of objects is that you can allow the object to have an internal life that you know nothing about and have nothing to do with. For example, perhaps the name and address object might keep its internal working private and only let you access the data via routines, generally called “accessors”:

myDetails
	name: mike
	address: 1 FORTRAN avenue
	age: 18
	Retire: Return 70-age
	getName: Return name

Now if you try to directly access the name field:

myDetails.name

the program will return an error that tells you that name is inaccessible. If you want to retrieve the name you have to use the getName method:

myDetails.getName()

At first this seems like a crazy idea. Why do this at all? The answer is that now we are free to use any method of storing the name we like and it can be modified without the external world being affected in any way. The accessor method isolates what you want from the way that it is implemented.

The accessor can also perform checks that the name is valid or correctly formatted or perform any processing needed before delivering the internal representation of the name to the user. This is often put forward as the main reason for using accessors and not allowing the user access to the fields is seen as a bonus. In fact it is the other way round.

How much objects keep their inner workings to themselves varies according to the way the language enforces private fields. In the most extreme cases an object is a black box that you can only make use of via its methods. In the least strict cases an object is a black box that you just promise not to look inside of.

cover600

 



Last Updated ( Wednesday, 01 October 2025 )