Mail-list精选-[refactoring] Table-Driven designs versus GOF-centric Design Patterns

p1：

I am learning about 'Refactoring to Patterns' and have Joshua
Kerievsky's book. A colleague and I are debating the relative merits of
the so-called Table-Driven design approach versus GOF-centric Design
Pattern approach: as a rule, do/should one (or more) GOF patterns
supplant Table Driven designs? If so, how should such a refactoring
proceed? Any thoughts on this are appreciated.

sam

p2：
As I understand it table driven design is about data modeling. There is a
focus on decoupling and at least a nod given to domain modeling so it
shouldn't be completely incompatible with design patterns. However, the GOF
patterns almost all take advantage of polymorphism which will encourage the
use of inheritance and inheritance doesn't mix terribly well with data
modeling so you are probably going to run into run into some conflicts
there. I'm not well-versed in table driven design but the obvious advice
would be to use table driven design for your schema, patterns for the
application code and O/R mapping to connect them. You might want to read
Eric Evans' Domain Driven Design and pay careful attention to what he has to
say about Entity objects. Those are the objects that will generally be
data-heavy and therefore most influenced by a data centric design
discipline. The domain driven approach will also make it more likely that
data and behavior will decompose along similar lines so there will be fewer
conflicts between the different approaches that are being advocated by your
team.

Broadly speaking there are three reasons to refactor: to remove duplication,
to prepare for the addition of new code or to clarify the design. It is
tempting to attempt a large refactoring immediately following a teamwide
shift in design philosophy. I recommend that you resist this temptation and
do the refactoring incrementally as you are writing new code. This approach
will give you an opportunity to learn from the results of one refactoring
session before embarking on the next. It will also keep your refactoring
efforts focused on the code that matters the most -- the code that you are
changing in order to add business value. Finally, in general it's best to
keep code that's concerned with storage or communication more data-centric
and more coarse grained; and business logic, UI and especially API code
behavior centric and abstract.

Phil