: I've been spending alot of time learning vb.net the past 6 months (for
: regular winform apps. Been somewhat experienced in asp.net for a few
: years)
:
: But my style has been using Procedural techniques, rather than OOP.
: Lately i've read more and more how OOP is the way to go. So i'm
: trying to learn it, and boy is it difficult if you've not worked
: that way much before!
:
: I ran into this web site:
http://www.geocities.com/tablizer/oopbad.htm
: It swears that OOP is over-hyped, and says that Procedural is better.
: It has many arguments against OOP.
:
: Do you pros think the info on that site has eny merrit? Or is the
: author just trying to get some attention?
:
: Thanks,
: John
The short answer to your question is, yes - you would do well to learn
and understand the OO programming model. Whether you choose to use it
will depend on your personal preferences as well as the task at hand.
However, OOP seems to be moving towards becoming the dominant paradigm
in modern languages: C++, Java and .Net are just a few examples that
represent mainstream languages. Even the venerable Javascript scripting
language allows the developer to utilized a limited implementation of
OOP.
I'm a relatively recent convert to the OOP approach (dare I say,
'paradigm') and frankly I think it's great. As a pratical matter
however, I use both approaches. I think a pure OO approach has its
shortcomings. As a result, I tend to think more in terms of a component
model approach rather than a pure object model.
I work for a company that makes extensive use of VB based COM+
components. While not OO proper, the concept of a component model is
very close in my mind. You have code and data encapsulation as well as
limited polymorphism (via implementation). The full OO implementation of
VB.net, C#, etc., makes that approach more robust and flexible (in
particular, I think function overloading is the best thing to come along
since individually wrapped cheese slices). Components, like objects,
allow you to isolate and reuse code in a manner I consider to be much
more flexible than a procedural model. They become black boxes that do a
job and the calling process can, at least in principle, disregard how a
component/object does its magic (although in the real world, that is not
always realisitic).
On the other hand, we have a large legacy of classic ASP web pages which
I help maintain and there the coding is strictly top down. Other than
calling COM+ components to implement business logic and access the data
layer (as well as using the occasional function embedded in the page),
the code is basicly start at line 1 and go until you reach the end, a
redirect, an error or a 'response.end' statement.
Of the two types of coding I do, I much prefer the compartmentalization
of the component model and so find myself very much at home in an OOP
environment. For my own coding outside my work environment, I much
prefer to think and code using a component/object model instead of the
top down approach. I even go so far as to use the limited object
oriented features of javascript on the client whenever it is a practical
alternative.
As for the website you've listed, I found it interesting but not
terribly compelling. I tend to agree with others that the arguments are
overstated.
"Procedural" programming techniques are themselves the result of an
evolutionary, and sometimes revolutionary, progression. At one time,
procedural languges were line number based, riddled with goto and
gosub/return statements, lacked variable typing and everything was
global (etc.). The introduction of a structured model changed all that:
variables and processes were given scope, variables could be typed
(double, integer, string, etc.); conditional blocks and loops were
easier to construct; and the program flow was more intuitive and self
documenting (e.g.: the statement 'Call OutputLogFile(Path, Data)' is
much better than '1365 gosub 1400' - we know what the call is for and
what variables are involved, etc.).
Still, this approach has its limits: core data for process A is visible
and can be changed by process B; everything you need in order to make
the program run has to be included in the program itself (resulting in
duplicated code and creating major maintenanance headaches); function
calls are not sufficiently flexible to allow one to implement similar
functionality with different input types; etc., etc.
OO attempts to address these concerns. All in all, OO is a major
improvement over a strictly top down, procedural approach which is
reflected by the fact that the IT community has largely embraced it.
Developing OO languages and using them represent a huge financial
commitment on the part of companies like MS; .Net (as Java was before
it) was a major effort to bring about. Companies that use the technology
have to make significant outlays of capital in order to make use of the
new technology. The fact that the business community is making this
switch (slowly perhaps, but nonetheless) reflects the value that OO
offers.
Ralf
--
