[Home]
[Edit this page]
[Recent Changes]
[Special Pages]
[Help]
oopDelphi
You do... and you don't.
You'll be doing the things the OOP way even without fully understanding what you are doing, in those terms. It's a bit like the fact that an 8 year old can ride a bicycle without having a Ph.D in physics.
I won't be offened if others edit the following, but to get you, gentle reader, started...
When you look at putting a program together as follows, you are in fact, in some ways, taking an OOP approach.
Imagine that instead of building a computer program, you were putting together a super hi-fi system for someone. You are an electrical engineer with the inclination and resources to build the whole thing almost from scratch.... I'm not talking about merely buying a few boxes (amp, tuner, speakers) and running wires between them.
For convenience, we're going to put everything (except the speakers) in one box. This is a bit like the "form" a Delphi project is built on. The Form is a container for "the bits".
There will be various switches on the front of the box. They all have things in common, or they wouldn't be called switches, and they come with variations. We'll have a power switch (on/off) and a selector switch (CD / tuner / turntable). We won't make them from scratch, we'll buy them from a supplier. In Delphi, from the component library, we can "buy" "switches"... for example buttons... and "stick" them on the form.
By the way: the Form is an Object. Buttons are Objects. Almost every "thing" is an Object. It's how objects behave that is interesting, and harder to explain or understand... but your understanding WILL gradually grow. Just don't worry about it too much. "Use the force, Luke."
In building the hi-fi system, we have to buy the right bits to stick into it. With OOP, when we collect components from the library they come to us in a malleable form. To go back to the analogy, we'd collect "switch progenitors". By setting the PROPERTIES of the switch-objects we've placed on the form we refine each one (each "instance" of the switch-type thing) and make it into the sort of switch we feel does the best job in that role.
Continuing with the switch analogy: A switch selectively connects things. An OOP object has METHODS. Methods are not unlike the sub-routines you may have used in older programming styles. While the "Connect" method is going, in general, to be about connections, the exact details of what is connected, when, for a given instance of a switch object in a particular program is flexible. It is something that you, the programmer, can determine, can set.
[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
oopDelphi
(Delphi) Object Oriented programming
Do you need to master Object oriented Programming (OOP... an acronym which is in widespread use) to work in Delphi?You do... and you don't.
You'll be doing the things the OOP way even without fully understanding what you are doing, in those terms. It's a bit like the fact that an 8 year old can ride a bicycle without having a Ph.D in physics.
I won't be offened if others edit the following, but to get you, gentle reader, started...
When you look at putting a program together as follows, you are in fact, in some ways, taking an OOP approach.
Imagine that instead of building a computer program, you were putting together a super hi-fi system for someone. You are an electrical engineer with the inclination and resources to build the whole thing almost from scratch.... I'm not talking about merely buying a few boxes (amp, tuner, speakers) and running wires between them.
For convenience, we're going to put everything (except the speakers) in one box. This is a bit like the "form" a Delphi project is built on. The Form is a container for "the bits".
There will be various switches on the front of the box. They all have things in common, or they wouldn't be called switches, and they come with variations. We'll have a power switch (on/off) and a selector switch (CD / tuner / turntable). We won't make them from scratch, we'll buy them from a supplier. In Delphi, from the component library, we can "buy" "switches"... for example buttons... and "stick" them on the form.
By the way: the Form is an Object. Buttons are Objects. Almost every "thing" is an Object. It's how objects behave that is interesting, and harder to explain or understand... but your understanding WILL gradually grow. Just don't worry about it too much. "Use the force, Luke."
In building the hi-fi system, we have to buy the right bits to stick into it. With OOP, when we collect components from the library they come to us in a malleable form. To go back to the analogy, we'd collect "switch progenitors". By setting the PROPERTIES of the switch-objects we've placed on the form we refine each one (each "instance" of the switch-type thing) and make it into the sort of switch we feel does the best job in that role.
Continuing with the switch analogy: A switch selectively connects things. An OOP object has METHODS. Methods are not unlike the sub-routines you may have used in older programming styles. While the "Connect" method is going, in general, to be about connections, the exact details of what is connected, when, for a given instance of a switch object in a particular program is flexible. It is something that you, the programmer, can determine, can set.
==
Apologies for a rather abrupt end here. I hope the above was of some use?[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
