Home > Archive > Software Engineering > August 2004 > Why is OO Popular?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Why is OO Popular?
|
|
| Ian Roberts 2004-04-27, 2:19 am |
| Hi, I was wondering if anyone could tell me why object oriented
approaches to programming are becoming very popular.
Thanks
Ian
| |
| Frank A. Adrian 2004-04-27, 2:19 am |
| On Mon, 26 Apr 2004 08:44:40 -0700, Ian Roberts wrote:
> Hi, I was wondering if anyone could tell me why object oriented
> approaches to programming are becoming very popular.
Well, you're about 10 years too late to ask this question - the real
peak of mind-share happened about 5 years ago, and the early adopters have
moved on to questioning where objects don't work, why this is so, and
what to do about it (look at Aspect Oriented Programming, Functional
Programming, and Pattern Oriented Programming for likely suspects). But,
why are objects popular?
(1) In procedural programming, algorithms and the data they operate on
were specified in different locales. As such, these items could become
desynchronized and a source of errors. Object programming fixed this by
unifying data, procedural, and control information into one self-contained
package - the object - making these types of errors less likely.
(2) In procedural programming, (relatively static) data modeling was often
carried out in isolation from any question as to how (dynamically) the
data was to be used. As such, procedural code was often clunky, trying to
drag data from different sources, willy-nilly. With objects, the data and
code to operate on it are designed (theoretically) in tandem, doing away
with this type of trouble.
(3) In procedural programming, the main trace of the real world through
the system was often in the data representation of a model of the real
world. These models often needed extraneous elements for performance and
processing reasons, and the trace back to the real world was often under-
(or un-) documented. Object oriented programming has the potential to
structure the code more directly to objects in the "real" world.
(4) Inheritance allowed a simple way to decrease code volume by exploiting
commonality in models.
(5) Publicity and hype (don't ever underestimate the power of these two
things).
Is the above simplistic? Yeah. Are the main ideas that drove the
creation of object orientation up there? Yeah. Are there examples of
procedural systems that didn't have these problems? Again, yeah. Are
there object oriented systems that don't solve these problems? Yup! But
in any case, you might as well start answering the question of "Why OO?"
by asking "What are (were) the problems with procedural programming?" and
realize that OO was a proposed solution to these issues.
--
Frank A. Adrian
Blue Roof Associates
fadrian@blueroofassociates.com
http://www.blueroofassociates.com
| |
| Bradley K. Sherman 2004-04-27, 2:19 am |
| In article <85ea541e.0404260744.297b7e88@posting.google.com>,
Ian Roberts <wilvers1@vodafone.net> wrote:
>Hi, I was wondering if anyone could tell me why object oriented
>approaches to programming are becoming very popular.
Let's say you have 3 good programmers 50 mediocre programmers
and 10 horrible programmer. OO means that the horrible programmers
only destroy their own section of the code, and the mediocre
programmers only bloat their own section of the code, usually
the  fruit-salad interface and the horribly slow database
accesses.
The 3 good programmers are then free to write the fast,
small, efficient parts in C or assembler.
So the appeal of OO is that it allows one to encapsulate
the mediocre and bad programmers.
--bks
| |
| Alexei Polkhanov 2004-04-27, 2:19 am |
| On Mon, 26 Apr 2004 08:44:40 -0700, Ian Roberts wrote:
> Hi, I was wondering if anyone could tell me why object oriented
> approaches to programming are becoming very popular.
>
> Thanks
>
> Ian
Want another mistery ? Why Ada became so unpopular programming language ?
Cheers,
---
Alexei Polkhanov
Sr. Consultant/Software Systems Analyst
Tel: (604) 719-2515
E-mail: usenet@monteaureus.com
http://www.monteaureus.com/
| |
| Frank A. Adrian 2004-04-27, 2:19 am |
| On Mon, 26 Apr 2004 20:48:16 -0400, Alexei Polkhanov wrote:
> Why Ada became so unpopular programming language?
It didn't become unpopular, it just never got popular. Why? It didn't do
anything that other modular languages (read Modula, Oberon, etc.) didn't
already do. It was tainted with a "design by comittee" reputation as well
as carrying a DoD stigma (we in the US have a fairly rational belief that
military technology is late adopter technology). At first it had
no really good implementation and that was single sourced, too. Finally,
by the time the modular, procedural Ada language came out, Eiffel and
Object Pascal had already superceded it in language technology.
In short, Ada was too late, too low tech, and too unambitious with
suspicious backing. The real question I have is why do you think it
should have succeeded?
--
Frank A. Adrian
Blue Roof Associates
fadrian@blueroofassociates.com
http://www.blueroofassociates.com
| |
|
| Bradley K. Sherman wrote wrote:
> Let's say you have 3 good programmers 50 mediocre programmers
> and 10 horrible programmer. OO means that the horrible programmers
> only destroy their own section of the code, and the mediocre
> programmers only bloat their own section of the code, usually
> the fruit-salad interface and the horribly slow database
> accesses.
>
> The 3 good programmers are then free to write the fast,
> small, efficient parts in C or assembler.
>
> So the appeal of OO is that it allows one to encapsulate
> the mediocre and bad programmers.
Can I use the term " fruit-salad interface"? It works on many levels...
--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces
| |
| Bradley K. Sherman 2004-04-27, 2:19 am |
| In article <O1kjc.256$0V5.12@newssvr15.news.prodigy.com>,
Phlip <phlip_cpp@yahoo.com> wrote:
>Bradley K. Sherman wrote wrote:
>
>
>Can I use the term " fruit-salad interface"? It works on many levels...
I stole it myself, you're on your own. It dates from the 80's.
--bks
| |
| Bjorn Reese 2004-04-27, 4:57 pm |
| On Mon, 26 Apr 2004 12:51:19 -0700, Frank A. Adrian wrote:
> (5) Publicity and hype (don't ever underestimate the power of these two
> things).
(6) Availability of tools.
--
mail1dotstofanetdotdk
| |
| Andrew Gabb 2004-04-29, 12:04 am |
| See below ...
Frank A. Adrian wrote:
> (1) In procedural programming, algorithms and the data they operate on
> were specified in different locales. As such, these items could become
> desynchronized and a source of errors. Object programming fixed this by
> unifying data, procedural, and control information into one self-contained
> package - the object - making these types of errors less likely.
Also applies to modern procedural programming as well, and has for
10-15 years.
> (2) In procedural programming, (relatively static) data modeling was often
> carried out in isolation from any question as to how (dynamically) the
> data was to be used. As such, procedural code was often clunky, trying to
> drag data from different sources, willy-nilly. With objects, the data and
> code to operate on it are designed (theoretically) in tandem, doing away
> with this type of trouble.
Yes, in the 70s particuarly. Again, you shouldn't compare bad
procedural with good OO. OO doesn't solve this problem, just forces
a data first approach. Normally the data and methods are not defined
in tandem either except for very simple classes.
> (3) In procedural programming, the main trace of the real world through
> the system was often in the data representation of a model of the real
> world. These models often needed extraneous elements for performance and
> processing reasons, and the trace back to the real world was often under-
> (or un-) documented. Object oriented programming has the potential to
> structure the code more directly to objects in the "real" world.
Sometimes, but less often than you'd expect.
> (4) Inheritance allowed a simple way to decrease code volume by exploiting
> commonality in models.
Agreed, leading to better component based software development and
increased reuse.
> (5) Publicity and hype (don't ever underestimate the power of these two
> things).
>
> Is the above simplistic? Yeah. Are the main ideas that drove the
> creation of object orientation up there? Yeah. Are there examples of
> procedural systems that didn't have these problems? Again, yeah. Are
> there object oriented systems that don't solve these problems? Yup! But
> in any case, you might as well start answering the question of "Why OO?"
> by asking "What are (were) the problems with procedural programming?" and
> realize that OO was a proposed solution to these issues.
One of the big reasons for the advance of OO was the GUI and other
graphical and event-driven applications for which OO is
well-matched, and procedural approaches are often ugly and
inefficient. Until these were common, OO was not much more than
academics playing in Smalltalk, and making outlandish claims for OO.
These days, you'd probably find that 99% of new applications are GUI
based on a semi-OO API (even though the actual % of development
effort may be lower).
Andrew
--
Andrew Gabb
email: agabb@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021, fax: +61 8 8269-3280
-----
| |
| Mark Jerde 2004-04-29, 12:04 am |
| Ian Roberts wrote:
> Hi, I was wondering if anyone could tell me why object oriented
> approaches to programming are becoming very popular.
Once you catch on, it's a very natural way to model the real world.
-- Mark
| |
| Steve Jorgensen 2004-04-29, 2:45 am |
| On Thu, 29 Apr 2004 12:11:43 +0930, Andrew Gabb <agabb@tpgi.com.au> wrote:
>See below ...
>
>Frank A. Adrian wrote:
>
>Also applies to modern procedural programming as well, and has for
>10-15 years.
I'm skeptical of this comment, but I'm interested in your answer if I'm wrong.
Perhaps, you're right for some value of "modern", but it sure doesn't seem to
apply to the procedural languages I've been using. What procedural languages
do you consider to be modern, and what metaphors do they employ to solve this
problem as opposed to how OOP solves them?
>
>Yes, in the 70s particuarly. Again, you shouldn't compare bad
>procedural with good OO. OO doesn't solve this problem, just forces
>a data first approach. Normally the data and methods are not defined
>in tandem either except for very simple classes.
You're repeating the ame assertion, but again without examples. In an OOP
program, I can define member variables and member function sof a single class,
and I can keep some member variables private since they apply only to the
implementation, not to the interface. I can so something that sounds like
that with a procedural language, but not if I want multiple instances of the
set of member varibales. For that, I would need to pass around a structure or
defined type which would then be an extra parameter passed to every related
function (unnecessary duplication), and that structure would not be able to
contain data that's hidden from code outside of the implementation.
How would a procedural language solve these problems? If it did, wouldn't
that make it Object Oriented? If not, I think it would have to use some
competing metaphor that would still make it something deserving of its own
term beyond simply, procedural.
>
>Sometimes, but less often than you'd expect.
Again, you can assert all you like, but I haven't seen evidence of what you
are asserting. If you have something concrete to offer on this, please do so.
I'm all ears.
>
>
>Agreed, leading to better component based software development and
>increased reuse.
>
>
>One of the big reasons for the advance of OO was the GUI and other
>graphical and event-driven applications for which OO is
>well-matched, and procedural approaches are often ugly and
>inefficient. Until these were common, OO was not much more than
>academics playing in Smalltalk, and making outlandish claims for OO.
>These days, you'd probably find that 99% of new applications are GUI
>based on a semi-OO API (even though the actual % of development
>effort may be lower).
I disagree. most of the OOP coding I've done recently is not directly
connected to the back-end. It has more to do with the LoD. For instance, I
want the smallest possible bridge between my database and my 3rd party data
download API, so I have a class that manages the database, exposing only the
minimum interface to manipulate what the application actually needs to
manipulate, with implementation details like record IDs, etc., hidden away,
and I can mock that for testing. Likewise, the 3rd party API is only
available on a few heavily used machines, so I need to be able to mock that as
well for testing the rest of the system including the database component.
Could I have done that without OOP? Perhaps, but it would have been much more
work to do that and also engineer out errors up-front, e.g. ensuring that
variables are properly initialized and torn down for each pass. If I did do
it with OOP, the simplest design might have ended up being an event-driven
system, and that's tantamount to implementing a custom OOP in a procedural
language. Why should I reinvent that wheel for every app?
| |
| Alan Gauld 2004-04-29, 7:39 am |
| On Thu, 29 Apr 2004 05:24:40 GMT, Steve Jorgensen
<nospam@nospam.nospam> wrote:
>
> I'm skeptical of this comment, but I'm interested in your answer if I'm wrong.
PMFJI.
ADA and Modula 2/3 both address this problem via package/modules
and even vanilla C can be used this way by a disciplined
programmer. It has been recognised within procedural programming
for at least 15 years (I'd say nearer 20) that bundling data
structures and the procedures that manipulate them together is a
good idea.
> You're repeating the ame assertion, but again without examples. In an OOP
> program, I can define member variables and member function sof a single class,
> and I can keep some member variables private since they apply only to the
> implementation, not to the interface.
ADA at least solves this problem for procedural programming and I
think Modula 2 did as well, but itsa a long time since I used it
so my memory might be faulty...
> set of member varibales. For that, I would need to pass around a structure or
> defined type which would then be an extra parameter passed to every related
> function
Just like in most OO languages(self, this, etc) except normally
the language hides it. (The exception being Python which
explicitly requires methods to have a first parameter that
represents the instance)
> How would a procedural language solve these problems? If it did, wouldn't
> that make it Object Oriented? If not, I think it would have to use some
> competing metaphor that would still make it something deserving of its own
> term beyond simply, procedural.
It depends on how narrowly you define procedural. I would
certainly class Modula as procedural but early ADA has
certainly been described as "object based".
>
> Again, you can assert all you like, but I haven't seen evidence of what you
Read the archives of comp.object. One of the enduring threads is
the need, or even the desirability, of OO programs to model the
real world. Many OO pundits advocate *not* modelling the real
world. The very fact that there is such hot debate suggests that
this is not as common as you migt expect from the theory.
> download API, so I have a class that manages the database, exposing only the
> minimum interface to manipulate what the application actually needs
If its a single class then procedural thechniques would work just
as well. Its only when we get into polymoprphic solutions that OO
has significant gain over procedural techniques IMHO.
> and I can mock that for testing. Likewise, the 3rd party API is only
> available on a few heavily used machines, so I need to be able to mock that as
> well for testing the rest of the system
And again if tyou are mocking an "API" the implication is that a
procedural solution could do the job just as well.
> Could I have done that without OOP? Perhaps, but it would have been much more
> work to do that and also engineer out errors up-front, e.g. ensuring that
> variables are properly initialized and torn down for each pass.
A good procedural solution would encapsulate both APIs in a
separate module and provide initialisation and termination
routines. Whats so difficult? This is the kind of stuff that was
bread and butter for procedural programs for many years.
> it with OOP, the simplest design might have ended up being an event-driven
> system, and that's tantamount to implementing a custom OOP in a procedural
> language.
Not at all, many event driven systems are non OOP. In fact the
largest event driven systems (Telephone switches, airtraffic
control systems, railway signalling systems etc) tend to be
designed with SDL case tools which typically generate procedural
code in C or ADA.
> Why should I reinvent that wheel for every app?
Absolutely, but the choice of OO or procedural has little to do
with that.
Incidentally I like OO and indeed have been using OO since I
learned Smalltalk in 1984 and most of my programming is OO. But I
did spend long enough in procedural projects during the 80's to
know that much of what OO enforces was also standard practice in
good procedural programs for a long time. The difference was that
procedural programs rely on programmer discipline in following
good practice, whereas OO tries to enforce it through the
language.
Alan G
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
| |
| Steve Jorgensen 2004-04-29, 1:00 pm |
| On Thu, 29 Apr 2004 08:29:02 +0100, Alan Gauld <alan.gauld@btinternet.com>
wrote:
>On Thu, 29 Apr 2004 05:24:40 GMT, Steve Jorgensen
><nospam@nospam.nospam> wrote:
>
>
>PMFJI.
>ADA and Modula 2/3 both address this problem via package/modules
>and even vanilla C can be used this way by a disciplined
>programmer. It has been recognised within procedural programming
>for at least 15 years (I'd say nearer 20) that bundling data
>structures and the procedures that manipulate them together is a
>good idea.
That only applies if you are talking about global variables, and excessive use
of these is asking for trouble. Even if I only use one "Instance" at a time,
in a procedural language, i must be much more careful to make sure
initialization and reinitialization happens properly, or I can avoid the issue
by avoiding globals, but then I'm passing structures to a collection of
procedures to avoid the globals, repeating the parameter, breaking
encapsulation, etc. I guess one can work around that by passing around
indexes to a collection entry in a private variable, but now, nothing is
tracking when all references to that index have gone out of use unless I
implement that carefully myself. It's an extra concern and possible source of
errors in every application. Packages and Modules simply do address the issue
to the extent that OOP does. If a Package or Module allowed dynamically
creating and destroying instances, we'd call it OOP - and we haven't even
touched on polymorhism and inheritance yet - keeping the code for a given set
of overrides together in one place.
>
>ADA at least solves this problem for procedural programming and I
>think Modula 2 did as well, but itsa a long time since I used it
>so my memory might be faulty...
I think you are asserting that Packages and Modules solve the problem. My
objection is the same as above. Global variables are not
>
>Just like in most OO languages(self, this, etc) except normally
>the language hides it. (The exception being Python which
>explicitly requires methods to have a first parameter that
>represents the instance)
Of course, it's all the same under the hood - that's not the point. The point
is that the OOP metaphor allows you to write code that has the same effect at
run-time in a more organized way, and it adds implicit abilities to so things
cleanly that you would have to write extra code for every time in a procedural
language. I could not argue that SQL is just like C because you could code
anything you could code in SQL in C if you worked at it hard enough.
>
>It depends on how narrowly you define procedural. I would
>certainly class Modula as procedural but early ADA has
>certainly been described as "object based".
So, what features does it add that make folks call it Object Based? Wouldn't
that mean it has partially adopted OOP? VB has also partially adopted OOP,
but the lack of any inhertiance and class constructors still greatly limits
the ways you can use it to eliminate code duplication.
>
>Read the archives of comp.object. One of the enduring threads is
>the need, or even the desirability, of OO programs to model the
>real world. Many OO pundits advocate *not* modelling the real
>world. The very fact that there is such hot debate suggests that
>this is not as common as you migt expect from the theory.
Sometimes, I ise OOP to model the real world, but not by trying to model the
real world. I'm trying to orgainize code to minimize duplication and engineer
out types of code constructs that are prone to errors, hard to debug and hard
to safely modify.
>
>If its a single class then procedural thechniques would work just
>as well. Its only when we get into polymoprphic solutions that OO
>has significant gain over procedural techniques IMHO.
If the procedural approach would have worked as well, I would have used it. I
used OOP because it was the easiest way to elimiante duplication and follow
the LoD. I have one set of code that creates instances of the database
handler and the API handler, and moves a batch of data between them. This
main process code has no need to know that when it creates an instance of the
database manager, connections are initialized, etc., and it has no need to
know that when it closes it down, a timestamp is written, and objects cleaned
up. It is simple to ensure that variables are all reinitialized for the next
pass because I'm using a new instance of the object. To do that with OOP
would have taken more design, more code, and been less safe.
>
>And again if tyou are mocking an "API" the implication is that a
>procedural solution could do the job just as well.
?
I have 20 odd methods in the interface. The way I do this now, is define an
interface, and define 2 classes that implement the interface. I can just
change what kind of object is returned from one function to change which
implementation I get for all those methods. Furthermore, when I compile, I
find out immediately that the calling code and the 2 classes all follow the
interface correctly.
>
>A good procedural solution would encapsulate both APIs in a
>separate module and provide initialisation and termination
>routines. Whats so difficult? This is the kind of stuff that was
>bread and butter for procedural programs for many years.
I've never seen a procedural language that can treat a module as a replaceable
abstraction. What are you talking about? I suppose I could add and remove
the entire modules, but then I have to catch each one up with the new
interface when I swap them rather than maintaining them live in a single
project. Also, with OOP, I can swap them at run-time if I want, and that
certainly could be desirable.
>
>Not at all, many event driven systems are non OOP. In fact the
>largest event driven systems (Telephone switches, airtraffic
>control systems, railway signalling systems etc) tend to be
>designed with SDL case tools which typically generate procedural
>code in C or ADA.
Are you hearing what I'm saying? OOP languages already do what I would have
had to engineer a custom event-driven model to handle, and they'v already done
the work of optimizing the performance of this metaphor? If OOP already
solves that part of my problem space, why should I solve it again for every
app? With OOP, I don't need to implement an event model because OOP already
is sort of a representaiton of an event model.
>
>Absolutely, but the choice of OO or procedural has little to do
>with that.
Again, I say "?" Sure, OOP might not be the right answer to every problem,
but it sure offers a lot of nice ways to remove duplciation and engineer out
errors in almost every app I work on that procedural languages simply don't
offer. It requires more work and care to solve the same complex problem in a
proceduarl language, and the resulting code takes more work and care to safely
maintain.
>Incidentally I like OO and indeed have been using OO since I
>learned Smalltalk in 1984 and most of my programming is OO. But I
>did spend long enough in procedural projects during the 80's to
>know that much of what OO enforces was also standard practice in
>good procedural programs for a long time. The difference was that
>procedural programs rely on programmer discipline in following
>good practice, whereas OO tries to enforce it through the
>language.
Sure, but OOP also enforces a unified convention rather than having every
programmer engineer their own unique set of practices and conventions for
solving the same endemic problems. Frankly, I'm in favor of tools that
effectively remove endemic concerns from the programmer's plate, so more time
and effort can be spent solving the unique problem at hand.
| |
| William 2004-04-29, 1:01 pm |
| "Steve Jorgensen" <nospam@nospam.nospam> wrote in message
news:gk3190t6te6kiej2emt5s0rl8s06bo7tqk@
4ax.com...
> On Thu, 29 Apr 2004 12:11:43 +0930, Andrew Gabb <agabb@tpgi.com.au> wrote:
>
> I'm skeptical of this comment, but I'm interested in your answer if I'm
wrong.
> Perhaps, you're right for some value of "modern", but it sure doesn't seem
to
> apply to the procedural languages I've been using. What procedural
languages
> do you consider to be modern, and what metaphors do they employ to solve
this
> problem as opposed to how OOP solves them?
OOP doesn't depend on any language, it's a way of programming - hence
the name. Some languages offer more intrinsic support for it than others,
but
I haven't encountered a language that actually rules it out (there probably
are
some, but I don't go looking for them). I've written OO code in assembler,
and bourne shell, myself, and those are pretty procedural by nature. -Wm
| |
| Richard Riehle 2004-05-04, 2:34 pm |
|
"Alan Gauld" <alan.gauld@btinternet.com> wrote in message
news:lha190dkg6i8v9n7fughcme2v35530ikdf@
4ax.com...
> On Thu, 29 Apr 2004 05:24:40 GMT, Steve Jorgensen
> <nospam@nospam.nospam> wrote:
> ADA and Modula 2/3 both address this problem via package/modules
> and even vanilla C can be used this way by a disciplined
> programmer. It has been recognised within procedural programming
> for at least 15 years (I'd say nearer 20) that bundling data
> structures and the procedures that manipulate them together is a
> good idea.
Note, also, that the current ISO/ANSI/IEC 1995 standard for Ada
includes support for OOP including inheritance, polymorphism, and
dynamic binding. However, as you noted in another part of your
posting, these features are seldom recommended or used, in any
programming language, for software in which high-dependability is
a requirement of the software. In particular, dynamic binding is
deprecated by most of the safety-critical software community.
Richard Riehle
| |
| Richard Riehle 2004-05-04, 2:34 pm |
|
"William" <Reply@NewsGroup.Please> wrote in message
news:5rudnUaqGq8atwzdRVn-hg@giganews.com...
> OOP doesn't depend on any language, it's a way of programming - hence
> the name. Some languages offer more intrinsic support for it than others,
> but I haven't encountered a language that actually rules it out (there
probably
> are some, but I don't go looking for them). I've written OO code in
assembler,
> and bourne shell, myself, and those are pretty procedural by nature. -Wm
Object-oriented programming can be emulated in most languages,
but one cannot be very successfull doing OOP except in language
that offers direct support. Assembler, C, COBOL, Fortran, Forth,
Pascal, PL/I, and the many other languages that fall short of the
required support for information hiding, encapsulation, inheritance,
and dynamic binding simply do not meet the needs of object-oriented
programming.
Consider, for instance, encapsulation. How does one provide good
encapsulation support in C? With great difficulty, I would answer. On
the other hand, how does one design well-encapsulated types/classes
in Ada, C++, Java, or Eiffel? With ease and simplicity, would be the
correct answer.
The issue is expressibility versus expressiveness. Most constructs are
ultimately expressible in any language, often with great difficulty and
extraordinary complexity. On the other hand, some languages are
more expressive of certain constructs than others. The difference
is whether one chooses the right tool or not. A language designed
to express OOP concepts is likely to be the right tool.
In fixing my automobile, I can get by with a collection of adjustable
wrenches and a couple of screwdrivers. My mechanic, a professional
at such things, chooses to use socket wrenches along with a selection
of other carefully chosen tools.
An amateur will frequently be satisfied with the equivalent of a
knuckle-buster wrench, but the professional will understand the
importance of choosing the right tool for the right job. A professional
software developer should be no different. When doing OOP, it
would be a bit absurd to choose inadequate tools. In fact, the
same would be true of any kind of software project.
The professional mechanic will choose a torque wrench when that
level of precision is required. The amateur will choose any long
handled wrench and risk twisting the head of a bolt. No problem.
We can always drill out the broken bolt and start over. Many
programmers work exactly that way.
One reason I prefer Ada, for the kind of work I do, is that safe
software requires a high level of precision and reliability. Ada
is the torque wrench of programming languages. Certainly, a
careful programmer can emulate the precision of Ada in C or
Assembler, but not without the risk that we may need to do the
equivalent of drilling out a few bolts before we get it right.
The real professional, in software or otherwise, will always try
to select the most appropriate tool for the job at hand. To do
otherwise, it seems to me, is a bit foolish.
Richard Riehle
>
>
| |
| Bradley K. Sherman 2004-05-04, 2:34 pm |
| In article <gjSkc.1800$V97.984@newsread1.news.pas.earthlink.net>,
Richard Riehle <adaworks@earthlink.net> wrote:
>
>
>Consider, for instance, encapsulation. How does one provide good
>encapsulation support in C? With great difficulty, I would answer.
File static variables work pretty well. We called these 'packages'
if I remember correctly.
--bks
| |
| Bjorn Reese 2004-05-04, 2:34 pm |
| On Sat, 01 May 2004 18:49:48 +0000, Richard Riehle wrote:
> Consider, for instance, encapsulation. How does one provide good
> encapsulation support in C? With great difficulty, I would answer. On
You can easily achieve encapsulation with something akin to the
Cheshire Cat idiom (a.k.a. pImpl.)
Inheritance, on the other hand, is quite difficult in C.
--
mail1dotstofanetdotdk
| |
| William 2004-05-04, 2:34 pm |
| "Richard Riehle" <adaworks@earthlink.net> wrote in message
news:gjSkc.1800$V97.984@newsread1.news.pas.earthlink.net...
>
> Object-oriented programming can be emulated in most languages,
> but one cannot be very successfull doing OOP except in language
> that offers direct support.
And yet, I was, go figure.
Usually this argument comes down to those who expect something
"out of the box" and those who are willing to implement the details
with whatever the available tool is (within reason). Now I can't
speak to what happened when you tried to apply OOP to C or
assembly, I can only state my experience: the results were quite
good, a vast improvement over the non-OOP alternative.
So what do you do when an OOP-oriented language isn't
available to you? Walk away because you assume you can't be
successful? Suddenly forget all the OOP techniques you know
that can be applied irrespective of the language?
Why were OOP techniques adopted if "[...] one cannot be very
successfull doing OOP except in language that offers direct
support."? That would imply that the first person to attempt using
OOP would not have been impressed wth the results and given
up (since OOP predates languages which directly support it) right?
(Yes, I know some of the refinements would be difficult to
successfully implement in "lesser" languages, but what does that
have to do with it? OOP isn't all or nothing.)
-Wm
| |
| Richard Riehle 2004-05-12, 9:06 pm |
|
"William" <Reply@NewsGroup.Please> wrote in message
news:MIadnUXeZbl4pwjd4p2dnA@giganews.com...
> "Richard Riehle" <adaworks@earthlink.net> wrote in message
> news:gjSkc.1800$V97.984@newsread1.news.pas.earthlink.net...
>
> And yet, I was, go figure.
>
> Usually this argument comes down to those who expect something
> "out of the box" and those who are willing to implement the details
> with whatever the available tool is (within reason).
Yes, of course. I recall from my childhood how farm equipment
could be fixed with baling wire, a couple of cotter pins, and, in
the immediate absence of a mechanics wrench, the old pipe
wrench hanging in near the turkey pen.
You can do OOP, up to a point ("within reason") using inappropriate
tools, but the result is not likely to be very pretty.
Professionalism is, to some extent, about knowing when and how to
use the right tool. If I see my auto mechanic doing something wierd,
such as using a pipe wrench to remove the plug from my oil pan, I
might get suspicious about the rest of his practices.
Software engineering is difficult enough already without increasing
that difficulty by patchwork practices using inappropriate tools. Do
we need automated configuration management tools? You bet! Oh,
you might answer, I can do configuration management without paying
for such tools. For some projects, yes. However, I have seen the
result of using "baling wire" to emulate configuration management on
large projects and it is not something I would commend as a standard
practice.
The issue is not expressibility, but expressiveness. Can one express
some of the features of OOP in C? Probably. Does C provide a
natural expressiveness of OOP? Absolutely not! Can one write
a program in C that does everything one can do in SQL. Absolutely!
Is it a good idea? Absolutely not!
When embarking on a software engineering project, the professional
will understand the need to choose good tools -- the right tools. It
might be the case that development can be accomplished using
inappropriate tools, but development is only part of the story. Most
esimates of the maintenance side of software give the number in the
70% to 80% range relative to development. Most maintenance is,
as the project lives a long time, enhancement maintenance. That is,
extending the existing software with new features. OOP, using the
right tools, makes this more convenient. I find, for example, that
Ada makes extension of existing software much easier than C or
other non-OOP languages.
Another aspect of maintenance is that of understanding. Of the
70-80% devoted to maintenance, a large percentage of that
is devoted to understanding the code that needs to be maintained.
When someone kludges together their own unique idea of how
to program with objects, using a non-OOP language, understandability
becomes more difficult. In fact, obfuscation is probably more
characteristic of such software. C++ is replete with enough
obfuscation already that we don't need more of it.
So, for any project in which I am engaged, I owe it to my client,
my colleagues, and my successors, to choose tools that will
be contribute to the longevity, the extensibility, and the understandability
of my final product. This means I have a responsibility to select
the right tools, not to create a monstrosity where the salient
feature of is the baling wire rather than the solution itself.
Richard Riehle
| |
| William 2004-05-12, 9:06 pm |
| "Richard Riehle" <adaworks@earthlink.net> wrote in message
news:qSsmc.9674$V97.4725@newsread1.news.pas.earthlink.net...
>
> Yes, of course. I recall from my childhood how farm equipment
> could be fixed with baling wire, a couple of cotter pins, and, in
> the immediate absence of a mechanics wrench, the old pipe
> wrench hanging in near the turkey pen.
>
> You can do OOP, up to a point ("within reason") using inappropriate
> tools, but the result is not likely to be very pretty.
>
> Professionalism is, to some extent, about knowing when and how to
> use the right tool.
And how to get it done when there is no choice of tool. And how to
implement the best techniques you can with the available tools.
Apparently you don't understand what the phrase "available tools"
can mean in a production environment. On one of my projects it
meant assembler - there was no other tool available (well, OK,
machine language but that's going in the wrong direction).
If you understand OOP, you use the best language you can get
your hands on, but you don't stop using OOP techniques just
because you can't get the best language.
Everything you've said is correct, but inapplicable. If the choice of
tools isn't yours to make, then no argument for choosing the correct
tool makes any sense.
> Do we need automated configuration management tools? You bet! Oh,
> you might answer, I can do configuration management without paying
> for such tools. For some projects, yes. However, I have seen the
> result of using "baling wire" to emulate configuration management on
> large projects and it is not something I would commend as a standard
> practice.
Actually, CM is part of my job and I can tell you the choice of tool is
a secondary consideration, and whether you pick a free tool or pay
through the nose is at best tertiary. The primary consideration is laying
out the CM process so people understand it, believe in it and use it.
(If they really get it, they could use 3x5 cards and make it work, albeit
tediously.) Certainly, people with a good grasp of CM will do as well
or better with CVS/Bugzilla as people who think buying Clearcase will
solve their CM problems. -Wm
| |
| William 2004-05-12, 9:07 pm |
| "Richard Riehle" <adaworks@earthlink.net> wrote in message
news:8S_mc.12069$V97.6587@newsread1.news.pas.earthlink.net...
>
> "William" <Reply@NewsGroup.Please> wrote in message
> news:042dneeHA5ee7QfdRVn-hA@giganews.com...
>
> One of the USMC mottos is: adapt and overcome. I agree that
> we are often confounded by managerial stupidity when it comes to
> selecting appropriate tools.
You're still assuming the tools are available at all. In the assembler
case I mentioned, the only development platforms available were a
buggy C compiler and a decent assembler. (Not an uncommon
situation in the case of embedded programming, or, in this case, a
proprietary game platform - much the same thing.) Management
choices didn't have anything to do with it, reality did.
There can be valid reasons for limiting the choice of tools even when
they exist. In fact, I wish I could have set a limit a couple of years
back when one developer decided to write his little project in C++
using all sorts of OOP bells and whistles. We had to upgrade five
master build machines to accomodate the only binary, out of dozens,
that required C++ (and STL - it wasn't easy to find a suitable version
of that for at least two of the machines). From a CM standpoint, it
wasn't pretty; sometimes there are reasons to wait. -Wm
| |
| Richard Boaz 2004-08-22, 8:57 am |
| the discussion here seems to be very much centered around languages and
which and what kind is best to achieve whatever.
however, another point which is rather relevant in answering the original
question, i feel, is that object orientation provides a new way of
_thinking_ about how solutions can be provided. as someone stated, OO is
merely a reflection of how the world is built around us, a bicycle is not
"one thing", but rather a collection of "things" whereby the whole is way
greater than the sum of the parts. if the bike were built "procedurally",
we'd simply end up with "one thing" after we were done making it, not a
collection (and when part of it broke, we'd simply have to get a new one
instead of merely replacing the broken "part").
while it is important to understand the differences between languages and
what individual benefits each of them has, we must remember that from the
machine's point of view, there is absolutly no difference at the binary
executable level, merely which compiler was used to create the assmebler
version, which, in turn, creates a binary version. a computer language
is, at root, nothing more than an agreed upon set of syntax rules,
different sets distuingishing themselves only in how they make something
easier for the programmer to achieve. the binary executable is always, at
root, procedural. (at the machine level, what would an OO-based computer
be, anyway? a biologically-based machine, for example?)
so for me, the important aspect of OO is how its methodologies are applied
to the design phase of the solution being provided. one can, no matter
what, implement OO ideals in any environment one wishes; how easy this is
between different languages (the tools) is the important question that
influences how you choose the tool. once upon a time, a C++ compiler was
at least two-phase: an interpreter converting the C++ code to C, followed
by a C compiler. meaning, i could have written this same implementation
in C, but why would i want to?; it's so hard. on the other hand, i am
perfectly capable of designing a system with OOP methodologies with the
implementation being effected in any language i choose, i must merely
choose wisely as to which language makes it easiest on me, the design, the
implementation, and ultimately the end-user.
back to the original question: for me it's not in any way related to
procedural language vs. OO language, the value of object orientation is
how it has made us programmers "think", and ultimately design, differently
than we did before, and that it is this that has fundamentally altered the
design phase of software development. and i would maintain it's how the
upstream design phase is "thought" about that most directly influences all
software development steps which follow, not necessarily which computer
language is chosen.
or, our manner of thinking has finally caught up with how nature sees
itself.
richard boaz
| |
| Bradley K. Sherman 2004-08-22, 4:03 pm |
| In article <opsc4mdjylbpzyp2@news.xs4all.nl>,
Richard Boaz <riboaz@xs4all.nl> wrote:
>the discussion here seems to be very much centered around languages and
>which and what kind is best to achieve whatever.
>
>however, another point which is rather relevant in answering the original
>question, i feel, is that object orientation provides a new way of
>_thinking_ about how solutions can be provided. as someone stated, OO is
>merely a reflection of how the world is built around us, a bicycle is not
>"one thing", but rather a collection of "things" whereby the whole is way
>greater than the sum of the parts. if the bike were built "procedurally",
>we'd simply end up with "one thing" after we were done making it, not a
>collection (and when part of it broke, we'd simply have to get a new one
>instead of merely replacing the broken "part").
That's absurd. Bicycles *are* built procedurally. Just because
it has subassemblies does not make it OO.
--bks
| |
| Nameless 2004-08-23, 3:57 am |
| "Bradley K. Sherman" wrote in message
news:cgadnc$b5j$1@panix1.panix.com...
> In article <opsc4mdjylbpzyp2@news.xs4all.nl>,
> Richard Boaz <riboaz@xs4all.nl> wrote:
>
> That's absurd. Bicycles *are* built procedurally. Just
> because it has subassemblies does not make it OO.
Absurd, indeed. Besides, the OP obviously hasn't heard of
programme modules (i.e., in many languages).
Somewhat off topic I know, but when did it become acceptable
to write 'i' instead of 'I', and to begin sentences with
lower case letters? Anyone?
--
Mail sent to this email address is automatically deleted
(unread) on the server. Send replies to the newsgroup.
| |
| Alan Gauld 2004-08-23, 3:57 am |
| On Mon, 23 Aug 2004 02:55:29 +0200, "Nameless"
<news.mail@chello.no> wrote:
> Somewhat off topic I know, but when did it become acceptable
> to write 'i' instead of 'I', and to begin sentences with
> lower case letters? Anyone?
The is an American poet who does that, and the 60's(?) book
"Cry the beloved Country" also used the technique. It's a
pain in the brain trying to read it tho'...
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
|
|
|
|
|