Simplicity vs 'Accepted' Best Practice

[Shane Mingins]

Hi

Would it be fair to say that one generally 'Accepted' best practice is to
separate a GUI type application into Model-View-Controller so that your
application is easier to change? For example I could be using JSP's to
provide the application Views but then decide to replace it all with Swing.

What I am trying to communicate is that there appears to be certain idioms
to software development that people just use and accept as best practice.

But when I read about XP it talks about doing the simplest thing that works.
It says do not look forward to the things that "may" happen, and I am just
trying to reconcile that with certain accepted best practices.

For example if I am writing a Java application and there is no known need to
provide any view other than via Swing do I care about separating/layering my
application so that I can easily replace it with something else?

If I am using OJB as my Object/Relational Mapping tool and there is no know
need to change that or use another tool for parts of the application, do I
care that code in my model "knows" about OJB?

On one hand I can see how in XP 9/10 times you find that via refactoring
your code wants to evolve its design to many of these accepted design
patterns (and hence best practices), but do you also find that in other
cases the known business need is just not there for it?

Cheers
Shane

--
shanemingins@yahoo.com.clothes

remove clothes before replying

"What are you famous for?" she asked.
"I am simply famous," he replied.

[Info]

I'm pretty new to all of this myself, but I'm getting the impression that many
of these kinds of best practices simply happen when doing test driven
incremental development. Any design that does not facilitate easy change simply
cannot evolve, and it almost goes without saying that the UI should be separate
because otherwise tests would be too hard to write - and when you write the
tests first, code that's hard to test never gets written.

On Thu, 17 Jul 2003 11:01:04 +1200, "Shane Mingins"
<shanemingins@yahoo.com.clothes> wrote:
HiWould it be fair to say that one generally 'Accepted' best practice is toseparate a GUI type application into Model-View-Controller so that yourapplication is easier to change? For example I could be using JSP's toprovide the application Views but then decide to replace it all with Swing.What I am trying to communicate is that there appears to be certain idiomsto software development that people just use and accept as best practice.But when I read about XP it talks about doing the simplest thing that works.It says do not look forward to the things that "may" happen, and I am justtrying to reconcile that with certain accepted best practices.For example if I am writing a Java application and there is no known need toprovide any view other than via Swing do I care about separating/layering myapplication so that I can easily replace it with something else?If I am using OJB as my Object/Relational Mapping tool and there is no knowneed to change that or use another tool for parts of the application, do Icare that code in my model "knows" about OJB?On one hand I can see how in XP 9/10 times you find that via refactoringyour code wants to evolve its design to many of these accepted designpatterns (and hence best practices), but do you also find that in othercases the known business need is just not there for it?CheersShane

[Phlip]

Shane Mingins wrote:
Would it be fair to say that one generally 'Accepted' best practice is to separate a GUI type application into Model-View-Controller so that your application is easier to change? For example I could be using JSP's to provide the application Views but then decide to replace it all with
Swing. What I am trying to communicate is that there appears to be certain idioms to software development that people just use and accept as best practice.

Yes. But MVC, and layering architectures in general, don't need to be among
them.

Things like providing for unimplementable copy constructors in C++ are best
practices one can't test for, or achieve by simplifying the code.
But when I read about XP it talks about doing the simplest thing that
works. It says do not look forward to the things that "may" happen, and I am just trying to reconcile that with certain accepted best practices.

The pattern where every function calls every other function, regardless of
layer, is not simple. It must duplicate lots of calls, states, etc.

If you refactor that duplication together, you get the common situation
where an Observer observes an Event Generator. That's the Observer Design
Pattern. We get it by merging the code that observes events. Then, if you
merge all code that controls into a controller module, the code that
displays into a view module, and the object model into another layer, MVC
pops out.

None of this is speculation; I've done it.
For example if I am writing a Java application and there is no known need
to provide any view other than via Swing do I care about separating/layering
my application so that I can easily replace it with something else?

The layers might still exist even if you don't name them or group their
code.
If I am using OJB as my Object/Relational Mapping tool and there is no
know need to change that or use another tool for parts of the application, do I care that code in my model "knows" about OJB?

I'l pass on that one!
On one hand I can see how in XP 9/10 times you find that via refactoring your code wants to evolve its design to many of these accepted design patterns (and hence best practices), but do you also find that in other cases the known business need is just not there for it?

Your business need is to attend to your own velocity. Do that by refactoring
a little at a time, after each code change. Eventually things will drop to a
rest state from which you can't figure out how to improve them. At that
time, your velocity will remain high, which is good for business.

There's probably a cool pattern or two going on in there; screw it. Don't
even bother to go looking for them.

Oh, also, Joshua K. is writing a book or something called "Refactoring to
Patterns". Looks good.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Code Like Hell]

Suppose you got a great idea for an XSLT-based declarative page flow
controller, that's lightweight and simple, yet not known to anyone
outside your own skull, but it's 1000 times less expensive than
biting off a commercial framework, and provides in 2 files or less
what Struts may or may not provide with 27 files...what do you do?

