Operation Naming: Delegation of behavior – where common logic is abstracted out to a new class (hierarchy) then call the operation performXxxĬonvention: Where behavior is delegated then the original class will need a reference to the class instance that is performing the implementation – name this attribute xxxBehavior where the delegated class type is XxxBehavior.Ĭoding Convention: When referencing another object, use the most abstract class type possible, prefer an interface to a class. Interface Naming: if an interface does not have abstracted realizations name the class …able otherwise name it …Behavior That is not to say that this pattern does not also have applicability to Ruby. The strategy pattern is vaguely similar to mixins in Ruby – the distinction typifies why I prefer Ruby to Java: in Ruby you just include BehaviorX and you are done. We delegate behavior to other classes to keep our class simple where that behavior may be of use elsewhere potentially or where the behavior is subject to change or evolution. #Using bouml codeThe less we know about another object the better – code on a need-to-know basis – do you need to know that an object is of a specific class or just that it is capable of something? Would it be sufficient to know that it was within the same superclass and so on up until you reach the Object root class? Additionally, does the class need to know how an operation is implemented – does it need to contain the implementation logic?īehaviors of objects may be suitable candidates for their own class even though the instances of such classes are not objects in our real or imagined world. The subtle: Prefer interfaces to classes, and abstract classes to concrete classes.Classes do not have to be nouns or things, sometimes they can qualities or just plain behavior. The obvious: Abstract out common behavior/code – limit duplication.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |