[prev in list] [next in list] [prev in thread] [next in thread] 

List:       extremeprogramming
Subject:    Re: [XP] Small Application Structure
From:       Ron Jeffries <ronjeffries () XProgramming ! com>
Date:       2004-09-29 12:34:11
Message-ID: 1101857450.20040929083411 () XProgramming ! com
[Download RAW message or body]


On Tuesday, September 28, 2004, at 10:59:37 AM, CodeMonk wrote:

> After reading Extreme Programming adventures I am starting to think 
> more about the design of my applications. I was wondering how I would 
> structure a new, small VB or C#.NET Windows application. 

> Instead of calling a startup form I was thinking of calling a class 
> named after the application with a shared Sub Main and a shared member of
> type ApplicationCommand. The Main routine would Application.Run the 
> Startup form. The startup form and all forms called from the startup form
> would have access the the shared member ApplicationCommand that would 
> contain all the methods necessary to get the information they wanted 
> (ie: GetCustomerList, GetProductList, GetOrder.)

I'm not clear on what you're saying here. But in a sense it doesn't matter
for at least two reasons, discussed below.

> I was wondering if this is a good or bad design for a small to medium 
> size business app. Would Ron Jeffries do it this way? I am not sure 
> anymore. I feel lost.

Whether I would do it or not isn't important. What is important is whether
the design is good. I haven't written a two-form app in C#, and in fact I
don't remember how I did it in whatever language I last did it in.

If there are any useful lessons about good design in Adventures, I'm
pleased, but Adventures is really about how to start simply and change the
design until it seems good to us.

So if you were to choose to follow that style for a while, you'd try your
program one way and see whether it feels good, and if it doesn't, you'd
transform it.

Another perfectly good thing to do would be to know what a recommended way
is to do what you want, and to start out that way. You could find that out
by having done it a lot, or by asking someone with a clue. (In this case,
that's not Ron Jeffries.)

> Would Ron Jeffries call a form from another form directly or use a 
> class to call that form? Instead of a ApplicationCommand object that 
> contains all functionality for all forms should they be split into multiple
> objects each owned by the form that works with them the most?

I don't know what Ron Jeffries would do. But I'm thinking that Forms
probably don't own objects. Forms /view/ objects, and when things happen in
objects, the forms find out about it, and when things happen in the forms,
the objects find out about it. But it seems to me that the connection is
more loose. Using delegates, they register interest in the other guy's
activities.

I prefer systems that are about the model, with very thin GUI connections.
That doesn't make it right: it might be more about the fact that I can
usually make the model be very nice, and I'm not very good at the GUI.

> Questions, questions... hopefully some answers will follow from the 
> wise Jedi Knights.

I have no answer. What I would do would be to write a really simple
application that seemed to me to be like the real one. A couple of forms,
just enough in other classes to have the same feel. Then I'd start with the
recommended style of delegate hookup in some C# book, probably Petzold in
my case, because he's about my age, and then I'd look at how the object
interact. If it seemed OK, I'd leave it that way. Otherwise I'd transform
it to some other way, repeating until I was smarter and more comfortable.

That's not necessarily a good way. It is just what I'd do to try to move
from "don't know what to do" to "know a few good things to do". Someone
else might actually already know what to do. That would be just fine.

Ron Jeffries
www.XProgramming.com
Do I contradict myself? Very well then I contradict myself.
(I am large, I contain multitudes.) --Walt Whitman




To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

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

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

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



[prev in list] [next in list] [prev in thread] [next in thread]