🚀 go-pugleaf

On 3/7/2005 at 9:30:19 AM, Scott wrote:

> I haven't actually written the code yet.

Then you should start.  Sometimes it is hard to get going when you do not
know where you are heading.  But at the same time, you will seldom be able
to know the exact path until you start.  Once you get moving, you will get
a better feel for where you are heading.

> Let's say my main application does something to a database, but before
> the operation can occur, the user must login.
> 
> So form1 is the "do something to the database" form.  Form2 is the login.
> 
> I've read that if I use the Dialog class, Form2 (login) requires Form1 in
> its constructor.

That is one possibility.

However, instead of accepting an argument of type "Form1", you can define
an interface to use in place of the concrete class.  The interface would
contain only those methods that the login dialog needs to use to inform
its caller about what is going on.  This would decouple the two classes
and allow the same dialog to be used by other "forms" (or code other than
a form).

In some cases (although I am not sure this is one of them), it may be a
good idea to make this a settable property rather than a static value
supplied only with the constructor.  This is a good approach when it makes
sense for the associated object to change over time.

An even more general version of this approach is using "listeners".
Rather than only allow a single instance of the interface property to be
set, you allow any number of them.  You have undoubtedly seen this pattern
many times in the AWT / Swing components that you have used.

For a modal dialog, it often makes sense to use property "getters" on the
dialog.  The code shows the dialog, then when it is dismissed, the code
gets the property values using the getters.  Of course, this only applies
to the "results" of the dialog, not information the dialog needs to
perform its work.

> In that case, would I implement a "loginButtonPressed" method in Form1
> (the main app)?  Or is there a better mechanism?

The goal is to reduce coupling and increase orthogonality in your code.
In order to accomplish this, each class in your code should have a concise
and well-defined purpose, and classes should know the absolute least
possible about how other classes work.

So in this case, what does the main form need to know about the login
dialog?  More specifically, does it need to know that it the user has
pressed a "login button", as opposed to press the "enter key"?  Obviously,
it does not, so at least that name is inappropriate.

So what does the main form do and what does it need to know?  I do not
know what your application does, but my guess is that it has some
functionality that it needs to provide, and authenticating the user is not
the core of what it does.  It probably just needs to know who the
authenticated user is.

So you probably want a separate class that handles the authentication.  It
would be the one that knows about displaying a login dialog, although it
should not know whether the user presses a button, hits Enter, or
whatever, since the dialog's job is to handle the user interface.

In order to do its job, your dialog will probably need to be able to check
whether a username/password combination is valid, since you probably want
to give the user a second chance if he makes an error.  But again, that is
not its primary function - you probably want the authentication class to
handle that, or even a separate object provided to it by the
authentication class.  More than likely, it would provide this object to
the dialog in its constructor.

All of this probably sounds complicated to you, but it really is not.
Once you learn to create simple objects that do their own thing (and only
their own thing), you will find that each little thing is quite easy to do.

-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html