RE: windows project

Question

If your application is going to be a big one, you might want to divid it
into a set of applets(smaller applications) that can be launched from
separate icons or from a menubar similar to an office suite. In order to
implement this, you will definitely need to define the individual applets by
putting windows in separate projects. All the de-coupling issues mentioned
in the previous replys would then apply.
Mark Savory
GTE Gov. Sys.
-----Original Message-----
From: Curtis Bragdon [mailto:[email protected]]
Sent: Tuesday, March 02, 1999 9:09 AM
To: '[email protected]'
Subject: RE: windows project
Hi Janet,
Your macro level division of projects makes sense, although you should also
consider merging the display data and windows classes before you split up
the windows classes. If you do that, you should be in a better position to
split your windows classes based first on class hierarchy and then on
services that the windows provide.
Also, as John says, note which windows interact and in what way. In
addition to identifying is-a relationships, identify has-a and uses-a
relationships. When you have a window that inherits from another window,
e.g. a standard form window and an employee form window, place the
superclass in its own project, and make that project a supplier to the
project that contains the subclass. In the case of has-a, identify in
which direction the has-a is implemented. Amongst windows, I would expect
this to be one-way, and usually the window where the relationship is not
implemented is a utility window, and can go in its own project, to be
included by all other projects where that utility window is used. The same
logic goes for uses-a (really just a pedantic distinction of has-a).
There are a couple of notes on the technique of using events to talk
amongst windows. While this method does help eliminate the circular
supplier problem, you give up the ability to pass return values, and are
therefore never certain that the intended recipient got the message. You
could implement a return event or return value method, but this would get
messy very fast. Some may also note that use of events is about 10 times
more expensive than use of methods for intra-process communication. This
is true, but unless you have thousands of methods per second, this will not
be much of an issue. You can avoid the whole event issue by moving some
methods higher up in the class hierarchy, but you should review your
design, first.
Also, in the same place where you maintain class diagrams for your project,
maintain a diagram that shows the dependencies amongst supplier plans. In
this diagram, include the classes contained in the project. Visualizing
this may help you understand where the circularity arises.
All this is easier seen than said. Let me know if you would like a diagram
example.
Good Luck,
CSB
-----Original Message-----
From: John Pianezze
Sent: Monday, March 01, 1999 8:03 PM
To: 'Kendall, Janet M'
Cc: [email protected]
Subject: RE: windows project
I would definitely recommend trying to split the project.
Usually if you come at the problem from a different angle, you'll find you
can split it.
* First, instead of splitting the windows by functionality, split them by
sub-system, or groups of windows that pertain to different services the
system provides.
* Identify windows that are re-used by more than one high-level window.
These are auxiliary windows. Popup modal windows can usually be grouped and
supply the top-level windows.
* Ideitify high-level windows that don't interact (much) with each other,
these should be supplied by auxiliary windows, and the popup modal windows.
If the windows communicate, they may not need to know about instances of
each other. If they POST message to each other, (on an object that is
visible to both windows) then they can effectively comunicate without
knowing about each other's implementation. This is also good decoupling,
reducing the windows' dependency on each other.
If windows are ued to model business functionality, then you might find
yourself needing code from one window to another. But if you put all your
business-specific code in your business objects, then BOs can happily
supply
any window, without one window needing to use another window to get some
business functionality.
Basically your windows should be very loosely coupled, and they should be
coupled together with business objects. Usually the only reason one window
need to know about another window is so that it can instantiate and display
it.
Another cool way to separate one implementation from another, is to define
a
series of Interfaces which define how windows interact without tying them
together with any implementation details.
To simplify things you might make design decisions to restrict
visibility.
It might be nifty to have any window be able to switch contexts to any
other
window, but you might find it simplifies things to make your view more
streamlined in their purpose. All of a sudden, your windows are easier to
construct, and happily go into a project by themselves, and are more easily
maintained etc etc etc..
Finally, you might want to build abstractions. You could have a series of
abstract base windows, in their own project that supply all window
projects.
You might build a abstract window classes for each sub-system you identify,
and they will supply each set of concrete window sub-system
implementations.
Small size is key. Small projects, small classes, small method, gets you
the
best reuse and fosters a higher quality of implementation.
John Pianezze
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
"Life is pretty much the same anywhere you find yourself,
because wherever you go, there you are!"
- Master Fwap.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Mazda Australia
Lorimer St., South Bank,
Victoria, Australia
Telephone [phone]
-----Original Message-----
From: Kendall, Janet M [SMTP:[email protected]]
Sent: Tuesday, March 02, 1999 9:11 AM
To: [email protected]
Subject: windows project
We are currently developing a system with four basic projects - windows,
display data, data access and business objects. The windows project
will probably end up with 100+ classes in it (a conservative guess, I
think). I was trying to split it into multiple windows projects grouped
by functionality and am running into supplier plan circularity problems.
I would appreciate responses indicating if you have designed with a
single, large windows project or multiple windows projects and any
pros/cons associated with the direction you took.
Thanks in advance.
Janet Kendall
[phone]
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
This message has successfully passed virus checking.Mazda Australia takes every precaution to ensure email messages are virus
free. For complete protection, you should virus test this message.

Answer 1

1 - moved to the correct forum
2 - More information needed for someone to help... please click below and provide the requested information
-Premiere Pro Video Editing Information FAQ http://forums.adobe.com/message/4200840