 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
 Posted: Mon Dec 12, 2005 2:25 pm Post subject: Help on class design |
 |
|
I'm revising a bit of code someone else developed, and I'm considering
a couple of alternatives, but I don't really know what the tradeoffs
are, so I was wondering if any of you would be kind enough to comment
and/or explain things to me. :)
The main concept here is Notes. There are several kinds of Notes, each
of which are based on real-life paper forms. Each type of note needs to
track different pieces of information. There is a graphical screen for
people to input and edit the data. The current implementation has
individual classes (inheriting TForm) for each note, although their
data is stored in a single table (fields that are irrelevant for a note
are simply left null. There is a field called "type" to distinguish the
notes). The user is also able to print any note.
The new requirements that I'm implementing are: Only one note window
can be open at a time. The window needs to be modeless. There will be
two places now where the notes screen can be invoked (so some
decoupling needs to occur).
Two designs I was considering:
1) Inheritance - there is a basic Note class (inherited from TForm),
which is a (possibly abstract?) singleton class. The other notes
inherit from this class. If the user tries to create a new note, and a
note window already exists, then they get a message. The code to handle
this is in the abstract class.
2) A manager-type class. When a new note window is needed, ask the
NoteManager. It will decide if a new note should be created, show a
message, or bring the existing window to the front.
The second options seems simpler and straightforward, but it feels a
bit more ad-hoc to me. The first options sounds overly complex. I'm
not sure how to decide what is the better approach. Or maybe there's
another option I hadn't considered?
-Corinna
|
|
| Back to top |
|
 |
Wayne Niddery [TeamB]
Guest
|
| Posted: Mon Dec 12, 2005 6:48 pm Post subject: Re: Help on class design |
|
|
[email]nutmegkat (AT) gmail (DOT) com[/email] wrote:
| Quote: |
The main concept here is Notes. There are several kinds of Notes,
each of which are based on real-life paper forms. Each type of note
needs to track different pieces of information. There is a graphical
screen for people to input and edit the data. The current
implementation has individual classes (inheriting TForm) for each
note, although their data is stored in a single table (fields that
are irrelevant for a note are simply left null. There is a field
called "type" to distinguish the notes). The user is also able to
print any note.
The new requirements that I'm implementing are: Only one note window
can be open at a time. The window needs to be modeless. There will be
two places now where the notes screen can be invoked (so some
decoupling needs to occur).
Two designs I was considering:
1) Inheritance - there is a basic Note class (inherited from TForm),
which is a (possibly abstract?) singleton class. The other notes
inherit from this class. If the user tries to create a new note, and a
note window already exists, then they get a message. The code to
handle this is in the abstract class.
|
This is exactly what you need to break away from - the idea of using visual
forms or controls as a basis for business objects or business processes. A
form is only a means of presentation and data-entry, it should not implement
rules or logic.
| Quote: | 2) A manager-type class. When a new note window is needed, ask the
NoteManager. It will decide if a new note should be created, show a
message, or bring the existing window to the front.
The second options seems simpler and straightforward, but it feels a
bit more ad-hoc to me.
|
Nothing ad hoc about it, it is a much better design. However, even the note
"manager" you describe above should not be the note class itself because it
is still dealing with specific visual presentation.
The class representing the note itself should be totally non-visual and
absolutely independent of any visual concerns - it will not know about memo
controls, list boxes, or forms. It can descend from TObject. Here you can
implement any rules about the note itself and store the data read from or to
be written from the database. It will have properties, such as the note data
itself, a date field, an author field, etc. if any of these are necessary.
Depending on how different the types of notes are, inheritance from a base
Note class may make sense, or perhaps simply a type field that can be cased
in a single class is sufficient for your actual business rules.
Now you can think about a NoteManager class that knows how to deal with the
Note class (and its descendants if any), and can also do the things you
describe - figure out what form is needed, etc. and pass any entered data
back to the note object.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"Reality is that which, when you stop believing in it, doesn't go
away." — Philip K. Dick
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
