| Ian Cooper 的个人资料Staccato Signals日志列表 |  工具  帮助 |
|
5月22日 The problem with archetype patterns and MDAI'm reading Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and MDA. I picked this up partially because one of the databases at my current gig has been heavily influenced by some of the ideas here - especially the party archetype. First, I want to be positive: if you are looking for a discussion around some of the problems you will hit when designing a solution to representing contacts, products,orders, rules etc. then as analysis patterns some useful learning has been captured here. As an example, the discussion on how to build products that support the open-closed principle (OCP) and are open for extension and closed for modification is useful and captures valuable knowledge. To be fair to the authors they do note that you can use the book as just that. However the book pitches itself as differing from Fowler's Analysis Patterns in that it suggests that the archetypes it provides are not just patterns, but templates for tooling to generate code, specifically: "Is sufficiently detailed to feed into the Model Driven Architecture (MDA) development workflow as a platform-independent model (PIM)". The archetype patterns, that are intended as suitable sources for generation, are necessarily defined in terms of state, not in behaviours, because the behaviour will differ from application to application. Indeed the book says: "As a general rule, Parties have no interesting behavior—they simply hold information. This is an important point to grasp because it makes the Party reusable across many different business domains. If you were to add significant amounts of behavior to the Party,
or to any of its subclasses, this behavior might be appropriate for
some domains but not for others. Your best strategy, therefore, is to
treat the different types of Party mostly as passive data stores and to allow other things to act upon them." Whoa there! Surely the authors recognize the smell here - this is structured programming not Object-Oriented programming. We are talking about seperation of state and behaviour. This seems to be a problem for archetype patterns - state and behaviour need to be seperated to create a generic template that we can use to stamp new instances out for new domains, because behaviour is unknown to the archetype author. The difficulty of extracting a design from one domain and using it in another is a big one. Successful re-use seems to be where the domain remains the same. It seems to be very hard, perhaps impossible, to write clean code that is reusable when you decide to shift domains. The authors do note this objection: "Sometimes a specific model of something, such as a model of products, may be suitable for use in one business area but not in another. This is what we refer to as the principle of variation: different business domains often seem to require different models of the same thing. This principle just seems to be a fact of life. Often there is no way around it even if you choose to make some modeling compromises. Because of variation, the construction of generic, highly reusable object models, such as enterprise object models, has proven to be rather difficult. You may even have heard some pundits say that such activities have failed and are, in principle, impossible." I do not support the author's contention that simply seperating state from behaviour is an adequate solution to the problem; sure, you can shift the archetype between domains now - but only because it no longer does anything useful. Any code that you add to work with the passive data structure will not be 'clean' OO code. So we have sacrificed design for the ability to create a PIM usable with code generation. But how much work has that actually saved us when our requirement is likely demand behaviour as well as state. In addition when we do not design our software through its behaviour we may end up with inappropriate data structures for our actual behaviours. Adding the behaviour to a generated artefact increases the likelihood that we will have speculative generality or over-complexity in our code derived from other domains that the model needs to support. The authors do express that the archetype can be morphed to the requirements of the domain for generation, but what drives those requirements if its not expression of that behaviour in the first place. While I tend to think that Behaviour Driven Development is really just a 'best practice' for Test Driven Development, their focus on behaviour does highlight that good OO design is about behaviour not about state. 评论 (3)
引用通告此日志的引用通告 URL 是： http://iancooper.spaces.live.com/blog/cns!844BD2811F9ABE9C!382.trak 引用此项的网络日志
|
|
|
