On Jul 30, 2006, at 1:30 PM, Joe Huber wrote:
I'm glad you found it interesting. I remember when the Class
Interface light finally went on for me. It was one of those
ephiphany moments.
Most people seem to describe ClassInterfaces as a set of methods,
ie the Verbs by which you tell another class how to work. And while
that's true, the big news for me is that class interfaces are
themselves actually Nouns. You can pass instances of them around,
keep lists of them, etc
Class interfaces are also one of RB's alternatives to Function
Pointers.
Another way of saying all this: A type *is* what a type *can do for
you*. In REALbasic, a type is a collection of public methods/function
signatures and properties. In order to refer to it (eg to Dim a
variable as that type), we give it a name. And because you can fake
up a property as a function and a method, the very *essence* of a
type is a collection of public methods/functions.
That's just what a Class Interface is: the definition of a type.
A class *also* defines a type; but a class does more: it also carries
the implementation of its method/function signatures, it can
participate in inheritance, and it can be any number of types (which
are: its own class; all of its superclasses; and all of its class
interfaces).
Once you have a type, you can use it, without regard to what it
"really" is. For example, you could write, say, a function that
counts words:
Function WordCount(s As TextSource) As Integer
...
End Function
Here, TextSource is a ClassInterface with a method and two functions
on it:
Sub Start
Function Next() As String
Function Done() As Boolean
TextSource is a new type. I can make subclasses of socket, clipboard
and folderItem, put implementations of these on it, add "TextSource"
to their Class Interfaces list, and then hand instances of any of
them to WordCount.
There are two main benefits from doing this sort of thing, which
benefit you more and more as a program gets bigger and more complex:
1. Every part of the program can be written with the fewest
assumptions possible about the other parts. I can add new sources of
text to the theoretical application above without writing much of
anything, other than the new source of text; and
2. The WordCount method above can be as simple as possible, because
it works with a type that has exactly the features that it needs to
do its job. So the WordCount function will be a pure and beautiful
abstraction, uncluttered and easy to understand.
Class Interfaces, in other words, are the very essence of
polymorphism, which is the most important feature in Object Oriented
Programming.
If Classes also do this, why have Class Interfaces at all? Only one
reason: a class can only have one superclass, but any number of Class
Interfaces (the reasons for this are too complex to go into here). If
your program will be simpler if you can treat a ListBox and an
EditField the same (say, as sources of text for WordCount), there is
no way to give them the same class, but you *can* give them the same
Class Interface.
Of course, doing good OOP is more than just understanding this; it's
also knowing how to make best use of it in your program's design. But
Class Interfaces, and therefore Polymorphism (the ability to treat
different things the same) is the essence of OOP. Once you get this,
you're really starting to get on board with OOP.
I'm working on a book on Object Oriented Programming with REALbasic.
Work on it is suspended for the moment, due to other obligations, but
it will probably come out sometime a little later this year. If
you're ready to step up to more advanced REALbasic design, look for it.
Guyren G Howe
guyren-at-relevantlogic.com
http://relevantlogic.com
REALbasic, PHP, Python programming
PostgreSQL, MySQL database design and consulting
Technical writing and training
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
