Tweet
More Thoughts On Object Oriented Programming
I would like to take a shot at justifying Object Oriented Programming. But before I do I’d like to state beforhand that I’ve personally had a difficult time learning it and am in no way an expert at it. Also, as many here have stated at different times its no panacea to every possible programming challenge. Its just a useful and important tool. My reason for thinking that it is something important to learn is highly philosophical and is based on a linguistic principal first advocated by a very gifted linguist Edward Sapir. The idea is that the symbols we use to think and the meanings we attach to them largely if not completely condition the nature of what we are able to conceptualize with those symbols. In linguistics this is know as the Sapir-Whorf Hypothesis, and here is a link to further information on it…
Here is the first sentence or two from that article…
"The hypothesis postulates that a particular language's nature influences the habitual thought of its speakers: that different language patterns yield different patterns of thought. This idea challenges the possibility of perfectly representing the world with language, because it implies that the mechanisms of any language condition the thoughts of its speaker community."
It is my belief that this is largely true, and is the reason individuals from different cultures and times can have such widely varying world views and social philosophies. I also believe this idea is applicable in the realm of programming languages. I don’t believe I’ve ever seen a better description of this issue as it relates to computer languages as that from Bruce Eckel in his book “Thinking In C++”, second edition, Volume 1. This book is downloadable and free from his website at…
In Mr. Eckel’s words…
The genesis of the computer revolution was in a machine. The genesis of our programming languages thus tends to look like that machine.
But computers are not so much machines as they are mind amplification tools (“bicycles for the mind,” as Steve Jobs is fond of saying) and a different kind of expressive medium. As a result, the tools are beginning to look less like machines and more like parts of our minds, and also like other expressive mediums such as writing, painting, sculpture, animation, and filmmaking. Object-oriented programming is part of this movement toward using the computer as an expressive medium……
The progress of abstraction
All programming languages provide abstractions. It can be argued that the complexity of the problems you’re able to solve is directly related to the kind and quality of abstraction. By “kind” I mean, “What is it that you are abstracting?” Assembly language is a small abstraction of the underlying machine. Many so-called “imperative” languages that followed (such as Fortran, BASIC, and C) were abstractions of assembly language. These languages are big improvements over assembly language, but their primary abstraction still requires you to think in terms of the structure of the computer rather than the structure of the problem you are trying to solve. The programmer must establish the association between the machine model (in the “solution space,” which is the place where you’re modeling that problem, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” which is the place where the problem exists). The effort required to perform this mapping, and the fact that it is extrinsic to the programming language, produces programs that are difficult to write and expensive to maintain, and as a side effect created the entire “programming methods” industry.
The alternative to modeling the machine is to model the problem you’re trying to solve. Early languages such as LISP and APL chose particular views of the world (“All problems are ultimately lists” or “All problems are algorithmic”). PROLOG casts all problems into chains of decisions. Languages have been created for constraint-based programming and for programming exclusively by manipulating graphical symbols. (The latter proved to be too restrictive.) Each of these approaches is a good solution to the particular class of problem they’re designed to solve, but when you step outside of that domain they become awkward.
The object-oriented approach goes a step farther by providing tools for the programmer to represent elements in the problem space. This representation is general enough that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as “objects.” (Of course, you will also need other objects that don’t have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you read the code describing the solution, you’re reading words that also express the problem. This is a more flexible and powerful language abstraction than what we’ve had before. Thus, OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run. There’s still a connection back to the computer, though. Each object looks quite a bit like a little computer; it has a state, and it has operations that you can ask it to perform. However, this doesn’t seem like such a bad analogy to objects in the real world; they all have characteristics and behaviors. …
Bruce Eckel "Thinking In C++"
To provide a concrete example to illustrate how the nature of the programming language affects our thought processes allow me to describe a basic forestry issue, and that is obtaining the expected board foot volume yield estimate from a standing tree. Over the years in forestry various workers have devised countless methodologies for making this estimate, but the one we’ll use is a formula developed by Dr. Harry Wiant while he was Professor of Forestry at West Virginia University. Below is a pure procedural approach using the Console Compiler.
The nature of the problem is that to estimate the expected board foot volume yield of a tree (the amount of lumber that sawing it would produce), you need to know the diameter of the tree in inches at 4.5 feet above the ground as measured from the high side, and the merchantable height of the tree in feet. Merchantable height of sawtimber is usually to a eight or ten inch diameter top. Also, an estimate of the taper of the tree is necessary. Without going into all the details these are ratios usually expressed as intergers ranging from 75 to 85 – the higher the number the less taper. These ratios are know as a ‘Form Class’.
Below is a procedural approach to the problem. First one would create a TYPE to contain the diameter, height, and form class. Then one would create a function where one would implement some volume determination method involving a formula or whatever. In the below example you can see Dr. Wiant’s rather complex result from his regression analysis. The function should take a parameter of the TYPE created to contain the tree’s diameter, height, and form class. The function should crunch the numbers contained in the TYPE parameter and return the tree’s expected board foot volume estimate.
As can be seen in the above procedural program, a variable of TYPE Bole was created in PBMain to hold the tree’s diameter, height, and taper data parameters. The function BoardFootVolume() can be passed a Bole argument containing the tree’s data and it will ‘crunch’ this data with its code and return a volume result to PBMain().
Below is an OOP implementation of the above program using PowerBASIC 5.0 and objects.
It certainly is longer but a description of how it works is much simpler. All you do is create an object of Class Tree, let it know the diameter, height, and taper of the tree, and request of the Tree its volume. Note the subtle change in emphasis – before we were passing a piece of data to an external function whose only relation to the tree bole in PBMain() was through a common function parameter, and now we have a tree of class “Tree” and simply ask it for its volume. It’s a subtle change in emphasis but it makes it easier for us to think about tree objects from an algorithmic perspective. And if we can think about it clearer and more easily, it will be easier for us to conceptualize various algorithims that may be used in our programs dealing with trees. In your programming life have you not ever run into a situation where you were struggling with a few variables to get an algorithim working, and just by renaming a variable or creating an extra intermediate variable allowed yourself to think clearer about what you were struggling with and thereby effect an easy and maintainable solution? That’s all we’re talking about here in terms of the benefits of object oriented programming – different symbols defined in such a way that we are better able to make the mental mapping from the ‘problem space’ to the ‘solution space’ of Mr. Eckel’s terminology.
One more quick issue I’d like to discuss. Up to now the big dichotomy within the PowerBASIC user base is that between DDT verses SDK. It strikes me that OOP in PowerBASIC leaves the avenue open for OOP implementations within these two different camps. I’d personally like to experiment a bit with encapsulating such Api ‘objects’ such as textboxes, labels, combo/listboxes into OOP classes. That could prove really interesting. Having implemented something like that, and given the skill & enterprise of the different GUI Designer programmers in the PowerBASIC Community, it wouldn’t be too long until one would have something like Visual Basic but with much more speed and a fraction of the bloat. I think it’s a good time to be a PowerBASIC programmer!
I would like to take a shot at justifying Object Oriented Programming. But before I do I’d like to state beforhand that I’ve personally had a difficult time learning it and am in no way an expert at it. Also, as many here have stated at different times its no panacea to every possible programming challenge. Its just a useful and important tool. My reason for thinking that it is something important to learn is highly philosophical and is based on a linguistic principal first advocated by a very gifted linguist Edward Sapir. The idea is that the symbols we use to think and the meanings we attach to them largely if not completely condition the nature of what we are able to conceptualize with those symbols. In linguistics this is know as the Sapir-Whorf Hypothesis, and here is a link to further information on it…
Here is the first sentence or two from that article…
"The hypothesis postulates that a particular language's nature influences the habitual thought of its speakers: that different language patterns yield different patterns of thought. This idea challenges the possibility of perfectly representing the world with language, because it implies that the mechanisms of any language condition the thoughts of its speaker community."
It is my belief that this is largely true, and is the reason individuals from different cultures and times can have such widely varying world views and social philosophies. I also believe this idea is applicable in the realm of programming languages. I don’t believe I’ve ever seen a better description of this issue as it relates to computer languages as that from Bruce Eckel in his book “Thinking In C++”, second edition, Volume 1. This book is downloadable and free from his website at…
In Mr. Eckel’s words…
The genesis of the computer revolution was in a machine. The genesis of our programming languages thus tends to look like that machine.
But computers are not so much machines as they are mind amplification tools (“bicycles for the mind,” as Steve Jobs is fond of saying) and a different kind of expressive medium. As a result, the tools are beginning to look less like machines and more like parts of our minds, and also like other expressive mediums such as writing, painting, sculpture, animation, and filmmaking. Object-oriented programming is part of this movement toward using the computer as an expressive medium……
The progress of abstraction
All programming languages provide abstractions. It can be argued that the complexity of the problems you’re able to solve is directly related to the kind and quality of abstraction. By “kind” I mean, “What is it that you are abstracting?” Assembly language is a small abstraction of the underlying machine. Many so-called “imperative” languages that followed (such as Fortran, BASIC, and C) were abstractions of assembly language. These languages are big improvements over assembly language, but their primary abstraction still requires you to think in terms of the structure of the computer rather than the structure of the problem you are trying to solve. The programmer must establish the association between the machine model (in the “solution space,” which is the place where you’re modeling that problem, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” which is the place where the problem exists). The effort required to perform this mapping, and the fact that it is extrinsic to the programming language, produces programs that are difficult to write and expensive to maintain, and as a side effect created the entire “programming methods” industry.
The alternative to modeling the machine is to model the problem you’re trying to solve. Early languages such as LISP and APL chose particular views of the world (“All problems are ultimately lists” or “All problems are algorithmic”). PROLOG casts all problems into chains of decisions. Languages have been created for constraint-based programming and for programming exclusively by manipulating graphical symbols. (The latter proved to be too restrictive.) Each of these approaches is a good solution to the particular class of problem they’re designed to solve, but when you step outside of that domain they become awkward.
The object-oriented approach goes a step farther by providing tools for the programmer to represent elements in the problem space. This representation is general enough that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as “objects.” (Of course, you will also need other objects that don’t have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you read the code describing the solution, you’re reading words that also express the problem. This is a more flexible and powerful language abstraction than what we’ve had before. Thus, OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run. There’s still a connection back to the computer, though. Each object looks quite a bit like a little computer; it has a state, and it has operations that you can ask it to perform. However, this doesn’t seem like such a bad analogy to objects in the real world; they all have characteristics and behaviors. …
Bruce Eckel "Thinking In C++"
To provide a concrete example to illustrate how the nature of the programming language affects our thought processes allow me to describe a basic forestry issue, and that is obtaining the expected board foot volume yield estimate from a standing tree. Over the years in forestry various workers have devised countless methodologies for making this estimate, but the one we’ll use is a formula developed by Dr. Harry Wiant while he was Professor of Forestry at West Virginia University. Below is a pure procedural approach using the Console Compiler.
The nature of the problem is that to estimate the expected board foot volume yield of a tree (the amount of lumber that sawing it would produce), you need to know the diameter of the tree in inches at 4.5 feet above the ground as measured from the high side, and the merchantable height of the tree in feet. Merchantable height of sawtimber is usually to a eight or ten inch diameter top. Also, an estimate of the taper of the tree is necessary. Without going into all the details these are ratios usually expressed as intergers ranging from 75 to 85 – the higher the number the less taper. These ratios are know as a ‘Form Class’.
Below is a procedural approach to the problem. First one would create a TYPE to contain the diameter, height, and form class. Then one would create a function where one would implement some volume determination method involving a formula or whatever. In the below example you can see Dr. Wiant’s rather complex result from his regression analysis. The function should take a parameter of the TYPE created to contain the tree’s diameter, height, and form class. The function should crunch the numbers contained in the TYPE parameter and return the tree’s expected board foot volume estimate.
Code:
#Compile Exe
#Dim All
Type Bole
Dbh As Single
Height As Single
FormClass As Long
End Type
Function BoardFootVolume(Tree As Bole) As Single
BoardFootVolume = _
( _
(1.52968 * (Tree.Height / 16) ^ 2 + 9.58615 * (Tree.Height / 16) - 13.35212) + _
(1.7962 - 0.27465 * (Tree.Height / 16) ^ 2 - 2.59995 * (Tree.Height / 16)) * Tree.Dbh + _
(0.04482 - 0.00961 * (Tree.Height / 16) ^ 2 + 0.45997 * (Tree.Height / 16)) * Tree.Dbh ^ 2 _
) * _
((Tree.FormClass - 78) * 0.03 + 1)
End Function
Function PBMain() As Long
Local t As Bole
t.Dbh=16.0
t.Height=32.0
t.FormClass=78
Print "A 16 In. Tree With A Sawlog Ht of 32 ft Contains " BoardFootVolume(t) " Board Feet of Lumber."
Waitkey$
PBMain=0
End Function
Below is an OOP implementation of the above program using PowerBASIC 5.0 and objects.
Code:
#Compile Exe
#Dim All
Class Tree
Instance m_Dbh As Single 'Diameter @ Breast Height; standardized as US 4.5 ft.
Instance m_Height As Single 'In Eastern US in Units of 16 ft. saw logs - 32 ft. in Western US.
Instance m_FormClass As Long 'Integer representing a tree taper factor. Ranges from 75 to 85.
Interface ITree : Inherit IUnknown
Property Get Dbh() As Single
Property=m_Dbh
End Property
Property Set Dbh(Byval sngDbh As Single)
m_Dbh=sngDbh
End Property
Property Get Height() As Single
Property=m_Height
End Property
Property Set Height(Byval sngHeight As Single)
m_Height=sngHeight
End Property
Property Get FormClass() As Long
Property=m_FormClass
End Property
Property Set FormClass(Byval iFormClass As Long)
m_FormClass=iFormClass
End Property
Method BoardFootVolume() As Single
Method= _
( _
(1.52968 * (m_Height / 16) ^ 2 + 9.58615 * (m_Height / 16) - 13.35212) + _
(1.7962 - 0.27465 * (m_Height / 16) ^ 2 - 2.59995 * (m_Height / 16)) * m_Dbh + _
(0.04482 - 0.00961 * (m_Height / 16) ^ 2 + 0.45997 * (m_Height / 16)) * m_Dbh ^ 2 _
) * _
((m_FormClass - 78) * 0.03 + 1)
End Method
End Interface
End Class
Function PBMain() As Long
Local t As ITree
Let t = Class "Tree"
t.Dbh=16.0
t.Height=32.0
t.FormClass=78
Print "A 16 Inch Two Log Tree of Form Class 78 Contains " t.BoardFootVolume " Board Feet of Lumber."
Waitkey$
PBMain=0
End Function
One more quick issue I’d like to discuss. Up to now the big dichotomy within the PowerBASIC user base is that between DDT verses SDK. It strikes me that OOP in PowerBASIC leaves the avenue open for OOP implementations within these two different camps. I’d personally like to experiment a bit with encapsulating such Api ‘objects’ such as textboxes, labels, combo/listboxes into OOP classes. That could prove really interesting. Having implemented something like that, and given the skill & enterprise of the different GUI Designer programmers in the PowerBASIC Community, it wouldn’t be too long until one would have something like Visual Basic but with much more speed and a fraction of the bloat. I think it’s a good time to be a PowerBASIC programmer!
Comment