Greg Stark wrote:
> Bill Moran <wmoran@potentialtech.com> writes:
>
>>In OO programming, the generally accepted rule is that a program shouldn't
>>access class values directly, but the class should have methods to set
>>and retrieve the data. This allows internal representations to change
>>without affecting the public API of the class. It also allows data
>>validation to occur, if needed.
>
> Note that this is largely a C++ rule. In C++ accessing class members is very
> different and much less flexible than using class methods. Other OO languages
> are not universally so hobbled.
Really? I can only assume you're referring to languages such as perl that have
ties (or equivalent capability). In that case, you're still accessing the data
through a method, it's just a more abstract abstraction. Or are you referring
to something else?
>>I'm just wondering how far this rule of thumb could/should be extended to
>>databases? I mean, you could say: "Nobody does a direct INSERT, but always
>>calls a stored procedure that stores the result." I don't know how much
>>this might break the mindset of the client developer.
>
> This is a popular old-school database approach. Personally I find it
> incredibly annoying, but I can see its advantages as well. But to me stored
> procedures just don't seem like nearly a powerful enough abstraction tool to
> make them worth all the pain this approach entails.
I threw it out there for the sake of discussion. I can see advantages and
disadvantages. For example, I'm working on financial software, and
_everything_ is accessed through stored procedures. This is A Good Think
(in my opinion) because the software is designed to be easily integrated
with other systems. The last thing we'd want is someone getting the wrong
answer to a financial query because they don't understand the schema. A
much more reliable way is to have them
SELECT * FROM get_monthy_payment(month, account); so we know they're getting
the correct answer.
But I _can_ see the potential PITA this can cause. I guess it depends on
the circumstance.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
