General talk about software patterns

["Juergen Aschenbrenner" <jasche AT gmx.ch>]

Hi Jan,

for the last couple of years I have been programming the middle tier both
.net and j2ee. According to various blueprints adopted by major vendors we
(me and my co-architecting co-workers) layered the middle tier in a business
process - and a domain object layer.

Depending on the layer a differed set of pattern proved to be useful:

The overall pattern in the business process layer is Strategy. That is there
is no such thing as a final business process. Business processes are prone
to continuos change because off various reasons and as a developer you just
have to keep up. In order to avoid that a reengineered process doesn’t
integrate, the last approved strategy/process must be kept in production as
a fall back option. Or because the same business in different setting is run
in a slightly modified manner.

The business process strategy may be refactored adopting various approaches
and patterns. In case of limited complexity the template method pattern may
provide an abstract high level view on the process that can easily be
discussed with business analysts. More complex operations or algorithms are
deferred to subclasses.

An alternative approach to template method is the chain of responsibility
pattern that factors the process into steps of self contained operations,
what I think is particularly nice as a migration path to webservices and an
service oriented architecture where business processes are orchestrated
graphically. I highly recommend this approach when the business process is
highly integrating in an enterprise landscape and rewriting a process is a
sensitive issue. This would offer a more fine-grained way in reengineering
the process.

Some operations involve a lot of data a relational database is more apt to
handle. Those operations can be wrapped in a command pattern that triggers a
stored procedure. 

For the domain layer the facade pattern provides a set of methods that
change state of the domain object. In a business world domain objects tend
to be whole-part object hierarchies each class in that hierarchy
representing an entity or table in a relational database. That is domain
objects are likely to be implemented applying the composite pattern.

Domain objects before stored in the database are validated applying specific
business rules. The rules must be plugable and easy to code, so one with no
big OO knowledge could do this. One possibility is by means of the
interpreter pattern. However I learned that an organisation which primary
focus is running a business that is not selling software would not be able
to maintain the resulting codebase. A simpler solution is an abstract rule
class that provides default implementations for all classes that make up the
whole-part hierarchy of a domain object. A business analyst is required to
overwrite the methods he wishes to implement.
These rules are notified or called back by an observer when a particular
method in the domain object facade is called. The observer implements also
to Visitors one for downward traversal and one for upward traversal. A
downward traversal for example is needed to verify that the foreign keys in
the child entities are properly set. Upward traversal is needed to assure
that subtotals on the order lines add up to the total on the order. 

The observer who acts in the role of an domain object controller calls a
factory method which takes some attributes of the domain object provided by
the process layer in order to determine the business case. Depending on the
business case different rule sets are loaded and applied to the domain
object. One has to distinguish between different business cases due to
varying legal demands depending in which state, country, planet or universe
the stakeholder wants to expand his business. Taxes on invoices may be one
example: The States for the most part use sales tax, Europe instead VAT and
Quebec a special state tax for what I know.

Hope I could provide an overview on GoF patterns I use and in which context

cheers Juergen


> --- Ursprüngliche Nachricht ---
> Von: "Jan Hannemann" 
> <jan AT cs.ubc.ca>
> An: 
> <patterns-discussion AT cs.uiuc.edu>
> Betreff: [patterns-discussion] Which patterns are more frequently used?
> Datum: Tue, 5 Jul 2005 14:03:17 -0700
> 
> I'm wondering which patterns are actually used more frequently than others
> in practice(*). In particular, I'd like to know which the top-5 (or
> top-10)
> Gang-of-Four patterns(**) are in terms of number of pattern instances
> found
> in practice. I do realize that this is hard to determine objectively, but
> subjective rankings are fine, too.
> 
> For example, I think it is pretty clear that Interpreter is less commonly
> used in practice than, say, Observer. 
> 
> Are there by chance even research papers on this topic available? Or on
> related topics (empirical study of patterns in the wild)?
> 
> Opinions are welcome as well. A few years back I spoke to one of the
> authors
> of the GoF book and he gave me this informal list of what he thought were
> the top-9 according to his experience (most commonly used on top):
> 
> Observer
> Composite
> Singleton
> Abstract Factory
> Visitor
> Adapter
> Factory Method
> Template Method
> Command
> 
> Can you confirm this list, or do you have different experiences with
> patterns used in practice?
> 
> Thanks!
> 
> --Jan
> 
> 
> PS: To provide some context: my research involves design patterns (in
> particular, the GoF patterns) and I want to make sure I focus on patterns
> that are actually used in software development.
> 
> (*)  With "in practice" I mean "in real-word software systems". 
> (**) I'm only interested in the GoF patterns.
> 
> _______________________________________________
> patterns-discussion mailing list
> patterns-discussion AT cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion
> 

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

-- 
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl