http://xent.ics.uci.edu/FoRK-archive/feb98/0139.html
to dist-obj for context because Dave Crook's comments in his post there
has stimulated so much discussion about objects here today.
Dave's point about decomposition and encapsulation having existed before
objects were en vogue is valid, as is his point that good design is more
important than what you use to implement that design.
I think the good thing about objects is that they help to enforce a
discipline which, although it does not guarantee good design, certainly
encourages good design. Objects are not a helpful way of thinking for
everyone, but they are certainly a helpful way of thinking for some.
I say that objects do not necessarily guarantee a good design because of
an experience I had managing a student term project here at Caltech in
which the students didn't understand good design -- instead of writing
their program in 21 modular units, they wrote it as a single monolithic
12,000+ line file of pseudo-Java which they then ran through a
preprocessor that they custom-wrote to take their pseudo-Java, convert
it to real Java, and in the process break it up into 21 files each
containing the appropriate objects which could then be compiled by the
Java compiler.
I also realize that you need not use objects to have a clean, modular
design, with the appropriate data coupled with the appropriate methods
for that data.
My point is that in some cases, objects can help. And we shouldn't turn
our back on them just because they don't help in all instances. We all
know that software has no silver bullet. Our job as developers is to
choose the right tool for each given job -- and so we may or may not
want objects, we might want to use commercial off-the-shelf tools
wherever we can, we may be forced to incorporate legacy code, we may
consider the tradeoffs between centralized and decentralized solutions,
we might consider client-server or multi-tiered approaches, we may or
may not want to specify interface syntax using IDLs, we may or may not
want to employ patterns for solutions, we may have to weigh the use of
different languages to figure out which one is most appropriate, we
might want to use declarative markup to better annotate the data, we
could choose RPCs for communication or perhaps messages or events, we
might decide that an agent metaphor is appropriate, we may want to use a
document metaphor for the artifacts being created, stored, and
exchanged... and so on.
I think it's wonderful that there are so many software tools available,
because it means that we're far more likely to find the right tool for
developing solutions more easily.
-- Adam
Dave's original post:
> From: Dave Crook (dcrook@commwerks.com) Thu, 12 Feb 1998 01:36:07 -0800
>
> ------------------------------------------------------------------------
> Adam,
>
> Will there be any rules to this death match? I hope not, for it to
> truly be a religious war then that has to be a war to the death, no
> quarter asked or granted. And as well all know, EVERY topic in this
> field takes on religious proportions. I've watched month long flame
> wars over vi vs emacs. I'm proud to have been one of the first posters
> on alt.religion.emacs (you can't spell evil without vi), but then it
> was tounge-in-cheek humor, I read the newsgroup a couple months after
> it started and sadly enough, people were taking it seriously. These
> people have no lives.
>
> But I will take up this call to arms and defend "the way things have
> been and worked all right" vs "the fad of the month".
>
> Actually I'm kidding. I am actually looking at this object stuff
> seriously, I just picked up Orfali, Harkey and Edwards "Essential
> Distributed Objects Survival Guide" and I actually intend on reading
> it soon. But since I haven't found object religion yet, I'll make some
> objections to your post.
>
> ...
>
> Adam, can you prove that OO isn't simply a plot to drive programmers
> out of the field and increase salaries? The circumstantial evidence is
> there, just as OO programming has gotten hot in the last few years the
> demand for programmers is going up. Even now there is a serious
> decline in the number of people going into the field. Probably all the
> C++ that they are scaring the college kids with.
>
> ...
>
>
> Yes, decomposition and encapsulation are GREAT concepts. But they
> PREDATE OO programming by a decade or too. How is a class
> fundamentally different from an abstract data type? True, its got a
> neater implementation, but its still the same thing. I've implemented
> typedefs and related manipulation functions in one file in C before, I
> just called it an abstract data type. I think you will have to go
> farther if you are going to claim a decisive victory for OO. It is
> true that the main subject of what is being decomposed and
> encapsulated is different for functional based design. But still its
> still organization.
>
> I grant that OO designed systems have a greater capacity for reusing
> modules of code in other projects. The modules rely on code outside
> themselves only through starkly defined interfaces. Functional
> decomposition doesn't give you this.
>
> But I ask, is this really a big deal? In THEORY it sounds great. But,
> its theory. One of the quotes in the joke interview was Stroustrup
> stating that no companies reuse their code. I hate to break it to you,
> but its true. Now some things do get reused a lot, they are called
> libraries and you can create those without OO programming thank you
> very much. But follow me on this for a second. Assume you have an OO
> designed banking system. Now lets say that over time that the
> requirements behind the system have changed enough that a redesign is
> in order (they had a merger, etc). How much of that system are you
> going to reuse in the new design. I submit that you are mostly going
> to reuse the lower level objects, the ones that get inherited by other
> objects. I submit that in most functional designed systems that these
> same tasks would probably be done by a library so that it could be
> easily called by other parts of the system. The library would be just
> as reusable as the object in this case.
>
> Now maintenance is another area that I hear as being the strong point
> for OO. I agree that since in OO design data is well encapsulated.
> Changing how private data is manipulated within a method has no effect
> on the other objects, even the ones that call it. But a good
> functional design will give you the same benefit. Most language
> support having private data for functions, even C. But maintenance
> work is more than simply making dink changes to code. Any changes you
> make during maintenance are for a reason, ie somebody wants you to
> make a change to the FUNCTIONALITY of the system. Under which system
> of organization do you think it will be easier to find and change all
> the code responsible for a particular function, one where all the code
> is grouped by function or one by where its grouped into objects that
> kinda match program functionality. I submit that any benefits you gain
> in being able to make changes without effecting the rest of the system
> are lost by having to spend more time finding the code you want to
> change in the first place.
>
> > > At some point, some light clicked - this is personal, of
> > > course- YMMV. But I think once you 'get' decomposition, there's
> > > really no going back. You can't fall in love with structured
> > > programming again once you've really seen the other.
>
> Hey, good functional designs should have decomposition and
> encapsulation too. Not every non-OO program consists on nothing but
> global variables and goto statements. Its not magic, its just good
> design. The kind of design that you can't learn in college simply
> because no one in college has to live with their programming mistakes
> for more than a semester. Maybe that should make freshmen programmers
> write some moderate sized program and then make them maintain the damn
> thing for their entire four years. Then maybe they will pause a second
> before writing programs and think of the poor bastard that will have
> to fix the thing later.
>
> > My attitude is, yes, object philosophy != existing object tools. We
> > can learn from objects without using them as a hammer wherever there
> > are nails.
>
> Sorry Adam, but your religious fervor is showing. "object philosophy
> != existing object tools"?? You seem to miss the point, I'm not merely
> suggesting that encapsulation and decomposition can be done without
> the latest copy of Visual Studio or the newest JDK, I'm openly
> shouting the blasphemy that these concepts are bigger than and can be
> implemented WITHOUT OO programming at all.
>
> Answer me this puzzle. Lets say I've created a nice stack
> implementation in C using something as hideously non-OO as void
> pointers. Now since I'm a neat freak about my code (my apartment is
> another matter) I make some nice typedefs for my datatype. I also
> write some general manipulation functions for my stack datatype and I
> throw all these in one nice c source and header file for easy use my
> multiple programs.
>
> Now either what I have done doesn't show encapsulation or
> decomposition separate from OO programming OR you can argue that C is
> an OO programming language. Your pick. :-)
>
> ...
>
> Everything will be objects in five years? Hmm, sounds like a
> reasonable prediction. But here, let me make one of my own.
>
> Its 2003 and Wired has officially declared the distributed object
> movement dead. Oh, it seemed like a great idea at the time. PC costs
> five years ago were still high enough that making stripped down
> computers strictly for running network based apps made sense. A short
> lived "back to the mainframe" movement that was killed by the
> continual march of Moore's law. Thin-clients always seemed like a
> great idea for other people, but no one wanted one for themselves. But
> with the continuing drop in prices for hardware and the ever
> increasing bang for the buck the bottom end model simply outgrew the
> limitations expected of thin-client machines, they could run real
> software just like the more expensive computers. Even the PDAs today
> seem powerful compared the machines of 5 years ago. The final
> deathblow for distributed objects came when angry mobs of computer
> owners went to the main purveyors of bloated software Netscape and
> Microsoft and demanded that they write reasonably sized software.
>
> How's that for a future?
>
> > Many people can't even write bug-free software in the current
> > climate of less ambitious, static, local, non-concurrent "objects".
>
> Ummm how about programmers using typical client-server programming
> methodologies and actually spending some time DESIGNING BETTER <very
> bad word>ING programs. I think the only thing that the browser war
> between Microsoft and Netscape is showing us is what happens when
> program design and testing are thrown out in favor of adding the
> feature dujuor. Gigantic bloated programs that crash on a regular
> basis. The main catch is that consumers basically have the choice of
> one pig or the other. I've thought about looking at Opera, but since
> they don't have a linux version it won't do much for me.
>
> Another solution is to increase the skill level of the "programmers"
> that you mention. This field has always had a ton of people that know
> less then they let on. The web has increased the problem a thousand
> fold. Every yeahoo that has a copy of hotdog pro thinks they are a web
> page designer. People who manage to mail-merge in a list of people
> from access into their holiday newsletter on Word thinks they are a
> DBA. I personally don't suffer from these delusions of adequacy. I'm a
> pretty good programmer and I know my way around administrating a unix
> box. But when it comes to overall design and layout, my web pages
> suck. Just because I can run pc paintbrush that doesn't mean that I'm
> a graphic artist.
>
> ...
>
> Come to the dark side Adam. Give up your faith in objects and join the
> programming skeptics. Feel the power of the dark side of the force,
> use ANY programming method that makes the most sense for the project
> at hand. Treat the most faithful belief systems of others as mere
> tools in your toolbox. Bend them to your will.
>
> You see, "objects" = "current trend", great for a lot of tasks but not
> the ONLY method for software development. Many of the concepts that
> are being co-opted by OO proponents have simply been the hallmarks of
> good software design before OO was even at the pre-fad days.
>
> > The reason I sent this post here, is that I think FoRK remains the
> > bastion of object skeptics, and perhaps this will inch some people
> > forward in thinking about objects.
>
> Not if I can help it :-)
>
> Dave "Chief Representative of the forces of darkness" Crook
----
adam@cs.caltech.edu
Objects in rearview mirror may be closer than they appear.