P-Patterns!
From Andrey
| Revision as of 09:19, 7 February 2006 Andrey (Talk | contribs) Smart Button ← Previous diff |
Revision as of 10:02, 7 February 2006 Andrey (Talk | contribs) Next diff → |
||
| Line 30: | Line 30: | ||
| Pascal example. | Pascal example. | ||
| + | |||
| + | == Detached Validation == | ||
| + | |||
| + | Provide each object with an alternate 'detached' state. In detached state, skip any validations improving performance. Validate object when it changes state from detached to normal (attached). Enforce that each object is in normal (attached) state on commit/checkpoint. | ||
Revision as of 10:02, 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 this DVD player which was a slick black box with a tiny hole of a microphone. It did an amazing job of hearing voice commands and recognizing 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 the product 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 craving for a normal DCD player. The one that would have buttons and a remote control, so to operate it I wouldn't have to recall commands. In the end, I took the DVD player back to store and exchanged it to a conventional one. With a several buttons, I had a complete control and no trashed that page with command printout in a condensed type, 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 the list of class's methods reads like that fine printed command reference of that DVD player, I would like to return it back to store.
I'm not entirely opposed to the Law of Demeter, however I always felt that it stems from the assumption that exposing an object results in loss of control on what actions are performed on the 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, obeying the Law of Demeter may be less critical.
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 parts hidden.
Postponed Validation
Postponing validation until checkpoint/commit so that validations do not hinder performance.
Pascal example.
Detached Validation
Provide each object with an alternate 'detached' state. In detached state, skip any validations improving performance. Validate object when it changes state from detached to normal (attached). Enforce that each object is in normal (attached) state on commit/checkpoint.
