ruby-****@sourc*****
ruby-****@sourc*****
2012年 9月 27日 (木) 05:30:51 JST
-------------------------
REMOTE_ADDR = 184.145.80.187
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-treev-trees
-------------------------
@@ -601,7 +601,7 @@
{{br}}
{{image_right("composite-ptt-s75-2x.jpg")}}
-In the absence of the Leaf and the Composite objects from the well known GoF blueprint design diagram, seen on the image on the right here, it is hard to conclude our((*Products*))object truly represents the((*Composite Design Pattern.*))However, if you look closely, you will find all the required objects and programming design elements needed in this pattern in our "Products" object. When our Children element contains the((*nil*))we have a((*Leaf*))object, else it is the((*Composite,*))and all together is the((*Component*)) with the abstract operation((*price.*))Those of you new to Ruby should take into account, that abstract classes and operations in Ruby seldom if ever are explicitly defined. This is all part of the strategy called((*duck typing,*))namely, the language does no checking to ensure that an object being passed around have any particular class ancestry. This is known as Ruby dynamic typing (hence, if it quacks like a duck, it must be a duck).
+In the absence of the Leaf and the Composite objects from the well known GoF blueprint design diagram, seen on the image on the right here, it is hard to conclude our((*Products*))object truly represents the((*Composite Design Pattern.*))However, if you look closely, you will find all the required objects and programming design elements needed in this pattern in our "Products" object. When our Children element contains the((*nil*))we have a((*Leaf*))object, else it is the((*Composite,*))and all together is the((*Component*)) with the abstract operation((*price.*))Those of you new to Ruby should take into account, that abstract classes and operations in Ruby seldom if ever are explicitly defined. This is all part of the strategy called((*duck typing,*))namely, the language does no checking to ensure that an object being passed around has any particular class ancestry. This is known as Ruby dynamic typing (hence, if it quacks like a duck, it must be a duck).
The only piece of code that contains any solid evidence we really are dealing with the((*Composite Design Pattern*)) is our customized price getter method. You, know we would like to calculate the complete price for each composite product on all levels; i.e. just as we would like to know what is the price of the entire computer, we also wish to know what is the price for its composite parts such as the Computer Case. This requires that we customize the getter method for the price. So in addition to designing the getter((*price*))method we also need to modify the((*attr_accessor*))methods: