Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

GUI class design 1

Status
Not open for further replies.

SpankySpanky

Programmer
May 25, 2005
21
AU
I have embarked on my first major project in VB.NET 2003 and I am seeking guidance on how to do the GUI interface.

I am comfortable with the concept of classes now and I have been successfully building some components with classes and my limited understanding of design patterns. I would like to know about the general methodology that OOP programmers use when interfacing a GUI with the remainder of the program logic.

For example, I assume that the GUI is built around the default form you get when you create a project, and that the GUI is treated separate from the main logic, with messages going in between. If I had no further advice I would probably build classes that handle the way the controls work, ie. a listbox of names might have an associated class that handles the data and communicates back and forth with the main program logic.

If I need input into the main program logic from the GUI, I am guessing that I should use function delegates or events eg. to tell main logic classes that a button has been pressed, or that selections have been made etc.

Is this on the right track? What do experienced OO Programmers do?

Thanks for any comments.

 
<If I need input into the main program logic from the GUI, I am guessing that I should use function delegates or events eg. to tell main logic classes that a button has been pressed, or that selections have been made etc.

Just use events, that's what they are there for.

Yes, you're definitely on the right track. Your intuitions are very accurate.

I would investigate the "model view controller pattern" if I were you. I would also investigate the concepts of "cohesion" and "coupling", with the idea of balancing these. In general, a well-formed object has a well-defined purpose, and concise interaction with other objects.

HTH

Bob
 
Thanks BobRodes

I looked up the Model View Controller pattern, and I think that also answered another question I had. Sometimes I notice interaction between different sections of applications; for example, if you get a list of files using the search function in Windows Explorer, and then externally add one that matches the search, it updates automatically in the search list.

Is this the same mechanism at work?

Thanks for your reply.
 
I would say very probably. It's certainly the mechanism I would use to achieve the behavior.

You're asking some very intelligent questions, and I will say that I've seen a great deal of code that has obviously been written without any of your considerations in mind. It would seem that you have a considerably better grasp of the OO paradigm than you may believe.

Other study topics:
1. Cohesion and coupling (again!).
2. Iterative and incremental development lifecycle, as opposed to the "waterfall" method.

Here are a few deliverables you might want to consider:
1. Problem statement.
2. Semantic dictionary.
3. Use Case diagram.
4. Class diagram.

Having a working knowledge of the above, and a first pass at the deliverables, will probably be useful to you. Feel free to ask specific questions if you need help.

In general, I'd say it might be time to quit cuttin bait, and start goin fishin. :)

Good luck,

Bob
 
By the way, this thread has some excellent material. thread678-1121478
 
Thanks a lot for your advice Bob. I'm learning a lot by following up your pointers. I appreciate your time and effort.

Chris
 
You're very welcome. For a lot of general OOAD information, a couple of good books to look at would be Fowler's "UML Distilled" and Pender's "The UML Bible".
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top