Hi Nick, An object is a specific way to define and design a module and a module is a tool for segmenting, modularizing, the source code (what the programmer actually writes, not what the machine executes) for a program. To parse this assertion - and then to explain how and why object modularization is different - a quick aside to discuss a program is in order. I use 'program' to mean the source code - the lines of COBOL, java, C++, or Smalltalk that the programmer writes. I am sure you have seen BASIC programs. The source code consists of a list, each entry on that list having a sequence number and a BASIC statement. The computer will execute that program one line at a time in sequence: the statement on line 1 then line 2 ... Some of the statements, say the one on line 20 wont tell the computer to do something, instead they tell the computer to GOTO some other line number and resume executing instructions. Several different types of control structures are available. It takes little imagination to realize the larger the program the greater the difficulty in understanding what the computer might be doing at any specific time - especially if you also, simultaneously, need to track the values of numerous variables to see which branches are active. Hence the desire for modularization - packaging blocks of code lines into identifiable units - to simplify the process of reading a program and the mental modeling of what the program would be doing at any phase of execution. Now add Dikstra's famous definition, "a program is algorithms plus data structures." The first criteria for defining a module involved grouping lines of code that were related by prodecure, (essentially all lines participating in the same algorithm) - hence procedural programming with four kinds of modules: control, afferent, transform, and efferent. For various reasons, procedural modularization was unsatisfactory and, noticing that data structures were more stable over longer periods of time, data oriented modularization became the norm. You defined an entity as a data structure with members called attributes and aggregated all the procedures that operated on that specific data into a module. A DOS utility is probably written in C or Assembler, neither of which afford much opportunity for modularization, and is small enough that it does not need to be broken up. A tool in Matlab is likely a large program and if you could see the source code you would see modularization, probably more procedural in nature than data oriented. Note that both approaches to defining modules are focused on the program itself and how it can be broken up and the pieces related to each other. The same thing is true of "functional programming," i. e. the focus of design is inward towards the computer. Then came 'objects'.
First critical difference: an object is not a way to modularize the program, it is a means for modularizing the World, the problem space. Second critical difference: one object is differentiated from another solely on the basis of behavior - what it does, what contribution it makes to the overall system, what services it provides to other objects. These two characteristics of objects are why Harman borrows the term for his Object-Oriented Ontology. The term Object-oriented programming was coined by Alan Kay and the metaphor he used to communicate the idea behind the term was was a biological cell consisting of an encapsulation boundary, inside of which was all the complexity that allowed the cell to do what it did, and outside of which was a protocol that allowed other cells to communicate with and request services from the cell. Unfortunately, very, very, few in the programming community "got the memo" and understood what an object was supposed to be, or how it could be implemented in a programming language. So, it is extremely rare to find any code, even in Smalltalk, but definitely in Java or C++ that even remotely resembles the object idea. Alan Kay maintains, to this day, that the object revolution has yet to happen. BTW all modules, and all executing programs for that matter, are intended to be "black boxes" - you have no idea, and do not care, what is inside of the box, only what outputs the box will provide you in exchange for what inputs. Long winded, and I hope not remedial, answer. davew On Tue, Jul 17, 2018, at 8:06 PM, Nick Thompson wrote: > Dave, and anybody else who wants to play. > > I have always been puzzled by the question of how one distinguishes an > object in object programming from a utility in DOS or a tool in > Matlab. Or any mathematical function, for that matter. You give it > what it needs, and it gives you what it’s supposed to, and you don’t > give a damn how it works.> > Please don’t yell at me. > > Nick > > Nicholas S. Thompson > Emeritus Professor of Psychology and Biology > Clark University > http://home.earthlink.net/~nickthompson/naturaldesigns/ > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com > FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove
