That WIKI definition <http://en.wikipedia.org/wiki/Object-oriented_programming> will leave you confused if youre learning OO for the first time.
Heres a hard physical-sciences analogy: * In physics, you have Statics and Dynamics. * In biology, you have Anatomy and Physiology. * In molecular biology, you have Structure and Function. * In languages, you have Nouns and Verbs. * In chaos theory, you have the system (e.g. a differential equation), and its phase space <http://en.wikipedia.org/wiki/Phase_space> . * In general, you have the part that doesnt change, and the part that does. In computers, you also have the part that doesnt change. Depending on the vernacular context, these static parts are called a Types, Structures, Schema, Address locations, Code/Instruction Libraries, and Classes. You also have the part that does change. Again, depending on the circle of nomenclature, these dynamic parts are called Values, State, Execution/Run, and Objects. When talking about code, the actual instructions are the static part, and stored in memory (or disk). The actual execution of this code is the dynamic part and run by a processor (or virtual runtime environment). A dynamic part always presupposes a static part. You cannot understand a VERB unless a NOUN is implied. One must study anatomy first before physiology; numbers before functions; etc. Programming languages, like mathematics, is a method for humans to transmit these concepts and ideas to other humans via an alphabet or symbolic scheme. Compilers transform programming languages into that which a computer can understand. This is how computational science goes one step further than mathematics. All languages (programming, mathematical, and natural) must model both the statics and the dynamics of their system when describing it. Natural languages combine nouns and verbs to get sentencestheir smallest unit of information. Programming languages combine structures and code to get functions. A subroutine is a function with no return value. Different naturally languages have different syntax. German ends sentences with verbs. English puts them closer to the beginning. Programming languages have similar analogies too. Structured programming languages (Pascal, C, FORTRAN, LISP) begin with functions that operate on specific structures (called parameters). They are verb-oriented in nature. Object-oriented programming languages (Java, C#, CLOS) begin with structures (called classes) that send messages to methods. They are noun-oriented in nature. In a structured programming language, I might write: FLIP(Pancake, Quickly) In an object-oriented programming language, I would write Pancake.FLIP(Quickly) For an English analogy, we have an obvious noun (the subject) called Pancake. Theres a verb: To Flip. We have parameters that we pass in to the function call to modify its behavior. If the parameter is a constant, like Quickly, we call it an adverb. If it is another object, we call it a direct object, or indirect object, or prepositional objectdepending on its English use. Properties of an object are called adjectives. When you see a declaration in code that looks like this (regardless of whether its structured or OO): int i = 5 to declare an integer called i" that contains the value 5, int is the class (or structure, or type) and i is the object. 5 is the initial state of the object. If you want to convert this number to a string in a structured programming language, you might write this: ToString(i) To do the same in an object-oriented language, youd write i.ToString() Its all syntax! Just like there is nothing in English I cant say in German, theres no system modeled in an object-oriented programming language that I cannot express in a structured programming one. In case you read articles on the net, here are some vocabulary use cases: * Classes store the static non-changing parts of a system in memory (or disk). Classes contain static structures (or types) called fields or attributes, and static code called methods. * Objects are classes that are being run by the processor (or the virtual runtime environment). Their fields (called properties) have actual values (the dynamic parts). This is why we say that objects have state. * The same class can be copied into memory multiple times (called instances, or just objects) each being submitted to a processor and each having different state. This is why we say that objects have identity. * Every method in a class operates on a specific object instance of it. This is why we say that objects have behavior. When a method is executed, it is called a message. * Static methods; dynamic messages. Static fields (or attributes); dynamic properties. Static types (or schema); dynamic state. To understand ABMs, like understanding anything, I suggest this approach: form a paradigm by understanding the static parts first, and then observe (or deduce) the dynamics in the context of the statics. The more chaotic, less rigorous approach, involves looking at all the dynamics simultaneously (or participating in those existential terms) and then trying to infer the structure. I think this latter approach leads to confusion, frustration, and post-modernistic dialogs. When the only way to understand the statics is by black-box observation of the dynamics, then use the scientific principle: fix all but one dynamic, and vary it in a controlled manner. Robert Howard Phoenix, Arizona _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Holmes Sent: Saturday, June 02, 2007 9:48 AM To: The Friday Morning Applied Complexity Coffee Group Subject: Re: [FRIAM] Fwd: ABM Here's a couple of sites that could be worth checking out Phil: http://www.google.com/search?hl=en <http://www.google.com/search?hl=en&q=object+oriented+programming&btnG=Googl e+Search> &q=object+oriented+programming&btnG=Google+Search http://en.wikipedia.org/wiki/Object-oriented_programming Robert On 6/2/07, Phil Henshaw < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: Well, for the knowledgeably ignorant among us... what the heck is 'object oriented' programming anyway. All the code looks like code to me, and other than having a few more sub-routines I don't understand the purpose or design of... what's changed other than standardizing a few protocols across platforms? Phil Henshaw ¸¸¸¸.·´ ¯ `·.¸¸¸¸
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
