P-Patterns!
From Andrey
Contents |
P-Patterns
Some patterns I came up with.
Smart Button
- Suppose 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 over the thing and trashed that page with fine-print command printout wrapped in a translucent 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 the interface provides for simpler, more intuitive designs that hiding everything under a monolith interface with numerous methods. If the list of class's methods reads like a laundry list, I have an urge to return 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 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.
On the other hand, I'm also not entirely for always exposing an object in class interface. In our example with the DVD player it makes sense to export some objects (like buttons, light indicators) while keeping everything else under the hood (transformers, electric motors, microprocessors). Therefore, more precisely, we want to expose some very general control-like objects (buttons, status strings), while keeping the other parts hidden from the user.
Postponed Validation
Say you have a setProperty() method which changes the value of an object field. You typically validate method arguments right in the body of the method; and sometimes you also need a more extensive validation, e.g. if your object is of a compound type. Such validations may sometimes be taxing on performance in processing-intensive scenarios. Instead, if you perform validations in time of a commit. If a validation rule is broken, rollback the transaction. This lets you maintain data integrity without sacrificing high performance.
Postpone object validation until checkpoint/commit so that validations do not hinder performance.
One way to implement the postponed validation is Detached Validation. You create a flag in your object's class to switch validations on and off, and perform a total validation every time the flag is set on. While in the detached state (i.e. when the flag is off), skip any validations thus improving performance. Enforce that each object is in its normal (validations on) state on a commit/checkpoint.
Object Role
Object role vs. Object class
Static resolution
Hide a class behind a static interface to improve code brevity and clarity.
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.
