Re: Queries and OO
From: Robert C. Martin (unclebob_at_objectmentor.com)
Date: 01/17/05
- Next message: Robert C. Martin: "Re: Application, database and schema?"
- Previous message: Robert C. Martin: "Re: What is an OODBMS?"
- In reply to: Daniel Parker: "Re: Queries and OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 17 Jan 2005 12:28:49 -0600
On Sun, 16 Jan 2005 19:05:35 -0800, "Daniel Parker"
<danielaparker@spam?nothanks.windupbird.com> wrote:
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
>news:hg8mu0tdkb46h6grc4avab33irpr88pajj@4ax.com...
>>>
>>>Isn't queries something you may need even if you don't use a database?
>>
>> Yes, but without a database one typically does not have a query
>> language other than the programming language.
>
>Sure you do. Regular expression matching,
I don't view regular expressions as a query mechanism; but I take your
point. In any system that makes heavy use of regular expressions to
do queries and searches, I'd like to partition the design so that the
regular expression engine is encapsulated and does not pollute the
rest of the application. Indeed, FitNesse has such a design.
>XPATH queries,
Yes, these are queries of a sort. And I encapsulate them into
specific parts of the design so they don't leak out all over the
place.
>> The fact that classes/objects can be used to model things in the real
>> world is irrelevant. Processes and stores can also be used to model
>> things in the real world. Inverters and and gates can also be used.
>There's a literature, though, that motivates OO approaches to programming by
>drawing on the analogy between a physical system modeled with mechanical
>objects and a physical system modelled with software components. It's hard
>to argue that this wasn't one of the motivating factors behind OO, and the
>idea is reflected in its name. Whether you find the idea compelling or not
>is, of course, another matter.
I can make (and have made) that argument in the past. OO was
"discovered" when Nygaard and Dahl modified Algol to keep the function
stack frame on the heap instead of on the stack. It is true that they
were working on a simulation project at the time; and this has implied
that they were trying to enhance the real-world-modeling abilities of
the language. On the other hand, the mechanism they chose is so
strongly related to bits and bytes that it's hard to justify all the
philosophical ramifications that have followed.
The bottom line is that OO is a set of language tools and programming
techniques that decouple modules by interposing jump tables in all
function calls, and keeping those jump tables in data structures on
the heap.
>> The benefit that OO programming languages give us is a way to manage
>> dependencies in our source code.
>
>To manage or to obfusicate :-)
The power to manage *is* the power to obfuscate. You get to choose
which way you will use that power.
>I don't see this as a defining
>characteristic of OO, in the sense that you could build a thery of OO on the
>primitive notion of dependency management.
I disagree. There is very little in software that could be said to
meet the criteria of a "theory". I think the tools and techniques in
OO that support decoupling have been put together into a set of
principles and patterns that could eventually be used as primitives to
support a quantitative theory of software design.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
- Next message: Robert C. Martin: "Re: Application, database and schema?"
- Previous message: Robert C. Martin: "Re: What is an OODBMS?"
- In reply to: Daniel Parker: "Re: Queries and OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
