You may not hear this very often, but the "art" of good architecture reminds
me a lot of taking thermo back in college. It was generally considered a
hard course, but I loved it (partly because easy doesn't keep my attention).
At the final we were allowed to bring a page of notes. I saw that many
people had scrawled as many equations they could in the tiniest hand on both
sides of their single 8 1/2 x 11 page. All I had was four equations written
on a note card (why not three? I can't remember). That's all I needed. From
them I easily derived everything required to answer all the problems on the
test, and I finished an hour early. A few precious drops of knowledge served
me far better than the fire hose.
How does this relate to designing an n-tier system? I believe there are a
few First Principles of design that can guide you through any problem:
Simplicity. Normalization. Interchangeability. Manageability.
- Simplicity
If it's not simple (this can be a relative, intuitive term), learn to hate
it. Be ruthless.
- Normalization
It's not just good database practice. Normalize your logic, don't repeat it
all over the place. Subclass. Use DLL's.
- Interchangeability
Always design with the assumption (even if it's not likely) that your UI can
change independently of the functions your app delivers to its users. As an
exercise, make a form to deliver a few data presentation and editing
functions to a user. Then make another, different form to deliver the same
functions, maybe with a different look and feel. Then apply the
Normalization principle to these data-presenting and editing functions...
the beginnings of "n-tier" design will emerge naturally and intuitively.
- Manageability
Don't "fly blind" with your data usage. When the time comes to make some
serious changes to your database design, you should be in the position to be
able to easily map the footprint of the impact. Don't worry too much about
this when your learning, but always keep it in mind. If you hard code SQL
into your app, ask yourself, "What if I have SQL like this (~x100) in lots
of places? How can it be managed so I can tell without doing a text search
through all of my projects where a certain table is being used?" (eventually
you may decide SQL belongs nowhere in hard code, even in the "business"
layer). Also ask yourself periodically, "How could I make my app keep track
of (and maybe self-document) all data-altering functions that are relevant
to its users?".
Some may tell you to learn by example, and that's good, too, but I strongly
recommend you focus on building a strong understanding of the "what" and
"why", as well as the "how". Do this and eventually you'll be able to take a
look at other people's work and make extremely relevant judgments, like
"this design is bad because the logic isn't normalized", or "I don't like
this system, how could you possibly manage changes to the database?".
These links also talk about proper design flowing from First Principles.
http://www.sdmagazine.com/documents/.../sdmsdw1b.html http://www.asktog.com/basics/firstPrinciples.html
HTH,
Bob
"slonocode" <oh******@spamsux.sux> wrote in message
news:36*************@individual.net...
I'm wondering if there are certain processes that I could follow to
learn to design better classes? Where could I find these processes?
Is designing classes more of an art that comes from experience or can it
at least be somewhat done by a process?
I have the most trouble with abstracting the specifics, such that a
class could be reused or just be generic such that anyone could use them.
My frustration has emerged in trying to learn n-tier architecture. I
can't seem to find a project small enough such that my eyes don't glaze
over trying to decipher the data or business layers. Or I can't find a
project that doesn't involve ASP.Net which I haven't really learned yet.
