This content has been marked as final. Show 12 replies
a class is a group of methods (functions) and properties (variables) that do a specific function.
like a tv
it has input via its ariel (cable, stalite whatever)
its buttons and power supply
all its workings are on the inside of the box and you don't need to know about them
its out put is audio (the sound) and visual (the picture)
it doesn't may toast
or wash your dishes
Essential ActionScript 2.0
By Colin Moock
OK so say I have a class called "tv"...any function that pertains to the tv is written within the tv class.
Now I have another class called "dvd", which is its own thing, but I obviously want its functions to effect the tv class. Is that where I start using terms like "extends" or "interface" ?
Thanks for the help.
ok extends is more like this:
class cup extends container
in other words cup inherits everything from container and adds its own (which can overwrite the super class)
interface is more like a class template
if you want classes interact, you would either use data bindings or create event listners and write control code (external to the classes) that 'binds' them together
>>(external to the classes)
Not neccesarily. Basically, the base class - tv - should provide the basic functionality: the screen. Extend it with a remote control or a dvd player. Then you can write a 'wrapper' class - homecinema - that controls how the classes interact. For example by using the EventDispatcher class or by implementing a design pattern like the Delegation Event Model. And... there is no rule that you have to use inheritance. You can also use seperate classes. It all depends on the job and your own preferences.
An interface is used to force classes to have the methods the interface describes.
I actually like the idea of the wrapper class, that looks like it will work with my concept I have now.
Thanks for the help.
as you say the right tool for the job
I don't tend to use wrapper classes, as I general am creating applications that are constantly changing their functionality and user interfaces.
Wrapper Classes I find are too perminant
external control code allows me a more fluid and rapid development.
Not to get too OOPish, but Remote or DVD wouldn't extend TV. Remote would more than likely be an interface and DVDs (as well as DVDPlayer) would be separate objects. DVDs might implement a Media interface, but they themselves are actual objects. They might even extend from class PlasticDooDad, if you're feeling really ornery.
class TV implements RemoteReceiver
// Functions inherited from RemoteReceiver interface:
// Original functions:
} // ends class TV
"InputSource" might be an interface that Antenna, Satellite, DVDPlayer, and Karaoke all implement. In this manner, you could tell your TV to change inputs to the dvd player with the statement:
or to channel 7 from the antenna feed with these statements:
Home entertainment systems are a pretty good example for OOP since the backs of them have clearly labelled inputs and outputs. The output from your VCR has to go to the input of your TV. Plug it in anywhere else and all you get is snow.
>Plug it in anywhere else and all you get is snow.
or a very nasty shock ;-}
>>but Remote or DVD wouldn't extend TV
Possible if that is what you want/need. But, there is no law on how to tackle a specific job. There would be several feasible setups.
>>Functions inherited from RemoteReceiver interface
That's not possible. An interface can inherit from another interface. Classes that implement the interface agree to provide the methods that are described in the interface but they do not inherit the methods.
Unless your remote has a little LCD in it, it wouldn't be subclassing TV.
As for the interface implementation, notice that I put the function abstracts in the TV class. The RemoteReceiver interface declared them, and the TV class inherited the abstracts, and needs to give them definitions. What's so hard about understanding that?
>>What's so hard about understanding that?
Very hard. But let's say I have a pea for a brain.