Some fundamental OO thoughts (not urgent)
Hans-Joachim Grüßner
I want to share some fundamental OO thoughts with you:
I'm just wondering, wether that we do in VO is really objectoriented,
but windows-oriented. Well, we treat our windows as objects, but...
To understand things better, allow me to lead you the way I came to
thouse insights:
I was going to make some basic classes for future apps. I saw many
apps, which concern with persons, named customer, clients, mandants,
patients....
So I thought to build a basic PERSON - class wherefrom I can inherit
all thouse.
This class Person has instance-variables like first_name, last_name,
adress etc, and may have methods like getdata(), new(), change(),
search() etc, combined with windows to do that. In this way an
instance of person _has_ a GUI for doing the Input/Output stuff and
not a window has (or owns) an instance Person.
Having build a kind of skeleton of this class I was wondering, how to
integrate that in a shellwindow or something like that.
Well, I didn't find a god solution until now, and that brings me to
the above mentioned thoughts.
It's talked in bussiness so much about 'customer-orientation'. Well,
isn't that a person-orientation ??
And for any bussinessman to do so computer-based wouldn't it be better
and helpfull to have apps, with are person-oriented from the birth ??
Perhaps I'm on a wrong way, perhaps I don't see the trees standing in
the wood, because I'm in VO a beginner to intermediate, not more.
Please tell me your thougts about that.
Greetings from the baltic
Hanjo
----
Software & Seminar-Kontor Hans-Joachim Gruessner
Pommerby 4 D-24351 Damp
Fon +49 4352 91 25 95 Fax +49 4352 91 25 97
e-mail mailto:dl3...@darc.de
URL http://www.ZahnArzt-Kontor.de
Geoff Schaller
What you are describing is in fact the basis of inheritance, one of the four
key tenets of OOP: abstraction, encapsulation, polymorphism and inheritance.
At the risk of sounding like an advertisement, get Sandy Hood's new VO book
and read Chapter 5. I think CA has a white paper on-line but I can't
remember where. Other than that, dial up OOP on the internet and sift
through the 38,343,902 pages which will come up <g>.
Yes, we are windows programmers and that very much is an event driven
nightmare. But VO is also one of the true OOP languages around and even so,
you can programme completely linearly if you wanted. So we program windows
with an OOP environment. You have complete freedom of choice - what more
could you want <g>.
Geoff
(Remember to place new queries at http://forums.cai.com )
Hans-Joachim Grüßner <hanjo.g...@t-online.de> wrote in message
news:384218c9....@news.btx.dtag.de...
Mathias Håkansson
they have divided our VO window into two classes
The Window class
and the Document class.
The window class is the one that handles all contact with the user, it's the
interface. The document class is responsible for storing data. It also does
all operations on the data. There are cases however when the document class
does things that maybe the window class should have done instead, like
drawing. There are however obvious advantages with this. The data is drawn
with functions in the window class so you don't have to think about zooming
and such in the document class. The window class takes care of all such
things. The document class also takes care of saving the data.
What about a document class in VO. Well, it sertainly can be useful in some
occations, but if you use dbf files the dbserver class is infact a kind of a
document class. It's only if there is no obvious connection between data and
a database field that a document class can be useful. However if you want to
use the browseview you will need a server class to connect to it, so I
suggest that you think twice before using this approach.
The document class in this c-sample managed the data in a double linked
list, which is a far more complicated way of handling data than using
dbf-files. The only good thing is that you can organize your data any way
you want. You can go for tree structure or n-dimensional matrix whithout
problems, but again it's on much lower level of abstraction and a lot more
tecnical.
When I read what I just have written it strikes me that I only have tried to
persuade you to not do anything out of the ordinary. I think that what you
should do depends on how much time and effort you are willing to pay for
this kind of solution. And don't forget that even though you loose some of
VO functionality and have to write more code your resulting document class
is is extremely powerful and if you construct it in the right way you can
connect more than one window to it. Even if you aren't going to do that you
should contruct the document class as if you were. This will make it more
usable. You should always try to make your classes with I high degree af
context and try to minimize the interface with other classes.
Hope this discussion have given you some more facts to go on.
Mathias
Hans-Joachim Grüßner <hanjo.g...@t-online.de> skrev i
diskussionsgruppsmeddelandet:384218c9....@news.btx.dtag.de...
Hans-Joachim Grüßner
<geof...@bigpond.net.au> wrote:
>H-J,
>
>What you are describing is in fact the basis of inheritance, one of the four
>key tenets of OOP: abstraction, encapsulation, polymorphism and inheritance.
>At the risk of sounding like an advertisement, get Sandy Hood's new VO book
>and read Chapter 5.
Hello Geoff,
well, I have this book already and read that Chapter too.
I wrote, that I'm not an expert in VO and Windows, but.. I'm one of
those old clipperheads, who from the very beginning (classy()) did it
the OOP way. (There were Class Methods, Class variables, things VO
doesn't have.... but Jasmine).
So I'm quite familiar with OO I think. Even if I lack some details in
Windows and VO programming, I know quite well the structures.
My question has a 'philosophical' background too.
I feel, that we in future have to do something like 'person-oriented'.
Well, you claimed we are Windows-programmers. I think, we should treat
windows as a tool to describe the world, not the world itself!
To tell an example: German Telekom is internally using
(Windows?)-Programs to control their people.
It's now like that computers tell the employees how they have to do
their job, not the customers.
Well, ask any german member of this NG how 'happy' they feel with
their telekom.......
The step from the procedure oriented to OO was a step. I think, there
are steps to follow. The one to PO could be one, couldn't it ??
(Besides: PO is OO)
If you have an customer, who wan't any app from you, it's first to
analyse, what he wants to do.
In my experience, the most of our customers have to do with persons:
clients, their customers, patients, debtors, mandants.
So the first 'event' is, any person is standing before the desk, being
on phone, wrting a letter/fax. Then _our_ customer has to react -
computer-aided.
I think, it would be easier to formulate the needed programs in this
case person-centered not window-centered. OK, we take windows as our
tool.
You said " You have complete freedom of choice - what more
could you want <g>.".
Well, I don't want to go linearly. But how to do it in the PO-way ??
HTH
Hanjo
---
I think CA has a white paper on-line but I can't
>remember where. Other than that, dial up OOP on the internet and sift
>through the 38,343,902 pages which will come up <g>.
>
>Yes, we are windows programmers and that very much is an event driven
>nightmare. But VO is also one of the true OOP languages around and even so,
>you can programme completely linearly if you wanted. So we program windows
>with an OOP environment. You have complete freedom of choice - what more
>could you want <g>.
>
>Geoff
>(Remember to place new queries at http://forums.cai.com )
>
>
>Hans-Joachim Grüßner <hanjo.g...@t-online.de> wrote in message
>news:384218c9....@news.btx.dtag.de...
Geoff Schaller
Sorry if I misunderstood your point.
With all due respect though, I think you are mixing UI issues with
programming issues. But I also think your basic thesis is correct:
programmers often put system performance before user friendliness. ie, your
PO. I think that good programming is easier with solid OOP designs but that
is only from a functional sense for the technical performance of an app. We
try to also please and comfort the user - to make his or her job better and
easier. As you put it, look after the PO side.
So I think I am saying that you must have OOP and PO (let's not put them the
other way around, please <g>) and that an appropriate balance must be
achieved. If we don't get the user interfave correct then it won't matter
how much OO is inside, we won't have any users to worry about.
Cheers,
Hans-Joachim Grüßner
I feel that we are beginning to understand each other perfectly, so
that's the right base to continue the dialog (If you like or not <g>).
Well, of course 'PO' is OO.
But now, let's go into code:
I have a base-class PERSON as above mentioned with methods to put in a
new instance, to change data to search data and so on.
Now I do
CLASS Patient inherit Person
.... some stuff
As you see, I think to describe the 'logic' in a - let's say - dental
practice.
Well, to make the raw description: the patient steps to the desk to
put in/change his data. The desk-nurse is 'creating' an instance of
the Patient -> oMeier
After a while in the waitingroom Meier is asked to climb on the chair
of pain. Well, the desk-nurse 'passed' the instance oMeier to the
desktop beneath the chair to the doctor. .............. and so on.
How to realize (structural) something like that in VO ??
I have all the time in background oMeier, the window-instances are
coming and going: the input-window for the desk-nurse, the
details-window for the doctor (with all the x-rays belonging to oMeier
and so on).
You got me ?? I feel like we are a little bit to much 'window-driven',
where windows should only be the tool for GUI.
Besides, couldn't it be, that 'PO'-written programs like that could
force our customers to be by theirselves a little bit more 'PO' in the
job they do ?? (Haven't we forced them with windows programs to _be_ a
little bit more OO, even if they don't know how that spells ??)
Well, to repeat the question:
having as class-'description' like the following, how to make a
program out of resp. around the description ???
HTH
Hanjo
CLASS person
EXPORT apDaten AS ARRAY
PROTECT opServer AS dbServer
PROTECT aFieldnames AS ARRAY
METHOD init(oServer,apDaten,aFieldnames) CLASS person
IF !IsNil(oServer)
SELF:opServer := oServer
ENDIF
IF IsNil(afieldnames)
//wenn keine Feldnamen übergeben wurden, Standard
setzen
ENDIF
METHOD getdaten(oServer) CLASS person
LOCAL oPerson AS person
//Personendaten entweder von einem Server oder einer GUI einlesen
RETURN oPerson
METHOD such(cbBedingung) CLASS person
LOCAL oPerson AS person
//eine Person suchen
RETURN oPerson
METHOD gibaus(oPerson) CLASS person
//Ausgabe auf Window
RETURN NIL
METHOD nimmauf() CLASS person
//Eingabe auf Window
RETURN NIL
Stephane
I'm in the process of doing just that.
What I have upto know isn't much:
Class xServer
My own version of DBserver which uses the DBxxx functions.
Class DataSet.
A class which takes care of all opening, closing and indexing of xServer
classes.
I never retouch this class. All the data it needs is in a DataDictionary
(dbf).
I've been using these two classes for quite a while now and I'm very pleased
with them.
Now the hard part.
Class Client
To make this a black box isn't easy. The key may change from one app to the
other.
The number of fields may also change as well as their purpose.
Same goes for any other "bussiness" object as invoices, orders, suppliers...
Stephane
Richard Press
My variation is a class called Employee{}. Upon instantiation, it finds the
files it needs and opens them. It has its own Seek() method which can
distinguish between Social Security Number, Employee Number or alpha lookup
depending on what the user enters. Upon successful seek, it gathers from
the various tables in its possession all the information about the employee
such as address, phone number, work location, job number, job title, union
affiliation, date of birth, date of hire, and so on. It can display its own
results or send them to a form, copy them to the clipboard, or print them
according to what is desired or appropriate. In my particular situation all
data is accessed from the company's master payroll files, so there is no
need for me to write methods to add names or other information, nor to edit,
but such functionality could and should be included in the Class as
required.
HTH
-=RAP=-
"Hans-Joachim Grüßner" <hanjo.g...@t-online.de> wrote in message
news:384218c9....@news.btx.dtag.de...
Meinhard@newyorker.de Meinhard Schnoor-Matriciani
well to be honest, I had no clue of what you are talking about after
reading your original message. With this one I am beginning to see what
you're thinking about. And yes, you're absolutely right ! Although I
wouldn't elaborate on the point that we are 'window driven' ( maybe
Windows, but ... <G> ). The problem here is of other nature ( at least
from my point of view ), our understanding of databases is too much
'record oriented' even in the SQL world ( a table is nothing more than
a set of records ). A record is a 2 dimensional datastructure and can
be perfectly presented in a two dimensional container like a datawindow
or a databrowser.
What you experience here is the typical paradigm break when you're
doing OO ( OOA,OOD,OOP and then ? ) when it comes to the datastorage.
And it's a pain. We came across this border long time ago and we were
looking to an answer to this question. The first one was to use an
object oriented database and the second one was to find a way how to
present objects. The way of presenting an object is a relative simple
task from a generic point of view, let the object itself how to present
itself. With this idea in mind it's relatively easy to implement a
generic way how to present an object. To get a picture of this idea,
take a look into the database administrator of the Jasmine Studio ( or
Jasmine Modeler in Jasmine ii ). And make sure that you don't miss our
regular user group meetings, because we're ( HaJo and myself ) and
going to demonstrate how we solved this.
I have to find an end, I don't want to compete with Geoff <bg> ( Hi
Geoff, I appreciate your engagement !)
Meinhard Schnoor-Matriciani
[VOCA GmbH Germany, the makers of the SDT magazine and the DevCon
Germany]
Stephane
Could you tae that class and put it in ANY app _without_ changing a single
line of code to it ?
IOW, could you make a DLL out of it and send it to me and I could just hook
up to it and away I'd be ?
Stephane
Richard Press <r...@usa.take-this-out.net> wrote in message
news:81ubsg$ntm$1...@news.laserlink.net...
Alexander Fry
undergo the next revolution, there may be no windows, but there will still
be objects.
The situation you describe or model here does not need windows, you could
write it to process against the terminal (AKA dos) window if you wanted, or
take out the visual interface all together and have a sound based interface.
The interface should be an aside issue. Any good OO program should be able
to handle a variety of input devices.
To this point, does your person class need to have a window at all?
In OO there are two phrases you need to keep in the back of your head at all
times, "HAS A" and "IS A"
A person is not a window but yes a person can HAVE A window, but why ?
Why not make a Person Class, and indeed all the other objects that the
person will interact with, i.e. chair and drill, and get there interaction
right. Then you can hook into whatever interface you need.
You could have a billing window, which the person details gets passed to
rather than them having their own window !
Hans-Joachim Grüßner wrote in message
<38425d6d....@news.btx.dtag.de>...
Geoff Schaller
I appreciate your engagement !)<<
<BG> Please, all engagement is worthwhile!
For my part, your contribution is great to see. You have much greater
experience with VO than I and a debate/discussion is not really that unless
a number of people jump in. If the jumper's are senior, all the better! I
hope we can entice you out to DevCon Australia next year because these
topics will be central to the theme of our conference.
Geoff
George L. Smith
seperate the data access routines from the datapresentation routines.
What I mean is that the access to the underlying data should only be allowed
through your person object. The window should deal only with the person
object, and the person object should deal with the database implementation.
This allows that the database implementation can be changed, the
presentation layer can be changed, or the middle layer can be distributed
through the use of COM/DCOM or Corba (if your environment supports it).
If you need a list of persons which match a query, then set up an object
that can return a collection of person objects, or sufficient data in a
collection to allow the object to be instanciated once selected from the
collection.
The point is that in todays applications, placing a middle tier in the
application allows flexibility and robustness for the future of the
application.
George L. Smith
>Richard,
>
>Could you tae that class and put it in ANY app _without_ changing a single
>line of code to it ?
>IOW, could you make a DLL out of it and send it to me and I could just hook
>up to it and away I'd be ?
How about, if I just sent you a reg file and allowed you to use my Person
object on my server accross the internet and charged you for it's use. If
the charge was reasonable based on the transaction level, wouldn't that be
an acceptable alternative? It might give you access to all of the persons on
my server, or, it could limit you to only those persons which you add to the
list.
The benefits here could be that a change of address for a given person would
automatically be propagated to all subscribers of the list. A marriage
(resulting in a name change) could be updated only once, and again propagate
throughout the user network. If you could access something like the combined
telephone books of the world , wouldn't that be worth something to your
application?
Now, don't get me wrong. I'm not offering that kind of service. It's just an
example of what can be done through DCOM and the internet.
Maybe a subscription service...... I don't know....
As a reply to Richard as well. Though it works fine for your particular
application, you might think about a slightly different approach. The way
I've approached your situation is a little more granular. The following is
the first steps in my hierarchy.
Addresses - Object_ID, Street1, Street2, City, State/Province, Country,
PostalCode, AreaCode, MainPhone
Persons - Object_ID, FirstName, Middle Initial, LastName, NickName, Gender,
Birthdate, HomeAddress (Address Object_ID Reference "AddrOR")
Accounts - Object_ID, Name, BilltoDefault (AddrOR ), ShiptoDefault (AddrOR),
Contact (Person Object_ID Reference "POR" ), CreditLimit
Contacts - Account ( Account Object_ID Reference "ActOR") , Contact (POR),
Position, Email, Phone, Fax, Cellular, MailStop, WorkAddress(AddrOR)
Etcetera.
This allows that the same person can have two or more positions but still
only have one home address information. The point here is similar to the
point in the thread. The person is the fundamental base object. Though, in
this case I don't think that inheriting the Client (or in my case the
contact ) is the appropriate method. In this case I think containment is the
more appropriate method to handle the client./employee/contact - person
relationship.
Just my random thoughts on the subject... <G>.
George
Hans-Joachim Grüßner
I would be very interested, how you hook your empoyee-class in the
app. Thats the problem I see in being really OO. Perhaps I'm
shortsighted here because my lack in windows-experience.
I know, that the data-part of the problem is very good to do with
jasmine. I'll try it as soon as possible. (Well, the only problem is:
I need a new machine for that, you can't do Jasmine with an 133 Mhz
Pentium.... But a month or 2, then I have it I hope).
The problem to me seems really to hook it in an VO-app (I'm quit
shure, it's not easier with C++, delphi, ........).
I'm a little bit suspicious, all thouse development-systems are made
with the record-thinking (as Meinhard names it).
Look: you have a Shellwindow. Perhaps you create the first (empy)
instance of employee in the Start() Method. Perhaps you have an global
array containing your employee-objects (or in jasmine as
class-variable). But now you want to put in a new employee.
The VO-Way I learned until today: you make a window, wherein you do
the stuff. But now the employee:class has it's own input-window.
Yes, you can write a wrapper-method, which creates an new empty
employee-instance and send a oEmployee:input() to it.
But in my sight of OO it should be the oEmployee:input() or oEmployee
:= Employee:new() from the shell or shell-menue directly.
Anyway, I'm very interested in your 'hooking in'.
Greeting from the baltic
Hanjo
--
Hans-Joachim Grüßner
I suppose, what you name 'record oriented', is a very important part
of the backbrain-thinking of developers for development tools.
But, you are perfectly right, here something like Jasmine could be the
solution. (And I try it as soon as possible I can buy a new machine).
But there is an other part, what I call 'window(s)-driven' <g>. And
that means to hook in such an object like person or employee in your
app. Please refer to the follow-up I wrote do Richard Press right
down. (I'm very lazy to write things twice).
Thouse apps we have to do, use to have IMHO always a sort of 'central
Object'. Lets be Customer, Employee, generally Person, or e.g.
spare-parts (if there is an app for steering a galvanic fabrication),
container (an app for transport-logistics), and so on.
I think, it would be an interesting world to develop software 'around'
those central-objects making a class of it, which steers the whole app
(or the largest part of it...).
The data-part is quite important for that, but - as you poited out -
Jasmine is the solution.
In the app-part, the 'hooking-in' I see until now only work-arounds.
Because such central-classes are no windows, but only represented of
them. (Mostly more than one per class).
Well, some thoughts need a time to flow... like old cheese <bg>.
Greetings to south-germany :-))
Hanjo
---
SergioC
I think you (re)introduced the concept behind the wall. I think this is the
kind of thinking that many of us allows himselves as often as day to day
pressure permits.
I am in the proccess of building my first VO-Jasmine app and I just
received (10 minutes ago) the Beta if Jasmine ii. I can tell you that much,
very much of your concerns about "persistents objects" is "solved" in
Jasmine. You have to upgrade your PC and put hands on Jasmine. You will
have a new start point for your thinkings. With Vo and Jasmine you have the
best (sorry I am excited) of the tools: great and true OOP for Windows &
volatile objects from VO and true OO for persistent objects with the
advantage of server side methods.
Of course, the way you use the tools will determine the degree of
flexibility and acceptance your app will have.
greetings from Peru
Sergio
Mark W. Schumann
Hans-Joachim Grüßner <hanjo.g...@t-online.de> wrote:
>I suppose, what you name 'record oriented', is a very important part
>of the backbrain-thinking of developers for development tools.
>
>But, you are perfectly right, here something like Jasmine could be the
>solution. (And I try it as soon as possible I can buy a new machine).
Right. The idea of Jasmine is that the WHOLE WORLD is objects. There
are no records or other "flat" structures. Every database is just a
collection of objects that have relationships, just as the memory in
your program is not viewed as a series of addresses but as a complex
relationship of objects and variables.
The "object database" ideal is interesting but probably isn't quite as
fast at traditional operations as we're used to. I'd like to try it
myself... as soon as I buy the hardware!
>But there is an other part, what I call 'window(s)-driven' <g>. And
>that means to hook in such an object like person or employee in your
>app. Please refer to the follow-up I wrote do Richard Press right
>down. (I'm very lazy to write things twice).
I will summarize my thoughts on this very lazily. Try getting a copy
of this book:
DESIGN PATTERNS: elements of reusable object-oriented software;
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides;
Addison-Wesley, 1995.
Now that most professional programmers understand classes, inheritance,
polymorphism, and encapsulation, we still lack a vocabulary for
describing how classes interact and relate to each other within a
complex system. But again and again we find similar problems that
keep calling out for similarly-structured solutions, at a little
higher level of abstraction than classes themselves provide. THOSE
are Patterns.
Stephen Quinn
I can also recommend the book.
I read about 2/3 of it while laid up in hospital recently, found out that
I'd been using some of the concepts/patterns described therein without
knowing it or that they even had a name.
I decided to purchase it after Mark Miller recommended it, for those of you
who don't know who Mark is, he is the author of CodeRush - prossibly the
best Delphi addin tool available.
--
HTH
Steve Quinn
Life is sexually transmitted.
Never take life seriously. Nobody gets out alive, anyway.
Fire hydrants have H2O on the inside and K9P on the outside.
Hans-Joachim Grüßner
>of this book:
>
> DESIGN PATTERNS: elements of reusable object-oriented software;
> Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides;
> Addison-Wesley, 1995.
Hello,
you guys are going to ruin me, aren't you ?? <g> Are you all
shareholders of amazon ?
Anyway, I ordered the book as well as I ordered before the
"Windows-bible" by charles Petzold.
There I found: "When programming for Windows, you're really engaged in
a type of object-oriented programming. This is most evident in the
object you'll be working with most in Windows, the object that gives
Windows it's name, the object that will soon seem to take on
anthropomorphic characteristics, the object that might even show up in
your dreams: the object known as the 'window.' "
Well, thats a part of what I'm writing against. Of course not the
window-object itself, it's important, no question.
But to consider it as THE OBJECT might make some mist before the eyes
to see really OO. To go on develop it.
But I feel, I get very much agreement in this point.
Let's go on thinking in that way!
Greetings from the stormy baltic
Hanjo