Hello Tigers,
As to any programming concept, it should be balanced using solid
theory, as well as project-oriented pragmatism. So in short, the risks
and benefits of the Object Oriented Paradigm in programming are just
that; it's a good solid theory, while it could get in the way of
project-oriented pragmatism in smaller software projects.
Time-critical, well-defined and clearly limited projects can suffer
from overtly theoretical approaches. But then again, it's rarely the
case that a programmer or management sees those limits, and more often
than not they will extend the original scope. In that case, it is good
to have started a solid basis, because people don't like to just throw
away older work; quite the opposite, they tend to copy existing
concepts found in a project, and at times bad code ends up in
otherwise good systems, which now can begin to "rot" from inside.
Before we go to the risks and benefits of OOP, here is an overview of
what Object Oriented Programming actually means:
What is Object-Oriented Software?
http://www.softwaredesign.com/objects.html
Object-Oriented Programming Concepts
http://java.sun.com/docs/books/tutorial/java/concepts/
What is Object-Oriented Programming?
http://www.wi2.uni-erlangen.de/sw/smalltalk/oop.html
Now, the specific risks of OOP, Object Oriented Programming, are:
- it's harder to understand if you're a programmer who never used it
- concentrating too much on the theoretical approach can shift the
focus away from real problems at hand
- it can be misused, like any programming approach (e.g. too complex
relationships, overuse of multiple-inheritance)
The benefits of OOP are:
- data encapsulation using the "black box" of an object
- restricted name-spaces
- often: more easily understood, structured code
What you need to keep in mind is:
- the lack of OOP expressed in programming language syntax does not
mean the actual code written is not object oriented
- any concept can be misused, and languages supporting object oriented
features can be used to write very linear, procedural programs
The last point brings us to why some would consider C++ violating the
nature of object oriented languages: C++ is rooted in C. While it
brings Object Oriented Programming to the C language, it does not get
rid of everything that might be considered historical these days --
and while that allows for very speed-optimized programs in some cases,
it also means there are some additional pitfalls when it comes to OOP.
You can move around them, or fall right in.
Same is true with Visual Basic, with one major exception -- as opposed
to C++, many do not even call it OOP. Up until version 6 of VB, there
is a lack of certain concepts available in "real" Object Oriented
languages. Most prominently, this includes inheritance; "an employee
is a kind of person, so my employee code can inherit and therefore
elegantly reuse my person code".
However in the newest release of VB (VB.NET, or VB7), these OOP
concepts are available.
It needs to be emphasized here that OOP stays a choice of programming
style for an individual programmer; there is simply no programming
language available that will force or teach one to be a good
programmer, or that will lead your way to OOP.
I hope this helps!
Search terms:
"what is oop"
vb oop
"best oop"
"c/c++ vs java"
"c++ vs oop" |
Clarification of Answer by
j_philipp-ga
on
30 Jul 2002 15:52 PDT
Hello Tigers,
In VB, you can visually design forms, by putting form elements on
them. This could be a button to click on. Such button can be called an
object, since it has methods and properties. E.g. a button property is
the text on the button:
myButton.caption = "Click Me"
And a button method is:
myButton.setFocus
(If you call this method "setFocus", the button will receive the
focus.)
Now, what does event-driven mean here?
If you click on the button, an event is raised:
Private Sub myButton_Click()
MsgBox "You clicked the button"
End Sub
This event lets you execute further code, like display a message-box
reading "You clicked the button". The function above is therefore
called the "event-handler", because it sits there silently until the
user does something (or another command raises the event). Events are
not non-OOP; rather, they can go hand in hand with an object oriented
approach.
But can you also implement your own classes in VB, to instantiate new
objects?
You can, but as I pointed out, without inheritance. This can be
sufficient in many cases:
Dim myOutput As myOutputClass
' instantiate object using class code below
Set myOutput = New myOutputClass
myOutput.text = "Hello World"
myOutput.outputText
' class code (separate file)
Private m_text As String
Public Property Let text(ByVal text As String)
m_text = text
End Property
Public Sub outputText()
MsgBox m_text
End Sub
The actual use of this sample class is rather small; typically, a
class also has hidden methods (functions) that do some more of the
"behind the scenes" work.
But now compare the following two approaches to see the limitations:
Object composition:
- "has a" relationship: "A bike has a saddle"
Class inheritance:
- "is a" relationship: "A bike is a vehicle"
In other words, a saddle would not need to be able to do everything a
bike can; while a bike should be able to do everything a vehicle can.
In programming, the latter case is implemented using class
inheritance. This means reusing existing code to avoid redundancy, and
keeping the system flexible and open to easily implemented future
changes.
Now to connect this back to our button example, in Visual Basic up to
version 6, we would reach the limit of easily implementing a very
special button that provides much of the old functionality, but also
some of our own new functionality. We can not extend, or override
existing behavior; we can only use object composition (wrapping the
button with our own class) to simulate this, which is not quite as
elegant.
The only good thing about this limitation is that it avoids some
occasions on which a programmer might otherwise use class inheritance
on a "has a" relationship, which would make the code unnecessarily
complex to maintain.
But, like I mentioned, the newest version of VB implements
inheritance, and therefore becomes a "real" OOP language.
Hope this helps!
|
