Before I begin, a disclaimer: there is a special kind of object-oriented programming based on a concept called delegation instead of inheritance, but for Rad's benefit I'm pretending that doesn't exist, because what he's reading doesn't address that yet either. But I'm sure Rad will look at Javascript one day and then we can look at that.
First things first: a textbook author who writes that Object-Oriented programming
[is] the most powerful programming model yet devisedis hard to take seriously, because it's arrant nonsense. OOP is certainly very popular (and set to remain so by being the only model taught in most universities), and also very useful, given that a great deal of software is written to model real-world things, which is what object-orientation is essentially about, and why object-oriented programming is in fact pretty easy to learn.
However, in terms of expressive power it cannot be compared to the functional languages, which both derive and ultimately pay for their immense versatility and precise expression because their core concepts don't match to simple real-world reasoning by analogy. OOP works by making it easy to create program structures which are direct analogues of real-world things, and indeed it's generally presented that way. However, reasoning by analogy is also horribly imprecise, so while OOP is comparatively "easy to learn" because it's about drawing simple analogies, that learning process is in fact pretty hit-and-miss because people can and usually do draw incorrect inferences from analogies.
This is why rigorous teaching programs start with something like Scheme; it's small, and about as simple as a functional-type language can be, but it's very precisely specified - so when you learn it, you don't end up with misconceptions that have to later be unlearned - and it's built on concepts that are universally applicable.
Most college programs use Java precisely because it's object-oriented, and thus its' entire logic can be demonstrated by analogy, which by "happy" coincidence is the mode of reasoning it's suited to address. Since making analogies is very simple, people get a big sense of power very quickly, even though what they are learning is very imprecise and that imprecision can lead people quite far astray.
The main thing about object-oriented programming is that it's got things (i.e., nouns) and actions (i.e., verbs), but in OOP it is the nouns that are in charge all the time. Verbs are applied to nouns, and have no meaning by themselves.
Things, just like nouns, come in several forms; there are nouns which describe categories of things (for example, "cats"), and nouns which describe particular actual things (for example, "my car").
All the world of nouns in OOP can be dealt with by one of a type of categorical statement, of these forms:
- An X is a kind of Y, e.g. a Cow is a kind of Animal.
- An X is a Y, e.g. Bessie is a Cow.
- An X has a Y called Z, e.g. a Cow has a Tail called "the tail".
Classes are where we make statements of the first kind, to start to describe a category by asserting what it is kind of like (or analogous to), which we can then elaborate by describing it in more detail using the third kind of statement, where we can describe the attributes of the thing. And lastly, almost as an afterthought, we can tack on verbs:
- An X can do a verb, e.g. a Cow can Moo.
Congratulations! That's basically the entire conceptual foundation of OOP, and if you are happy expressing everything like this (i.e., talking like a child with a picture book) then you could well have a promising career as an Enterprise Java Developer in front of you.
So, to address Rad's (implied) questions:
In PHP, characteristics are called FIELDS, and behaviors are called METHODS (.. F&M). Okay, methods I can see, but not sure why they chose the term 'fields'.Actually, they aren't called fields. The term used by convention in most programming language is "properties", and a trick to remember this is by recalling it's all about saying has a. If you have something you own it, therefore it's your property.
The term "field" isn't used in much programming language literature (and isn't used that way in PHP either), because it comes from a specific application area: filling in forms, which is of course a lot of what very simple programming is about. A field is an area in a form you can fill out; basically, calling a "property" a "field" is something you might do if the code you were writing was nothing more than conveying form fields.
So, it's a terminology thing which you'll only encounter in the context of PHP which is oriented around HTML, and thus where simple applications receives most of its data via forms. The other place the term "field" used to be common was in COBOL applications (which similarly was almost exclusively about processing forms) where it was actually used in the language: data in COBOL was organized into structures called records and the elements of a record were called fields. Later on, SQL standardized the terminology for the quite versatile (not just for forms) representation of data it supported to "rows" and "columns" although few languages incorporated SQL directly into themselves so there were separate names for persistent data in a database on disk and data which is "live" in memory in a program.
Most of the rest of the things such as abstraction and modularity as they exist in OOP aren't actually fundamental. Rather, they are best considered as consequences of the noun focus. If you're restricted to describing nouns in the prescribed way, using only the simple kinds of statements you're allowed, then modularity is enforced by fiat. Similarly, abstraction is a consequence of the fact that verbs can be attached to objects which have more specialised "kinds of" described later.
Modularity and abstraction are just as important in other kinds of programming language, but they arise in different ways because the other kinds of language have a different way of composing things which aren't just about noun verb. So by all means treat them as virtues, but bear in mind that they aren't particularly unique to OOP at all.
By the way, the whole noun-verb obsession is brilliantly lampooned by Steve Yegge in Execution in the Kingdom of Nouns which shows how awkward and stilted it becomes trying to reason using only sentences at the level of grammatical complexity of "See Spot Run", which is actually the goal of much OOP programming.
No comments:
Post a Comment