The Trick Of The Mind - Why Objects |
Written by Mike James | |||
Wednesday, 26 July 2023 | |||
Page 1 of 2 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 & ComputationalThoughtBuy Now From Amazon Chapter List
<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 ObjectThe 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. |
|||
Last Updated ( Wednesday, 26 July 2023 ) |