"Shane Mingins" <shanemingins@yahoo.com.clothes> wrote in message news:<3f15d696$1@news.iconz.co.nz>... Hi Would it be fair to say that one generally 'Accepted' best practice is to separate a GUI type application into Model-View-Controller so that your application is easier to change? For example I could be using JSP's to provide the application Views but then decide to replace it all with Swing. What I am trying to communicate is that there appears to be certain idioms to software development that people just use and accept as best practice. But when I read about XP it talks about doing the simplest thing that works. It says do not look forward to the things that "may" happen, and I am just trying to reconcile that with certain accepted best practices. For example if I am writing a Java application and there is no known need to provide any view other than via Swing do I care about separating/layering my application so that I can easily replace it with something else? If I am using OJB as my Object/Relational Mapping tool and there is no know need to change that or use another tool for parts of the application, do I care that code in my model "knows" about OJB? On one hand I can see how in XP 9/10 times you find that via refactoring your code wants to evolve its design to many of these accepted design patterns (and hence best practices), but do you also find that in other cases the known business need is just not there for it? Cheers Shane

[Uncle Bob (Robert C. Martin)]

"Shane Mingins" <shanemingins@yahoo.com.clothes> might (or might not)
have written this on (or about) Thu, 17 Jul 2003 11:01:04 +1200, :
HiWould it be fair to say that one generally 'Accepted' best practice is toseparate a GUI type application into Model-View-Controller so that yourapplication is easier to change? For example I could be using JSP's toprovide the application Views but then decide to replace it all with Swing.

Yes, this is *a* best practice. It's not *the* best practice. There
are other ways of separating GUIs. MVC is not always the right
choice.

It is almost always better to separate GUIs than to embed them. This
is a best practice. How you do it is more of a judgement call.
What I am trying to communicate is that there appears to be certain idiomsto software development that people just use and accept as best practice.

Most of us find it comforting to have a set of rules that we follow.
On the other hand, a professional always measures the cost of
following the rules vs, the cost of breaking them. Sometimes breaking
the rules is the right thing to do.
But when I read about XP it talks about doing the simplest thing that works.It says do not look forward to the things that "may" happen, and I am justtrying to reconcile that with certain accepted best practices.

Software designs evolve over time. At any given instant we want an
independent reviewer to look at our design and say "It's just right
for the current system requirements". As the requirements change, we
want to migrate the design with the requirements so that the reviewer
continues to say that the design is "just right". (Call this the
"Goldilocks Principle"). If you asked the reviewer if best practices
had been used to build the design, he'd say: "Of course. The design
is just right."

Best practices are applied over time and in context. One does not
leap to use MVC until one really *needs* MVC. One does not assume the
use of the Proxy pattern, one migrates the design *into* using a Proxy
when the Proxy becomes necessary.
For example if I am writing a Java application and there is no known need toprovide any view other than via Swing do I care about separating/layering myapplication so that I can easily replace it with something else?

The first thing you will write is a test. That test must test the GUI
independently of everything else. Thus the GUI already requires
separation. So, even though there is no known need for another GUI,
you'll still separate the GUI just so you can test it, and so you can
test the business rules independently of the GUI.

This does not mean you anticipated the need for separating the GUI,
You simply could not proceed without separating the GUI.

If you consider design option X to be a best practice, but neither
your system nor your tests currently need X, then you should not
implement X. Wait until X is needed, and *then* implement it.

This generates two different fears. The first fear is that the cost
of implementing X now is smaller than the cost of implementing X
later. Since we know we will need X later, we're wasting money by not
implementing it now. Call this "Anticipatory Design".

The other fear is that the cost of implementing X won't be recovered
until later. Moreover X will have to be maintained even though it's
not being used. Thus it's wasting money to implement X now. We
should wait until X is needed, and then we'll recoup the cost. Call
this "Agile Design".

The debate between these two options has not been decided. Developers
will just have to follow their conscience. I usually put more
emphasis on "Agile Design", but there are times when I will use
"Anticipatory Design". It's a judgement call.If I am using OJB as my Object/Relational Mapping tool and there is no knowneed to change that or use another tool for parts of the application, do Icare that code in my model "knows" about OJB?

Can you write tests of the business rules that are independent of OJB?
On one hand I can see how in XP 9/10 times you find that via refactoringyour code wants to evolve its design to many of these accepted designpatterns (and hence best practices), but do you also find that in othercases the known business need is just not there for it?

Yes.


Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Ron Jeffries]

On Sat, 2 Aug 2003 00:57:07 -0400, "Guillermo Schwarz"
<guillermo_schwarz@hotmail.com> wrote:
"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b@objectmentor.com> escribióen el mensaje news:1eudhvs8mbkpge3iocrhquhu29ttp6lbrs@4ax.com... Best practices are applied over time and in context. One does not leap to use MVC until one really *needs* MVC.Tell that to a bunch of VB programmers. If they feel like they *need* MVCprobably it is already way too late.

Does the smallest program imaginable already need MVC? I would not think so. So
there must be a transition point, a gradient of need perhaps?

What are the signs of needing MVC? What is the first sign? How can one recognize
earlier that a particular program is getting complex enough to benefit from MVC?I've never seen a UI that has not used MVC and has got away with it. Haveyou?

Depends what we mean by "got away". I would bet that the vast majority of VB
programs in the wild do not, in fact, use MVC. Of course, many of them have by
now become hard to maintain, because MVC is a good idea when one needs it.

Regards,

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

[Uncle Bob (Robert C. Martin)]

"Guillermo Schwarz" <guillermo_schwarz@hotmail.com> might (or might
not) have written this on (or about) Sat, 2 Aug 2003 00:57:07 -0400,
:
I've never seen a UI that has not used MVC and has got away with it. Haveyou?

Sure. Lots.


Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |