Re: Architecture question...overthinking again :-)
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Thu, 11 Jan 2007 13:14:46 -0600
"MP" <nospam@xxxxxxxxxx> wrote in message
news:OnG$JHRNHHA.1252@xxxxxxxxxxxxxxxxxxxxxxx
warning ... two part question ahead :-)exe.
...I'll blame it on the fact that I'm again re-reading "Code Complete" <g>
Working on an app, trying to "decompose" it into objects.
I don't think it's germane but it happens to be an axdll run from a std
jobs),
So I have a class(dll) that manages some other classes(to do various
we'll call it cManager <g>a
If I want a report on a database it creates a cData class to handle
accessing a database and cReport to handle reporting on results.
cManager passes cData to cReport ... Set moReport.DataSource = moData
cReport reads the database (with the help of cData) and then reports it's
findings in a listview on a form(with the help of cListView)
cListView handles formatting headers and entering data into a listview on
ReportFormbad
which brings us to the first question <g>...you were beginning to wonder
eh?? ...
question 1)
Is this completely stupid to break this all up like this?
It does seem to be helping me keep track of what i'm doing where(with my
memory thats important<g>) compared to when it was just umpteen subs andsome
functions in one module...but i do wonder if breaking out every little job
into it's own class (like setting up a listview) is overdoing it ???
and for the second question....
while all this is going on, I want to give the user indication that
somethings happening so I have a frmProgBar to show a progress bar
cReport creates frmProgBar, sizes up the quantity of data, sets pb.Max and
increments while it's "Reading Data"
then cReport hands off frmProgBar to cListView
... Set moLv.ProgBar = Me.ProgBar
so cListView can increment pb while it's loading the listview(which for
unknown reason is not instantaneous??)conflumerrations
When cListView is done with it, it can destroy it and show it's
ReportFormWithListView displaying the results of all those
<g>
Then ReportForm.CmdClose_Click event raises Event Done
clistView receives that event and raises it's event Done
cReport recieves that event and raises it's event Done
cManager receives that event and re-shows it's .MainForm to await further
instructions
question 2)...whew...thought we'd never get there ...<bg>
Is this a reasonable structure or is there a better way for two classes to
share a common form instance?
...or should they not... maybe each should create it's own instance and
show/destroy at will?
any advice for a confused amature?
Thanks
Mark
Hard to advise whether to stop overthinking or to just rethink the whole
thing.
First drop 'decompose' from your vocabulary. That is something that belongs
to structure programming, not OO.
Drop cData. That is obviously leading you into a data-centric design. Again
we are back to structured programming.
As you noted, merely breaking umpteem subs and functions into related
modules (VB classes) doesn't do anything except making it easier to find
stuff. But you could do that with just judicial naming and the Browser.
IMHO, you need to shutdown the IDE and go visit online or in person a book
store and find something on Object Oriented analysis, design, or
programming. Spend some time with a good book and a yellow pad.
-ralph
.
- Follow-Ups:
- References:
- Prev by Date: Re: BackgroundWorkker in MDI Form
- Next by Date: Re: What microsoft has to do with...
- Previous by thread: Architecture question...overthinking again :-)
- Next by thread: Re: Architecture question...overthinking again :-)
- Index(es):
Relevant Pages
|
