[AccessD] OOP vs OBP

[John Colby]

Arthur Fuller via <https://support.google.com/mail/answer/1311182?hl=en>
databaseadvisors.com
8:26 AM (1 hour ago)
to Access
Without question you are one of the most skilled Access developers I have
ever encountered. Also without question is the fact that one can work magic
by wrapping Access classes. My sole objection was one of terminology. I
distinguish OOP from OBP (Object-based programming). Let's use another
example. An ancient language called Clipper introduced objects in V. 5.0,
most notably Tbrowse,  which meant table-browser. I discovered that one
could reduce a Tbrowser to a very tiny area, equivalent to the navigation
buttons onan Access form, and then attach an actual form to this, so the
form refreshed as one navigated using the Tbrowse object. That is not OOP,
it is OBP., for the simple reason that I could not create a class from
scratch, but merely create descendant classes. That is not to say that
descendant classes are not powerful. But it is to say that OBP will not
allow you to create classes from scratch -- say, for example, that I want
to create a slider control.  In Access, this is impossible. That is all
that I mean by distinguishing OOP from OBP. It's not an insult to Access or
its developers, or any virtuoso such as you or Shamil or Jim Dettman (whose
work is astounding). But it is to say that I cannot create a class from
scratch, such as a Slider control. I have to begin with the existing
classes and then wrap them.
A.

I understand and fully admit that Access cannot use inheritance.  However,
the primary tenants of OOP are encapsulation of data and code, and
abstraction - exposing a specific interface to users of the class, hiding
the implementation details of what and how the class does whatever it
does.  OOP is now generally considered to use inheritance, but not always.
The terms OO was used way back when well before inheritance raised it's
head.

Google's Go language is usually considered an OOP language and yet has no
inheritance.  It does have interfaces, as does Access.  Interfaces
basically define what an object will look like, but completely absent any
code or data.  What that allows however is passing of objects, as well as
dimensioning objects that are "of" an interface instead of "of" a specific
type.  So as long as the object being passed or dimensioned implements that
interface it can be used in that context.

Access, internally, is actually OOP complete with inheritance.  However it
has a hard boundary, i.e. we cannot inherit any of the objects that are
Access.

As for me, I don't really care what you call it, what matters is what I can
do with it.  I worked in C# for about 2 years, writing a pretty darned
complex, system to automate SQL Server, exporting and importing data and
doing other stuff, threaded. And never once inherited anything.
Inheritance, while it can be useful, is IMHO highly over rated. In the end
I can't use it in Access so I just move on to what I can do.

So call it whatever you like.  Just don't call it as useless.
-- 
John W. Colby
Colby Consulting