From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,7f8fc37d854731d6 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public From: rmartin@oma.com (Robert C. Martin) Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/12/03 Message-ID: #1/1 X-Deja-AN: 202094868 references: organization: Object Mentor Inc. newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai Date: 1996-12-03T00:00:00+00:00 List-Id: In article , stt@houdini.camb.inmet.com (Tucker Taft) wrote: > Robert C. Martin (rmartin@oma.com) wrote: > > : This is an architectural choice; and it is based upon which kind of change > : is more likely. If it is more likely that new functions will be added to > : existing modems, then the switch statement is probably the better choice. > : If it is more likely that new kinds of modems will be added, then the class > : structure is probably better. > > This is certainly a good point, but I think that the class structure > still has certain advantages over the "switch" structure even when adding > new "functions" is somewhat more common than adding new modem variants. Building class structures is also my preference; even when new functions are added with relative frequency. I will use 'Visitor' or 'Decorator' to add those functions. However, in the extreme case, when adding new new functions will continue to be the primary means of modifying the software, the switch statement route is probably the better choice. > > In the "switch" world (in which I have spent many pleasant hours ;-), > one tends to presume that almost every new function requires its > own personal switch statement. In the "class" world, when adding > a new operation, one has the option of implementing it in terms of > some preexisting more primitive operation, rather than creating > a new operation for every modem variant. This is a matter of style. There is no reason why primitives cannot be created when using switch statements. That some people tend not to do that is unfortunate, but no different from the fact that some people tend to build classes with no behaviors other than accessors and mutators. I don't want to seem that I am advocating a programming structure based upon procedural principles. Generally I do not support such structures. I ususally try to arrange the structure of the program such that the 'types' vary more frequently than the functions. However, there are times when a procedural architecture is the right choice. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan