headers
Gabriel Marquez | 3 Nov 2006 20:54
Picon
Favicon

wish to join group

am cs major working with refactorings and would like to join group

 
---------------------------------
Cheap Talk? Check out Yahoo! Messenger's low  PC-to-Phone call rates.

[Non-text portions of this message have been removed]

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:refactoring-digest <at> yahoogroups.com 
    mailto:refactoring-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    refactoring-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
(Continue reading)

Permalink | Reply | 0 comments |
headers
sacona2ld | 3 Nov 2006 22:03

Table-Driven designs versus GOF-centric Design Patterns

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

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:refactoring-digest <at> yahoogroups.com 
    mailto:refactoring-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    refactoring-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tim Dugan | 4 Nov 2006 14:28

RE: Table-Driven designs versus GOF-centric Design Patterns


I don't see why there is a conflict...isn't a table a pattern?

________________________________

From: refactoring <at> yahoogroups.com on behalf of sacona2ld
Sent: Fri 2006-11-03 3:03 PM
To: refactoring <at> yahoogroups.com
Subject: [refactoring] Table-Driven designs versus GOF-centric Design Patterns

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

[Non-text portions of this message have been removed]

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional
(Continue reading)

Permalink | Reply | 5 comments |
headers
Phil Goodwin | 5 Nov 2006 05:58
Picon
Gravatar

Re: Table-Driven designs versus GOF-centric Design Patterns

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.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tim Dugan | 5 Nov 2006 15:36

RE: Table-Driven designs versus GOF-centric Design Patterns


Maybe my terminology is out of date...I thought table-driven design is
something along the lines of having a table that suggests what action to
perform in a given situation-at least, that's what we called it in
college, although that was some time ago...

For example, a state-transition table would have as a key a state plus
an event, and provides back an action and new state.  This puts a lot of
the processing logic in a concise table rather than complex if-else
logic.

Using GOF concepts, the action in the table could be a Command object
(sorry, I don't recall the exact class names).  

In either case, GOF or Table-driven, it still seems like only one aspect
of a larger modeling task...

Tim Dugan, Technical Lead - RTDP/Airline 
PROS Revenue Management
(713)335-7942, tdugan <at> prosrm.com <mailto:tdugan <at> prosrm.com>  

________________________________

From: refactoring <at> yahoogroups.com [mailto:refactoring <at> yahoogroups.com]
On Behalf Of Phil Goodwin
Sent: Saturday, November 04, 2006 10:58 PM
To: refactoring <at> yahoogroups.com
Subject: Re: [refactoring] Table-Driven designs versus GOF-centric
Design Patterns
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Hanson | 5 Nov 2006 17:41

RE: Table-Driven designs versus GOF-centric Design Patterns

The book you want is "Patterns of Enterprise Application Architecture"
by Martin Fowler.  There are *lots* of patterns other than the 24
presented in ght GOF book; Fowler covers a lot of patterns in
excruciating detail, incuding patterns related to tables.

Or am I missing the mark? is Table Driven Design a concept similar to
Test Driven Development?

________________________________

From: refactoring <at> yahoogroups.com [mailto:refactoring <at> yahoogroups.com]
On Behalf Of Tim Dugan
Sent: Saturday, November 04, 2006 7:29 AM
To: refactoring <at> yahoogroups.com
Subject: RE: [refactoring] Table-Driven designs versus GOF-centric
Design Patterns

I don't see why there is a conflict...isn't a table a pattern?

________________________________

From: refactoring <at> yahoogroups.com <mailto:refactoring%40yahoogroups.com>
on behalf of sacona2ld
Sent: Fri 2006-11-03 3:03 PM
To: refactoring <at> yahoogroups.com <mailto:refactoring%40yahoogroups.com> 
Subject: [refactoring] Table-Driven designs versus GOF-centric Design
Patterns

I am learning about 'Refactoring to Patterns' and have Joshua 
Kerievsky's book. A colleague and I are debating the relative merits of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Rutherford | 5 Nov 2006 21:50
Picon

The wrong duplication

Here's something I've seen many times in code right across the spectrum, and
which I caught myself doing just the other day (hence the reason for
un-lurking right now). It seems to occur particularly often in codebases
that weren't TDD'd, and which haven't been kept lean with regular
refactoring...

Imagine a codebase in which one particular text string occurs frequently.
The string may be some kind of message header, for example, or an XML tag
(both of these examples are usually accompanied by another repeated string,
representing the message footer or the closing tag). As the codebase grows,
you notice the string popping up more and more frequently, until the
"duplication" bell goes off. What to do?

It turns out we've all been taught the answer: Create a manifest constant (a
#define or a static final String or whatever, depending on the language),
thereby giving the common string a name, and replace all instances of the
string by use of the manifest. There's even a name for this refactoring in
Martin Fowler's catalogue: Replace Magic Number With Symbolic
Constant<http://refactoring.com/catalog/replaceMagicNumberWithSymbolicConstant.html>.
Duplication sorted, right? Wrong!

The duplication wasn't in the repeated *text* of the string's contents, but
in the repeated *use* of the string. The resulting code still contains the
original duplication. Worse, by hiding the string behind a constant, my
feeling is that we've made the code less readable too.

The right approach - after using Inline Constant to put the original strings
back into the code - is to look at the context in which each of those
strings occurred. Chances are there will be only a small number of
*kinds*of use of the string - perhaps every time a reply message is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keith Ray | 6 Nov 2006 03:50
Picon

Re: The wrong duplication

1. The first time I use a certain string literal, I just use it in
whatever function needs it.

If it needs to be localizable, it's wrapped in a macro and copied to
the localizable.strings file.

2. The second time I need to use that string literal, I make it into a
symbolic constant.

This would be the case if I'm doing TDD and both the test and the
code-under-test need to use the string literal.  So the code may
transition from #1 to #2 very quickly.

3. The third to Nth times that I need to use that string literal, I
look for common code and try to extract that.

On 11/5/06, Kevin Rutherford <kevin <at> rutherford-software.co.uk> wrote:
>
>
>
>
>
>
> Here's something I've seen many times in code right across the spectrum, and
>  which I caught myself doing just the other day (hence the reason for
>  un-lurking right now). It seems to occur particularly often in codebases
>  that weren't TDD'd, and which haven't been kept lean with regular
>  refactoring...
>
>  Imagine a codebase in which one particular text string occurs frequently.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 6 Nov 2006 04:21
Favicon

Re: The wrong duplication

Hello, Kevin.  On Sunday, November 5, 2006, at 3:50:00 PM, you
wrote:

> Duplication isn't about text. It's about knowledge and meaning.

> Does that seem reasonable to you?

Yes, good observations ... I might put it this way:

Duplication isn't [just] about text.
It's [also] about knowledge and meaning.

Ron Jeffries
www.XProgramming.com
What is your dream? And knowing this, what have you 
done to work towards realizing it today? -- Les Brown

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zhiyi Zhang | 6 Nov 2006 03:13
Picon
Favicon

Re: Table-Driven designs versus GOF-centric Design Patterns

Just to add a comment about ER data modeling. In one aspect, it is very 
similar to Domain Driven Design (DDD) in that the data modeler (or yourself) 
constantly asks questions about the concept behind a table or a column and 
how it's related to another table/column. I personally think it's a 
extremely valuable execise as it helps uncover hidden concepts or umbiguous 
concepts.

On the other hand, it's mostly a static view of data and relationship, and 
it requires strong disciplines which most developers don't have. In 
addition, it doesn't tell you anything about your object-oriented code. DDD, 
on the other hand, can be naturally mapped into your working code.

- z
P.S. I'm not a big fan of design patterns, especially GOF. I think if we 
understand enough the problems and what we try to achieve, the solution will 
come out natually. Starting from patterns often leads us to forget the 
original problems.

>From: "Phil Goodwin" <phil.goodwin <at> gmail.com>
>Reply-To: refactoring <at> yahoogroups.com
>To: refactoring <at> yahoogroups.com
>Subject: Re: [refactoring] Table-Driven designs versus GOF-centric Design 
>Patterns
>Date: Sat, 4 Nov 2006 20:58:19 -0800
>
>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
(Continue reading)

Permalink | Reply | 2 comments |

Gmane