4 ms·

I think the original post is suggesting that your pseudocode should look something like: videoPlayer.play("myvideo.mpg") videoPlayer.limitVolume(50) I have t

I think the original post is suggesting that your pseudocode should look something like: videoPlayer.play("myvideo.mpg") videoPlayer.limitVolume(50) I have to admit, in this kind of example, his argument is interesting.

ardit33 18y ago
ok, good point :) So, basically limitVolume is used to push the implementation of the that scenario up the food chain, to the player itself. How about when I want to set the volume exactly 50, depending on certain triggers. What if I have no control on the videoPlayer, (third party), and now I am limited only on the scenarios they thought were ok to implement? I guess, that's the point of the author, to enforce encapsulation, but by limiting the actions to only "verbs", the author is restricing the user of that object to what he thinks he should be doing. Basically, the author is limiting my ability to do things the author didn't thought I needed. It is like pushing implementation up, and, limiting what users can do. It will probably be a system with less bugs, but also a cripled one.
- jimbokun 18y ago
  "I guess, that's the point of the author, to enforce encapsulation, but by limiting the actions to only "verbs", the author is restricing the user of that object to what he thinks he should be doing." Yes, this is definitely one of the tenants of (at least some definitions of) Object Oriented programming. Arguments for this include giving an object the ability to ensure some kind of contract is maintained, which becomes impossible if you can arbitrarily change certain values without making sure that other values are also updated appropriately. Making data private and making all changes only through public methods makes it possible to guarantee that data inside the object remains in a consistent state. You may not find this a convincing argument, but it is a widely accepted part of OO methodology.
DougBTX 18y ago
Pesumably you might want to know what the current limit is too: videoPlayer.play(file) videoPlayer.setVolumeLimit(number) videoPlayer.getVolumeLimit() videoPlayer.setVolume(number) videoPlayer.getVolume() Hmm...
- demallien 18y ago
  Lol. Yeah, I thought about that too. :-) Although to be fair, you don't need the second pair of accessors now That said, I can only think of one use case for wanting to know what the current limit is - so that I can restore it when I'm finished. So maybe the API needs to look like this: vp.limitVolume() vp.saveLimit(self) vp.restoreLimit(self) Anyway, I'm not disagreeing with you really. At the end of the day I think that accessors are necessary and even desirable (see my other post about MVC). Technologies such as Cocoa bindings can massively reduce the amount that needs to be written by using accessors.

ardit33 18y ago

ok, good point :) So, basically limitVolume is used to push the implementation of the that scenario up the food chain, to the player itself. How about when I want to set the volume exactly 50, depending on certain triggers. What if I have no control on the videoPlayer, (third party), and now I am limited only on the scenarios they thought were ok to implement? I guess, that's the point of the author, to enforce encapsulation, but by limiting the actions to only "verbs", the author is restricing the user of that object to what he thinks he should be doing. Basically, the author is limiting my ability to do things the author didn't thought I needed. It is like pushing implementation up, and, limiting what users can do. It will probably be a system with less bugs, but also a cripled one.

jimbokun 18y ago
"I guess, that's the point of the author, to enforce encapsulation, but by limiting the actions to only "verbs", the author is restricing the user of that object to what he thinks he should be doing." Yes, this is definitely one of the tenants of (at least some definitions of) Object Oriented programming. Arguments for this include giving an object the ability to ensure some kind of contract is maintained, which becomes impossible if you can arbitrarily change certain values without making sure that other values are also updated appropriately. Making data private and making all changes only through public methods makes it possible to guarantee that data inside the object remains in a consistent state. You may not find this a convincing argument, but it is a widely accepted part of OO methodology.

DougBTX 18y ago

Pesumably you might want to know what the current limit is too: videoPlayer.play(file) videoPlayer.setVolumeLimit(number) videoPlayer.getVolumeLimit() videoPlayer.setVolume(number) videoPlayer.getVolume() Hmm...

demallien 18y ago
Lol. Yeah, I thought about that too. :-) Although to be fair, you don't need the second pair of accessors now That said, I can only think of one use case for wanting to know what the current limit is - so that I can restore it when I'm finished. So maybe the API needs to look like this: vp.limitVolume() vp.saveLimit(self) vp.restoreLimit(self) Anyway, I'm not disagreeing with you really. At the end of the day I think that accessors are necessary and even desirable (see my other post about MVC). Technologies such as Cocoa bindings can massively reduce the amount that needs to be written by using accessors.