Dominoes

chaoticset on 2002-01-31T23:55:17

"Let's see...expert system stuff."

...these can be accessed as objects, returning...

"Oh, right. I was going to check that out anyway..."

Every time I try to use something, I'm told it's OO. I need to understand this, but to understand it I must do it.

"Well, let's look for an OOP tutorial in Perl."

And after many minutes of looking at one, I decided that Perl isn't a language one should learn OOP in...but many will attest you shouldn't learn it in C++ or Java.

I may just go try Ruby out and see if I can learn OOP while I learn Ruby. I understand the basics -- I believe -- but if I don't play around with it, I'll never really grok it.

---

Basic OOP

chromatic on 2002-02-01T02:46:15

Using objects is easy, if you know the secret: you're just telling something what to do. Think of it like sending a message. You want to tell me to go home? $chromatic->go('home');

Programming objects is a little more difficult, but if you read perlboot and perltoot, you'll have the basics.

OOP

TorgoX on 2002-02-01T05:07:43

I really didn't find perlboot and perltoot all that useful, back when I was trying to learn thins stuff. So I went to the university library and looked at all the books about OOP. That was astonishingly unproductive. However, in some book (I think it was Adele Goldberg (an autodidact herself!) and Kenneth Rubin's Succeeding with Objects ) there happened to be a two or three page synopsis of basically what object-orientation means. And that explained it all to me. It's nice to occasionally find a speck of clarity and good writing in comp sci, or any of the technical fields really.

I later wrote a TPJ article called "User's View of Object-Oriented Modules" which you might find helpful to get part of the picture on OOP. It's now available in CPAN as HTML::Tree::AboutObjects

The short story on OOP is this: it's about modeling things in terms of data structures whose insides you never touch directly, except with routines called methods. So you have a data structure ("object") that stands for the amortization table for a loan, or a node in a tree, or whatever, and everything you do with that, you do only with the documented routines ("methods"). You can write routines of your own to manipulate the objects, but they in turn use the documented methods.

Everything else about OOP -- inheritance, accessors, class data, the concept of "polymorphism", and even each particular language's syntax for method calls -- just derives incidentally from the basic concepts.

Practice, practice, practice, keep things simple, try things different ways, and read Damian's book.

Elemental

chaoticset on 2002-02-01T10:23:45

See, I think I understand the basic concept: Data structure(s) and ways to deal with said data structure(s) shrink-wrapped together in kind of an inseparable package. Said package can be duplicated, duplicated with frills, duplicated without certain things, duplicated just for the sake of having another one, etc.

The trick now is fiddling around and seeing where my mental model of OO is somehow wrong, then playing around with it and some OO code until it's fixed.