P-Patterns!
From Andrey
| Revision as of 07:15, 7 February 2006 Andrey (Talk | contribs) Smart Button ← Previous diff |
Revision as of 07:16, 7 February 2006 Andrey (Talk | contribs) Smart Button Next diff → |
||
| Line 21: | Line 21: | ||
| This is my case for exposing an object in interface. I know that there is opposition for doing so, and even a law ([http://www.ccs.neu.edu/home/lieber/LoD.html Law of Demeter]). However, I dare to say that exposure of an object of a generic, well-known class in interface provides for simpler, more intuitive designs that hiding everything under monolite interface facade with numerous methods. If a laundry list of class's methods reads like that fine printed command reference of my DVD player, I would like to take it back to the store. | This is my case for exposing an object in interface. I know that there is opposition for doing so, and even a law ([http://www.ccs.neu.edu/home/lieber/LoD.html Law of Demeter]). However, I dare to say that exposure of an object of a generic, well-known class in interface provides for simpler, more intuitive designs that hiding everything under monolite interface facade with numerous methods. If a laundry list of class's methods reads like that fine printed command reference of my DVD player, I would like to take it back to the store. | ||
| - | I'm not entirely opposed to the Law of Demeter, however I always felt that it stems from the assumption that exposing class can not control actions performed on an exposed object. While it is true in current OO languages, there may be designs and approaches that provide for such control ([[Overriding_in_Owner_Class |Example]]). In the presence of such mechanisms, advantages of obeing the Law of Demeter somewhat diminish. | + | I'm not entirely opposed to the Law of Demeter, however I always felt that it stems from the assumption that exposing a class can not control actions performed on an exposed object. While it is true in current OO languages, there may be designs and approaches that provide for such control ([[Overriding_in_Owner_Class |Example]]). In the presence of such mechanisms, advantages of obeing the Law of Demeter somewhat diminish. |
| I'm also not entirely for always trying to export an object in interface. For example, in the case of DVD player it makes sense to export some (buttons, light indicators) while keeping other under the hood (transformers, electric motors, microprocessors). Therefore, more precisly, we want to export some wery general objects (button controls, status strings), while keeping other encapsulated. | I'm also not entirely for always trying to export an object in interface. For example, in the case of DVD player it makes sense to export some (buttons, light indicators) while keeping other under the hood (transformers, electric motors, microprocessors). Therefore, more precisly, we want to export some wery general objects (button controls, status strings), while keeping other encapsulated. | ||
Revision as of 07:16, 7 February 2006
Some stuff that I came up with.
Contents |
Object Role
Object role vs. Object class
Golden Bridge
Utilizing the Bridge pattern in order to separate model from application-specific behaviors.
X class
Divide model classes into pure and application-specific classes, in the model, use only pure classes, but in application, instantiate only application-specific classes.
Smart Button
I bought a DVD player which was a black box with a tiny hole of a microphone. It did an amazing thing of being able to hear voice commands and execute them. For example, to open drive bay I would say 'Open drive'. To make a pause, I would say 'Do pause' and so on. I like it in the beginning but there was one thing. I had to always consult with a manual because I kept forgetting commands. For example, I would say 'Make pause' instead of 'Do pause', and it wouldn't do anything, because it wouldn't understand. Finally, I started missing my old DCD player. It had buttons as an interface. In order to turn it on, I didn't have to recall a command, but simply knew to press the Power button. In the end, I took the DVD player back to store and exchanged it to a conventional one. With a several buttons, I had complete control and no need to keep a page with commands printout in a condensed typeface, wrapped in a transluscent sleeve.
Expose a generic object in the interface in order to simplify class use.
This is my case for exposing an object in interface. I know that there is opposition for doing so, and even a law (Law of Demeter). However, I dare to say that exposure of an object of a generic, well-known class in interface provides for simpler, more intuitive designs that hiding everything under monolite interface facade with numerous methods. If a laundry list of class's methods reads like that fine printed command reference of my DVD player, I would like to take it back to the store.
I'm not entirely opposed to the Law of Demeter, however I always felt that it stems from the assumption that exposing a class can not control actions performed on an exposed object. While it is true in current OO languages, there may be designs and approaches that provide for such control (Example). In the presence of such mechanisms, advantages of obeing the Law of Demeter somewhat diminish.
I'm also not entirely for always trying to export an object in interface. For example, in the case of DVD player it makes sense to export some (buttons, light indicators) while keeping other under the hood (transformers, electric motors, microprocessors). Therefore, more precisly, we want to export some wery general objects (button controls, status strings), while keeping other encapsulated.
Postponed Validation
Postponing validation until checkpoint/commit so that validations do not hinder performance.
Pascal example.
