Re: What's OOP?
- From: randyhyde@xxxxxxxxxxxxx
- Date: 25 Apr 2005 10:00:51 -0700
wolfgang kern wrote:
> most readers here know me as the very last HEX-coder anyway,
> so don't wonder my question: what's all about this OOP-stuff?
OOP, in it's rawest form, works under the assumption that each packet
of data (i.e., an "object") carries around not only the data, but the
list of operations (i.e., procedures/functions) that are possible on
that data.
>
> As far I understood it's nothing else than data/code-grouping,
> and where is the difference to my way of seeing this?
In a very low-level sense, you are correct. Objects have a lot to do
with the data and code grouping. In particular, each data object
"carries" around the code that operates on it. Okay, not really, it
does, however, carry around *pointers* to the code that can operate on
it.
>
> As I know where my system got its data:
>
> 00100fb0..bf ;IRQ0 timeout counters
> 00100fb0 ;timeout channel 0
> b4 ; 1
> b8 ; 2
> bc ; 3
>
> 001xxxxx SYSTEM
> 00Fxx VARIAIBLES
> Bx Timeout
> C timeout ch3 (ATA-HD)
>
> and the 'set timout calls' are located at:
>
> 001030b0
> 001030b4
> 001030b8
> 001030bc
>
> 001xxxxx SYSTEM
> 03xxx IRQs
> 0xx IRQ0
> Bx SET timeout
> C channel 3
>
>
> call 001030BC says: SYSTEM.IRQ.0.SET.HD.Timeout.CH3.dw
> 00100FBC means: SYSTEM.VARIABLES.HD.Timeout.dw
>
> So do I use OOP without even recognised it ? :)
No. Now if your data values carried around pointers to the routines
that operate on those data values, you could *start* to make a claim
that you're doing OOP.
Of course, OOP is much more than just indirection. To truly support
object-oriented programming you need to support two facilities:
inheritence and polymorphism and generally you need to support a third,
overloading.
Inheritence means that if you have a data type, then you can create a
new data type by *extending* the old one.
Polymorphism, in a nutshell, means that functions written for the older
data type will operate properly on the new data type and, in fact, the
whole purpose of those pointers to the code (that an object carries
around) is to allow the selection of whatever procedure is appropriate
for the task at hand.
It goes without saying that OOP depends upon strong typing. In OOP
languages, the type checking system provides this. In assemblers that
don't support OOP, it is the programmer's responsibility to handle the
type checking. Keeping this right is a lot of tedious work, which is
why you don't see too many people doing true OOP programming in a
non-OOP language (e.g., most assemblers).
In it's rawest form, the inefficiency associated with OOP is mainly all
those indirect (rather than direct) calls to functions that operate on
data.
In the real world, OOP systems tend to be lower-performing because the
system architects go crazy defining layers and layers of inherited
objects and they wind up calling a procedure, that calls a procedure,
that calls a procedure, that ...., that calls a procedure, that returns
the value of a field in some record. When you get lots of operations
like that, it's really easy to write big and slow programs. Largely,
though, this is a function of the object system's design rather than a
particular strike against OOP (after all, you could do this same thing
in procedural programming code, it's just that most people know
better).
Cheers,
Randy Hyde
.
- Follow-Ups:
- Re: What's OOP?
- From: The_Sage
- Re: What's OOP?
- From: wolfgang kern
- Re: What's OOP?
- References:
- What's OOP?
- From: wolfgang kern
- What's OOP?
- Prev by Date: Re: An Object-Oriented Syntax for x86 Assembly
- Next by Date: Re: An Object-Oriented Syntax for x86 Assembly
- Previous by thread: Re: What's OOP?
- Next by thread: Re: What's OOP?
- Index(es):
Relevant Pages
|
