I posted this to rose forum 30 hours ago - it didn't seem to make it there for some reason - reposting...
(responding to Eric) Here's a previous posting on the topic from the dream team, posted rose forum 6 Feb 2002. =============================================== > (Paul) > Personally, I feel that the "Boundary, Control, Entity" distinction > better suits the 'real world' Business Object Model than the > problem model within the computer system. The reason for this > is that in the real world, many of the objects modelled are just > pieces of paper, and paper is notoriously short in behaviour. > As a result, the smart aspects exhibited by these objects are > delegated to human 'controllers' who push the papers round > in the right way. Within the computer system, the smart behaviour > is better attached to the objects where it rightly belongs. This > is because the human 'controllers' in the real world can adapt to > new ways of working far faster than the programmed controller > objects within the computer. The way I work would eliminate > almost all 'Controller' objects and instead have 'Smart Entity' > objects. About the only use I have for 'Controller' objects is > to stitch together the relevant 'Smart Entity' objects that are > needed to realise specific Use Case scripts. > > (Huseyin) > This has always been the intention with the Controller Objects. > Even a better name would probably have been a Co-ordinator > Object, or Policy Object. The controller concept is quite easy to > pervert, unfortunately: it can easily become the object that > controls a lot of dumb entity objects that provide nothing but > accessor operations. > > It is definitely worthwhile to start with your Business Objects > (the smart entities) and try to get them to do as much of the > processing as possible. Only when you come across tasks > that appear awkward in any of the BOs should yu move that > functionality up to a Policy Object or a Controller Object. > > If you look a little deeper at the Robustness Analysis approach, > the intention is to initially attach responsibilities to the Controller > Objects, then, as the analysis progresses, move as much of > those as possible to the Entities. This is a neat approach to > bridge the gap between the functional world of use cases and > the responsibility world of objects. It also reduces the size of > the intuitive leaps you need to make to bridge that gap: The > samller the leaps, the less chance of being stuck in analysis > paralysis. Trouble is that it is very easy to do the first stage, > then stop, because the model that you quickly end up with > does fit in quite nicely with the procedural mindset. Avoiding > analysis paralysis with analysis anorexia is not necessarily a > good thing. =============================================== So, let me tie up a few loose ends. Steve Baynes had the right idea in suggesting the key is to get the responsibility in the right place, but needed to follow through a bit further with that argument. The key distinction I make about entity objects, their responsibilities and their behaviour that distinguishes them from controller type objects is that the entity objects have their collection of responsibilities and behaviour no matter how any system that may contain them is used. OTOH, controller objects are tightly coupled to how the system is being used. If the system is well designed, then when the system needs to be used in different ways, the controller objects all need to change, but the entity objects do not. Typically we won't hit this peak of idealism, but you get the picture. So, now the question is, what does the business rule in question represent? Is it a fact about the domain that is independent of how the system is to be used, or is it a fact that is intimately coupled with how the system is to be used? In the former case, the rule belongs with one or more entity objects. In the latter case, the ruler belongs with one or possibly more controller objects. So, I've come off the fence and said, the correct answer is, it depends. Tarkington, come down off that fence, there's folk down here with a virtual thirst... Paul Oldfield ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ www.aptprocess.com any opinions expressed herein are not necessarily those of Mentors of Cally or the Appropriate Process Movement ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
