perlmeditation petdance On Saturday, June 23rd, [http://www.conway.org|Damian Conway] had a little free-for-all workshop that he gave at College of DuPage in Wheaton, IL. Although [91105|the whole day was fascinating], the most useful part for me was his discussion of ``Ten criteria for knowing when to use object-oriented design''. Apparently, Damian was once a member of Spinal Tap, because his list goes to eleven. Damian said that this list, in expanded form, is going to be part of the standard Perl distribution soon. <OL> <LI>Design is large, or is likely to become large <LI>When data is aggregated into obvious structures, especially if there's a lot of data in each aggregate For instance, an IP address is not a good candidate: There's only 4 bytes of information related to an IP address. An immigrant going through customs has a lot of data related to him, such as name, country of origin, luggage carried, destination, etc. <LI>When types of data form a natural hierarchy that lets us use inheritance. Inheritance is one of the most powerful feature of OO, and the ability to use it is a flag. <LI>When operations on data varies on data type GIFs and JPGs might have their cropping done differently, even though they're both graphics. <LI>When it's likely you'll have to add data types later OO gives you the room to expand in the future. <LI>When interactions between data is best shown by operators Some relations are best shown by using operators, which can be overloaded. <LI>When implementation of components is likely to change, especially in the same program <LI>When the system design is already object-oriented <LI>When huge numbers of clients use your code If your code will be distributed to others who will use it, a standard interface will make maintenence and safety easier. <LI>When you have a piece of data on which many different operations are applied Graphics images, for instance, might be blurred, cropped, rotated, and adjusted. <LI>When the kinds of operations have standard names (check, process, etc) Objects allow you to have a <CODE>DB::check</CODE>, <CODE>ISBN::check</CODE>, <CODE>Shape::check</CODE>, etc without having conflicts between the types of check. </OL>