Title: Message
Kyley wrote:
if your're worried about freeing objects, then use interfaced objects. If you're worried about speed (don't be) object creation is hardly slow by any measure. if you are worried about easy to maintain code, re-use and scalability of design. don't use arrays and records. Every record type you create is just an object lacking encapsulation of business rules.
 
I guess it really comes down to being an OO developer or not. 
You probably don't mean it this way (email is bad for that) but the above comes off as rather patronising.
 
All forms of abstraction have a performance cost. The job of a good software engineer is to know when to break them. The fact that _you're_ not worried about speed (or abstraction costs) implies you have the luxury of operating with much smaller problem domains or databases than others here (including myself) do.
 
When you're dealing with databases in the gigabytes or entities in the hundreds of thousands, bypassing unnecessary abstraction layers can make a big difference.
 
Just like a 3NF (or BCNF for the truly hard core) database may need denormalised cached totals for acceptable performance, large collections of simple types may need to bypass object (or interface) abstraction over-head to meet performance targets.
 
And along with that, many simple types don't really have any business rules to encapsulate - an Amount, a Point, a Rectangle, etc. Nothing is really gained by wrapping them as an object. OO languages like C++ and Delphi go to some pain to efficiently support simple record types without object overhead for exactly this reason.
 
And C# likewise has value types to avoid reference type overhead for many simple types. These language features wouldn't persist if there weren't significant software domains that needed them.
 
OO development techniques are just _one_ tool in a software engineers toolkit to be used when appropriate.
 
Remember the old saying - 'If all you have is a hammer, everything looks like a nail' :-)
 
TTFN,
  Paul.

Reply via email to