The Trick Of The Mind - Why Objects
Written by Mike James   
Wednesday, 26 July 2023
Article Index
The Trick Of The Mind - Why Objects
Instances & Class

Objects are at the core of modern programming but they aren't fundamental to programming. Why do we complicate things so? 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

  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 ***NEW!!

  11. The Scientific Method As Debugging 

  12. The Object Of It All
       Extract Why Objects 

 <ASIN:1871962722>

<ASIN:B09MDL5J1S>

In this chapter we look at the currently most popular approach to programming – Object-Oriented Programming (OOP). What is surprising is that this approach introduced very little that is new. It is mostly about improving the way we package programs for consumption by other programmers than about any deep philosophical or theoretical ideas. There are some deep theories about OOP, but most of the benefits of the approach are entirely independent of these. It is more a practical way of presenting useful modules to other programmers so that they can be easily used than a deep revolution in how we think about programming. Even so, it is currently the number one programming methodology and as such we need to know about it.

Active Data – The Object

The idea of objects originated in a very different place from its motivation today. Rather than confuse the issue by going over its history, it is preferable to explain the idea as it is understood today. If you have a routine, Sort, that sorts an array or list of items then you use it something like:

Sort(mylist1,order)

where mylist1 is the list to be sorted and order is used to indicate the sort order. This is easy enough to use, but if you have another list of items to sort you have write something like:

Sort(mylist2,order)

This too seems innocent enough and no trouble at all but there is a sense in which the Sort routine “belongs” to the list of things being sorted. After all sorting the list depends on it being a list – you can’t apply a sort to anything that isn’t a list. This thinking leads on to the idea that perhaps the list should “know” how to sort itself.

That is, the sort routine should be considered as part of the list and we need to write:

mylist1.sort(order)

This has the same effect as the previous sort method, but has been rewritten to emphasize that the sort routine is part of the list. If you remember back to Chapter 6 where records and structs were introduced, you will recognize the use of the dot notation to indicate a field name. This corresponds to the idea that now the list is regarded as a struct with the sort routine as one of its fields. This sounds complicated, but suppose you have a name and address struct:

myDetails
	name: mike
	address: 1 FORTRAN avenue
	age: 18

You would write

myDetails.name

to retrieve mike. Why not allow structs to have fields that are routines:

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

In this case the Retire field is a routine that works out how many years to retirement and you would use it something like:

myDetails.Retire()

In the jargon myDetails is an “object” and Retire is a “method.”, Put another way, an object is a struct that has routines as well as data as its fields. It is also usual to call the data fields of an object “properties” or “attributes”.

There are many ways to think of object and methods, but the result is functionally the same. You have an entity which has data and routines and the routines operate automatically on the data. So:

myList1.sort(order)

sorts the data in myList1. As already mentioned, it is as if the list of items knew how to sort itself.

Trick180

 



Last Updated ( Wednesday, 26 July 2023 )