"Richard Brady" <rrllbrrady@[EMAIL PROTECTED]
> wrote in message
news:e1KLj.88781$D_3.36594@[EMAIL PROTECTED]
> Pete Dashwood wrote:
> [snip]
>> The im****tant (to me...), and usually overlooked by people obsessed
>> only with coding, thing here is the CONCEPTUAL use you get from an
>> Object. This is BECAUSE it is as you described above. Identifying
Objects
>> conceptually and building them in code go hand in hand in my book. I
have
>> never considered Objects to be ONLY the "instantiation in memory of a
>> defined computer Class", even though that is all they are to a program.
>> PEOPLE can use Objects (conceptually) and can model with them, modify
>> them, (without committing any computer code to memory), do walkthroughs
>> with them, and conceptually juggle with them to get a better solution.
>> That is just as im****tant in an Object Oriented approach to problem
>> solution, as the technical details which apply to computer code.
>>
> [snip]
>> Absolutely. The fact is that when you encapsulate behaviours and
>> properties into an Object, the synergistic whole, is far greater than
the
>> sum of its parts. The code representation is only ONE aspect of it.
>>
>> Pete.
>
> OK Pete,
> At the risk of getting you in serious trouble again, here I have these
> files to read containing data. How does this data constitute an object
> and after I've manipulated the heck out of it generating the view I
wish,
> how do I save the object(s) to media (disk, print or screen)?
>
Well the serious trouble is something I'm quite used to... although it is
getting tiresome lately. Maybe I'm getting old...:-)
The only good thing about banging your head against a wall is that it is
nice when you stop.
However, I believe your enquiry to be a fair one so I'll respond.
I have bookshelves full of books.
The data in them, just like your files, in and of itself, does not
constitute objects.
So, the answer to your first question is: "Data is not an object".
However, if I decide to extract and organise some of the data in my books,
I
can build an object from it.
For example:
I want to find out about the life of Rudyard Kipling.
I go to the bookshelves (or the Internet) and read some biographies about
him. I notice certain salient points (his date of birth, when he died,
points about his early childhood, what shaped him... etc.) I read some of
his stories and poetry and consider them.
Now I can say I have some knowledge about Kipling. (It is no longer just
data; it is abstracted into a concept of Kipling... If I come across a
quotation or lines extracted without attribution, I can make a reasonably
accurate guess as to whether Kipling may have written them. This is more
than I can get from just the facts alone.)
Then I do the same with Edgar Allan Poe.
I find there are parallells with building a concept of Poe and building a
concept of Kipling.
If I abstract these common concepts I arrive at the idea of a "Writer".
This is a "Class" of information.
Within this Class of "Writers", I can visualise specific instances.
(Kipling
and Poe are just two instances of an "Object" within this Class.)
Now let's look again at your questions...
"How does this data constitute an object..." Answer: It doesn't until
you
make it do so.
The point is that the Object is conceived, and then the data is loaded to
it. The bookcase is an amorphous collection of data, your files are
organised into records and each of these records COULD be about a specific
writer, but in both cases, the data needs to be populated into an object
instance before we can claim to have a specific Kipling object or a
specific
Poe object, within the class of writers.
"...and after I've manipulated the heck out of it generating the view I
wish, how do I save the object(s) to media (disk, print or screen)?"
By adding methods to the object (or letting it invoke other methods in
other
Cl*****) that let it generate a view of itself and let it save its
properties. These methods can be parameterized and the parameters can be
passed from external programs or by using the GET and SET methods inherent
in the object.
If you compare this with standard batch processing it is not as efficient.
You must instantiate an object in your initialization and then load the
data
for each record on your file to it, as the data is read. You then invoke
your manipulation method(s), your view method(s), and your storage method,
and repeat the process.
Although this sounds unwieldy, there are actually some benefits in doing
it.
1. It allows separation layers so that code which does view processing,
code
that does DB access, and code that does other functions can be layered
into
an n-tier approach easily. Object methods are small and encapsulated;
easily
shared, replaced or enhanced.
(MS are making a big deal in .NET currently about the MVC facility that
has
just been announced. This stands for "model-view-control" and allows web
based systems to separate code as just described: The data model (LINQ or
SQL) is separated from the web page view (HTML, AJAX, Silverlight,
JavaScript, etc), and both are separated from the control code (C#, VB,
etc.
(OO COBOL can also be used)) which is placed on a "code-behind" page
attached to the .aspx page. Some of us have been doing this manually for
some time now, but it will be nice to have it automated...
2 The "control logic" is much shorter (and therefore easier to modify)
than
it would be for a Batch program that implemented all of this
monolithically.
Nevertheless, we don't usually use Objects for Batch processing.
It is totally hopeless for me to take specific instances of current
procedural approaches and show how they could be implemented using OO.
(Besides it is counter productive, because it just confirms the
prejudices... OO is not as good at procedural processing as procedural
programs are. That doesn't mean there is no room for OO or that OO has no
use. In fact the OO paradigm unlocks doors that procedural code simply
cannot penetrate. I really can't be bothered arguing this any more... the
world has voted with its feet; several hundred million programmers world
wide have gone with it; if less than 100,000 COBOL people want to resist,
I
can't see that making any significant difference.
OO is not about pedantic arguments on the exact shade of meaning of a
theoretical term. (well, OK, it IS in CLC... :-)), it is about an approach
to system development that is more intuitive for non technical people,
quicker, smarter, and MUCH more cost effective than carving lines of code
by
hand.
But don't take my word for it... look around, see where the jobs are.
> Thanks for this and other insights.
Thank you for your courtesy. You are very welcome.
Pete.
--
"I used to write COBOL...now I can do anything."
|
