R,
Your honesty (and courage!) are refreshing.
The first thing I would say is that you are to be commended for your
pragmatism. Don't change it. Use what works, yet be curious about ways to
improve it. In that sense you are exactly on-track.
My sense is that you may have a background in structured programming and
haven't quite had your "aha" experience yet with OOD. I would focus on
grokking design patterns but try to find practical examples of each pattern
that you can relate to. I admit, that's easier said than done since far too
many writers fail to provide practical rationales and examples. But with a
fair bit of Googling you can usually some up with something.
Also, consider looking at "anti-patterns" -- things not to do.
Another thing you can do to expand your mind is to learn a new language now
and then. Each one has its own ways of approaching the problem domain and
comparing and contrasting how they work gives you a deeper understanding of
concepts. Sometimes you see that features or concepts that are terribly
important in language X are less important in language Y because of
something inherent in the language, not necessarily something inherent in
OOP. Personally for example I'm pecking away at Ruby right now and find it
rather mind-expanding after two and a half years of steady C# coding.
You are right not to feel obligated to use every feature just because it's
there. Start by naming your number one maintenance headache in the many
apps you've written and seek out the simplest and most elegant ways to
mitigate that problem first.
As to your question whether "all this stuff" is just for "big projects" --
I'd give you a qualified "no". There are often different trade-offs in,
say, creating a small utility app vs coding something that has to fit into
an Enterprise framework vs something destined for commercial release. But,
good design is good design and the best design ideas tend to be generally
applicable to most any non-trivial project.
It's hard sometimes to find the balance between some theoretically "best"
way and the messy real-world demands of deadlines and marketing droids and
so forth. The way you describe the acquiantance who was whipping up all
sorts of elaborate and elegant "software souffles" might be describing some,
any, or all of the following:
1) A really expert guy working "in the zone"
2) Someone trying to build an app that only he can maintain
3) Someone constructing a monument to their ideal of the perfect program, at
the expense of practical matters
I'm a little worried that he creates "everything from scratch". Surely he
has a body of existing work that he leverages as a starting point! If not,
why not?
Does this guy have a track record of producing stable software on time that
the customer is happy with? Then emulate him -- especially if he documents
his work and can explain it coherently. Otherwise take him with a grain of
salt.
--Bob
"R Reyes" <RR****@discussions.microsoft.com> wrote in message
news:77**********************************@microsof t.com...
Hello All,
I'm always looking for ways to improve my code. Most of the time
(whenever I'm working on a project) I write a bunch of functions. Then after the
project is finished, I put all the similar functions into their own
module/class/page for neatness:
-- like a stringsManipulate class which has all string manipulation
methods to the project...separated from the whole project into its own library for
neatness.
-- like a databaseActions class (or code library) which holds all the
database methods to the project...also separated from the project into its
own library for neatness.
By the time my project is separated/sorted, it consists anywhere from 5-10
pages/libraries of functions so that everything is nice and neat.
However, there are never any delegates, factories, interfaces, extensions,
exceptions classes, none of that. Sometimes I have some error handlers
but i never have any of the other features I just mentioned. So, what i'm
wondering is...is all that fancy stuff really necessary? Or, is that just
something you need to worry about when you're working on something you
know millions of people will use (like some big business product or application
like AOL)?
I've been coding for several years now and I've seen many other people's
coding styles. One guy I knew I think created all his objects from
scratch. I've seen him code his own framework of factories, iterators, interfaces,
structs, event handlers, delegates, creating exceptions here, throwing
exceptions there, extending something there, implementing something here.
It looked very confusing and very time-consuming...yet efficient and neater
than the way I was doing things.
So what I want to know is...is this all fancy stuff necessary or any good
for small-medium website developments or desktop apps? And if so, are
there any links where I can learn the best design, strucutres, object models,
and the like?
I have been looking up some c# design patterns and there are many of them
have my mind going in circles. When coding normally, I never know when I
need to make exceptions, or interfaces, or events...My mind doesn't think
like that and I'm trying to find a place that will make me understand.
Usually I just write a function that does what I need to do and it works
so I take it, break it, and separate it for neatness. But somehow I feel
that's not enough. Somehow I feel I need to get my hands even dirtier and create
my own framework of factories and all those other concepts I can't really
understand. But is it really worth it? And would small web development &
desktop application stuff really have a great improvement in speed and
cleanliness? Well cleanliness I can see...speed I'm not sure of...I guess
so?
Hope some of you can help me out. Thanks for reading.
