P-Patterns!
From Andrey
| Revision as of 19:57, 21 October 2011 Andrey (Talk | contribs) Smart Button ← Previous diff |
Revision as of 20:12, 21 October 2011 Andrey (Talk | contribs) Postponed Validation Next diff → |
||
| Line 27: | Line 27: | ||
| == Postponed Validation == | == Postponed Validation == | ||
| - | Postponing validation until checkpoint/commit so that validations do not hinder performance. | + | Postpone object validation until checkpoint/commit so that validations do not hinder system performance. |
| - | Pascal example. | + | Example: say you have a setProperty() method which changes the value of an object field. You can validate the method arguments right in the the body of the method; but sometimes you also need to do a longer-type validation, e.g. if your object is a compount object. These validations may be sometimes taxing in processing-intensive scenarios, so what you can do instead is move some validations to the time of a commit, and if any validation breaks, rollback transaction. This lets you maintain data integrity without sacrificing high performance. |
| == Detached Validation == | == 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. | 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 20:12, 21 October 2011
Some stuff that I came up with.
Contents |
Object Role
Object role vs. Object class
Golden Bridge
Utilizing the Bridge design 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 DVD 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 for a conventional one. With a several buttons, I had a complete control and 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
Postpone object validation until checkpoint/commit so that validations do not hinder system performance.
Example: say you have a setProperty() method which changes the value of an object field. You can validate the method arguments right in the the body of the method; but sometimes you also need to do a longer-type validation, e.g. if your object is a compount object. These validations may be sometimes taxing in processing-intensive scenarios, so what you can do instead is move some validations to the time of a commit, and if any validation breaks, rollback transaction. This lets you maintain data integrity without sacrificing high performance.
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.
