Re: Singleton as a common area?
Re: Singleton as a common area?
- Subject: Re: Singleton as a common area?
- From: j o a r <email@hidden>
- Date: Thu, 21 Feb 2008 00:14:52 +0100
On Feb 20, 2008, at 11:59 PM, Graham wrote:
I have a tendency to build an object and fiddle with it
and when I understand how it works, I have to ease the
rascal into the main application.
Not wishing to cause offence, but this sounds bass-ackwards. You
design a class to solve a stated, defined problem. You don't start
with an "empty" object (for want of a better term) and stuff random
functionality into it until it does something useful. OO design is
just as easy to abuse as the older traditional programming models
and will lead to nasty spaghetti-like designs just as easily. If you
aren't clear what problem it is you are trying to solve this is
where the effort should be spent.
None of us are perfect in this respect but classes should have well-
delineated functional boundaries. If you find yourself stashing
miscellaneous functions into a class just out of convenience it's
probably indicative of a poor design or a lack of understanding of
what you're trying to accomplish. Taken to its logical conclusion
any application would only have one instance of one class that did
everything. Which is equivalent to the non-object-oriented model of
programming.
Well, there's that - BUT - In OOP you typically want to create
components with as few dependencies as possible on surrounding code,
this often makes it easy to prototype your new components outside of
the project where they will eventually be used. Doing it this way can
have many advantages:
- Turnaround time is typically faster, as a small sample app
typically has much less overhead
- Your new component starts out in a clean environment with fewer
unexpected side effects
- You're encouraged to not create unnecessary dependencies on other
components in your main project
Granted, most of the time I write new code in the main project, but
using a sample project is also a powerful tool to be used from time to
time.
j o a r
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden