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.2 required=5.0 tests=BAYES_00,REPLYTO_WITHOUT_TO_CC, SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,3aad2600dfe8f337 X-Google-Attributes: gid109fba,public X-Google-Thread: 111d6b,3aad2600dfe8f337 X-Google-Attributes: gid111d6b,public X-Google-Thread: fef06,3aad2600dfe8f337 X-Google-Attributes: gidfef06,public X-Google-Thread: 10b276,3aad2600dfe8f337 X-Google-Attributes: gid10b276,public X-Google-Thread: 103376,3aad2600dfe8f337 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,3aad2600dfe8f337 X-Google-Attributes: gid1014db,public X-Google-Thread: f753e,3aad2600dfe8f337 X-Google-Attributes: gidf753e,public X-Google-Thread: 1108a1,3aad2600dfe8f337 X-Google-Attributes: gid1108a1,public From: Michael E. Lee, II Subject: Re: WHERE ARE ALL THE OT EXPERTS??? Date: 1996/07/30 Message-ID: X-Deja-AN: 171100548 sender: Michael E. Lee, II references: <31fa4f6a.1089588215@news.cyberport.com> organization: Agincourt Engineering reply-to: mlee@primenet.com x-posted-by: ip142.phx.primenet.com newsgroups: comp.object,comp.object.corba,comp.object.logic,comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.c++.leda,comp.lang.java.misc,comp.lang.javascript,comp.lang.objective-c,comp.lang.smalltalk,comp.programming,comp.lang.java Date: 1996-07-30T00:00:00+00:00 List-Id: > >>trivial as to be completely useless, and (2) it's *worse* than useless > >>because it's a completely action-centered approach. Urgh. > > > >2) Define "action-centered" in this context. I don't understand what > > you're trying to tell me. What is the alternative ("passive-centered" :-)? > > > A book I recently read points out that most people who use > action-oriented design when using an O-O language tend to have roots > in procedural programming. I don't know anything about CRC cards, but > if it is action-oriented, it wouldn't surprise me that managers tend > to like them. Most of these managers were probably promoted out of > the programming ranks while they were still using a procedural > language. Unfortunately, the different duties of a manager tend to > separate them from the current technical happenings, so they're not as > up-to-date as when they were programming. Knowing the inherent risk of jumping into a thread mid-stream, here goes... The whole notion of CRC revolves around a single basic understanding: things (people, organizations, objects, systems, etc.) work together to accomplish tasks (business processes, workflows, Use Cases, methods, etc.). Granted, Responsibility-Based Design (RBD) focuses on behavior, but it is _always_ the behavior of things. Never, never, is this behavior "stand-alone" or strictly functional in nature. The hard-time RBD has been getting is very much related to our perception of "analysis" and "design". RBD splits-hairs in this area. >From one perspective, RBD deals with the external reference of objects - i.e. what are they and what do they do? From another perspective it deals with the internal nature of the behavior - i.e. how are things accomplished. It is this internal view that defines the collaborations. > Action-centered design is usually associated with procedural > programming, because it encourages this approach. Basically, it > centers on the actions of the user, with each of the user's paths > modeled in the software. Object-oriented programming can capture this > sort of model, too, but doing so doesn't take advantage of the > paradigm. For one thing, it tends to destroy reusability, because it > ties the design to one specific domain. So, action-oriented design is > to OOP what unstructured design was to procedural programming. Horse s---!!!!! Where do I start? Leaving aside the red-hearing of "action-centered", let's switch our focus back to Responsibility-Based Design (which CRC is a short-hand mechanism). First, one doesn't have to fit in a CRC model into an OO paradigm anymore than one would have to fit a Fusion, Booch, OMT, or Use Case model into the OO paradigm. RDB _is_ OO! Period. Second, how does RBD destroy reusability? How does it tie one to a specific domain? There seems to be a misunderstanding that RBD is strictly de-compositional in nature. It's not. Granted, identifying and establishing collaborations may force us to "de-compose" a Responsibility's behavior, but this does not mean that we have to identify, define, and build the servicing objects from scratch! In may circumstances, the process is one of synthesis rather than decomposition. We have an existing set of objects (many, if not all, of which can be domian-independent) which supply a set of services (which themselves can be modelled using RBD - if so desired). We then build higher-level methods, tasks, workflows, or processes from these objects (we could also derive new objects from the existing ones, and synthesize from these). Finally, I come full circle. Objects and their behavior do not stand-alone. An object is useless unless it interacts with its environment. RBD allows us to define these interactions - in the same model we define the objects. And RBD is not the only way. The popularity of Use Cases is another example of our hunger to put objects into an overall perspective. (Altough one can view Use Cases as Responsibilities of the systme being analyzed, and the Actors as objects establishing collaborations with the system Responsibilities). +---------------------------------------------------------------------- - Michael E. Lee, II mlee@primenet.com Agincourt Engineering