What is wrong with OO ?
Ahmed
Hello Every Body
I am a new research student working at the field of Object Oriented Technology...I have several
critical opinions about Object Oriented in general, and I like to participate it with you and hear
you expert comments and opinions
Object Oriented Technology came with quite promising claims that if achieved can benefit the software
development companies and organisations millions of pounds.
Some of these claims for instance
1 - high reusability of objects and frameworks
2 - Resilience to change, i.e. low software maintenance and evolution cost
3 - Easier understanding by the user and Natural transition between the analysis, design,
implementation because they all use tangible perceived objects.
However the reality is not so bright as claimed..if so, then nobody today thought to develop a
software on the traditional structural methods...
My question is what is wrong with OO ? why it did not achieved its targets yet.?
What are the main obstacles?
Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ?
or is it the deficiency in the development tools used like C++ or Smalltalk ?
or is it the steep difference in thinking between the traditional and OO schools ?
or is it related with the difficulty of object classification ?
or is it because of vast legacy systems done using the traditional methods ?
or is a combination of many other factors...?
I know that giving a precise answer is very difficult for such a complex question, but I like to
hear the comments of people working at the feild and who suffered from many difficulties..
I would really appreciate any participation, response or even leading to a good reference ,
and would be very grateful if the opinions are supported by some evidences...
Thanks
Yours
Ahmed Alkooheji
University of Sheffield
UK
Bill Gooch
Ahmed wrote:
> ....
> Object Oriented Technology came with quite promising claims that if achieved can benefit the software
> development companies and organisations millions of pounds.
>
> Some of these claims for instance
> 1 - high reusability of objects and frameworks
While this may be claimed about specific frameworks, it is
not IMO a valid generalization about OOT. It is feasible
and important to design and implement objects which achieve
immediate *reuse*, general *reusability* is quite rare, and
exceedingly difficult to achieve, IME. Typically the costs
outweigh the benefits.
To be clear what I mean by "immediate reuse" - it is most
often fine-grained (method and protocol level) reuse of
behavior via inheritance, delegation, etc. which is readily
achievable and most important. Medium-grained (class level)
reuse is also feasible, although it requires greater design
effort and foresight (and/or prior experience in the domain).
Large-grained (framework level) reuse is much harder (I think
somewhat exponentially with the number of classes/protocols/
relationships involved), and much more rarely achieved.
> 2 - Resilience to change, i.e. low software maintenance and evolution cost
This depends entirely on the quality of the analysis, design
and implementation. Objects effectively *support* resilience
by allowing implementations to mirror problems in a way that
minimizes unwanted dependencies, thereby limiting the scope of
changes. However, such results certainly aren't automatic,
and the misconception that resilience is an inherent attribute
of OOT works against the accomplishment of it.
> 3 - Easier understanding by the user and Natural transition between the analysis, design,
I'm very unclear what you mean by "Natural" here, but again,
ease of understanding by anyone is entirely dependent on the
quality of analysis, design and documentation. Again, OOT
used effectively can facilitate ease of understanding, but
that doesn't happen by itself.
> implementation because they all use tangible perceived objects....
Sure, software objects are "tangible perceived objects"
(sometimes perceived anyway), if only inasmuch as we've
decided to *call* them "objects." The more I think about it,
the more this choice of a name for software entities strikes
me as having been a mistake.
--
William D. Gooch bi...@iconcomp.com
Icon Computing http://www.iconcomp.com
Texas liaison for the International Programmers Guild
For IPG info, see http://www.ipgnet.com/ipghome.htm
Bill Gooch
Bill Gooch wrote:
>
> Ahmed wrote:
> > ....
> > Some of these claims for instance
> > 1 - high reusability of objects and frameworks
>
> While this may be claimed about specific frameworks, it is
> not IMO a valid generalization about OOT. It is feasible
> and important to design and implement objects which achieve
> immediate *reuse*, general *reusability* is quite rare, and
Sorry, that last sentence should have read:
"Although it is feasible and important to design...."
^^^^^^^^
Fred Parker
Ahmed wrote:
> chop
> My question is what is wrong with OO ? why it did not achieved its targets yet.?
> What are the main obstacles?
> chop
"We don't suffer from a Deficiency of Knowledge,
We suffer from a Deficiency of Execution"
Ell
Bill Gooch (bi...@iconcomp.com) wrote:
How about all of the objects that are reusable in PowerBuilder? Things
like Window, SQLCA, MLE, SLE, etc. objects which one uses time and time
again. Similarly with other frameworks like MFC, where one uses
CDocument, CDialog, CView etc classes time and time again. With these
objects and classes one has "immediate reuse" and "general reusability",
it seems to me.
Elliott
Ell
Ell (e...@access4.digex.net) wrote:
Sorry, I missed the "not IMO a valid a generalization about OOT". Still
it seems to me that most everyone uses frameworks nowadays - their own, or
pre-made. I agree with you that given the mechanics and language
differences it's almost impossible to reuse a class/object from one
environment in another. But that doesn't make the goal for reuse within
the same environment any less important.
Elliott
Harry Protoolis
On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed <ACQ...@shef.ac.uk> wrote:
>Hello Every Body
>
>I am a new research student working at the field of Object Oriented Technology.
> ..I have several
>critical opinions about Object Oriented in general, and I like to participate it
> with you and hear
>you expert comments and opinions
>
> benefit the software
>development companies and organisations millions of pounds.
>
>1 - high reusability of objects and frameworks
> , design,
>
>However the reality is not so bright as claimed..if so, then nobody today though
> t to develop a
>software on the traditional structural methods...
>
>What are the main obstacles?
I think this is overly negative, OO has not been and never will be a
'silver bullet' to solve all software development problems, but no-one
but a few spin doctors ever claimed it would be.
However, the real question should be 'has OO made a significant positive
difference', and in my experience the answer is a resounding 'yes!'.
I have been a professional software engineer for 10 years now, the first
half of which was spent fighting against traditional structured
techinques, it was only despite them I was able to get anything
finished.
The traditional techniques all suffered from a number of significant
flaws. Perhaps the most damaging one was what I (rather unkindly) think
of as 'The glorification of idiots' phenomenon. What I mean by this is
that projects were typically infested by a group of people who never
wrote any software, but spent most of the budget drawing diagrams that
the implementors never used.
The main contribution of OO has been was could be termed 'The
glorification on the implementor'. This has been achieved by the
effective marriage of Analysis, Design and Implementation. The result
is that every member of the team does all three of the key tasks.
In fact IMHO an OO team has no place for anyone who cannot do all
three tasks. Jim Coplein wrote an excellent pattern called
'Architect also Implements' which covers very nicely the reasoning
behind not allowing non-implementors to design systems.
Certainly the mecca of automatic reuse has not been achieved, but the
quantity and quality of 3rd party components available for most OO
languages already exceeds that available for their non-OO counterparts,
and IHMO this suggests a bright future.
Certainly OO has not made writing software trivial or automatic, but
then, *nothing ever will*.
Cheers,
Harry
-
alt.computer pty ltd software development consultants
Robert C. Martin
> Object Oriented Technology came with quite promising claims that if
achieved can benefit the software
> development companies and organisations millions of pounds.
Those claims were not made by the engineers and researchers who "invented"
OO. They were made by marketeers who found a new way to differentiate
products, and by engineers who had shut off their ability to employ
critical thinking.
>
> Some of these claims for instance
> 1 - high reusability of objects and frameworks
> 2 - Resilience to change, i.e. low software maintenance and evolution cost
> 3 - Easier understanding by the user and Natural transition between the
analysis, design,
> implementation because they all use tangible perceived objects.
>
> However the reality is not so bright as claimed..if so, then nobody
today thought to develop a
> software on the traditional structural methods...
>
> My question is what is wrong with OO ? why it did not achieved its
targets yet.?
> What are the main obstacles?
The claims were too grandiose. Software is still software; and it is still
hard. There are still bugs, still ambiguous specifications, still volatile
specifications, still improperly trained engineers, still engineers who
shouldn't be engineers, still managers who don't understand the technology
they are trying to manage, still arbitrary completion dates, etc, etc, etc.
In any case, you shouldn't be surprised when highly publicized claims are
not achieved. Generally those claims are just part of the overall hype
associated with any new idea.
The truth is: (If I may be so bold as to claim to know the truth ;)
1- OO, when properly employed, does enhance the reusability of
software. But it does so at the cost of complexity and design
time. Reusable code is more complex and takes longer to design
and implement. Futhermore, it often takes two or more tries
to create somthing that is even marginally reusable.
2- OO, when properly employed, does enhance the software's resilience
to change. But it does so at the cost of complexity and design
time. This trade off is almost always a win, but it is hard to
swallow sometimes.
3- OO does not necessarily make anything easier to understand.
There is no magical mapping between the software concepts and
every human's map of the real world. Every person is different.
What one person percieves to be a simple and elegant design, another
will percieve as convoluted and opaque.
4- If a team has been able, by applying point 1 above, to create
a repository of reusable items, then development times can begin
to shrink significantly due to reuse.
5- If a team has been able, by applying point 2 above, to create
software that is resilient to change, then maintenance of that
software will be much simpler and much less error prone.
In short. Nothing has gone wrong with OO. It is a technology, and it
delivers everything it was designed to deliver, and perhaps a bit more.
That it doesn't live up to the naive claims made by naive or insincere people
is unfortunate, but not unexpected.
>
> Is the problem with the immature OO methodologies ( OO analysis and
design in specific ) ?
No, these techniques have been a major contribution to software engineering,
and have gone a long way towards improving the way we build software.
> or is it the deficiency in the development tools used like C++ or Smalltalk ?
No, the tools are more or less adequate for the job. IMHO, someone
who blames a language for a failure should be looking a bit closer to
home for the cause.
> or is it the steep difference in thinking between the traditional and OO
schools ?
I don't think it's the steepness of the difference, although the difference
can be very steep. Instead I think that it is the disagreement by OO
authorities on the endpoint of that learning curve.
For example, some folks will tell you that the secret of OO is think of the
world in terms of objects. Others will tell you that it is to think
of the structure of the software in terms of polymorphic interfaces. Still
others will tell you that it is to decouple the domains of the problem
by describing them using macros that can be statically bound at compile time.
Which is right? Which is real? There is a *lot* of confusion out there.
That some folks might not be experiencing any of the benefits of OO does
not surprise me. (BTW, my own choice is one about structuring the software
in terms of polymorphic interfaces)
--
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
Robert C. Martin
In article <slrn5a9o60...@matilda.alt.net.au>,
ha...@matilda.alt.net.au (Harry Protoolis) wrote:
> The traditional techniques all suffered from a number of significant
> flaws. Perhaps the most damaging one was what I (rather unkindly) think
> of as 'The glorification of idiots' phenomenon. What I mean by this is
> that projects were typically infested by a group of people who never
> wrote any software, but spent most of the budget drawing diagrams that
> the implementors never used.
Much to my dismay, there are some OO methods that are promoting
the same scheme. The "analyst" draw nice pretty little diagrams, and
even run them through simulators to "prove" that they work. These
diagrams are then run through a program that generates code. Programmers
who maintain that code generator have to make sure that the "right" code
is generated. They have to make the program work.
In another case, I have worked with a client who had a bunch of
"architects" doing nothing but drawing pretty Booch diagrams and
then throwing them over the wall to a bunch of programmers. The
programmers hated the architects and ignored what they produced.
>
> In fact IMHO an OO team has no place for anyone who cannot do all
> three tasks. [Analysis, Design, and Implementation]
Agreed, emphatically.
> Jim Coplein wrote an excellent pattern called
> 'Architect also Implements' which covers very nicely the reasoning
> behind not allowing non-implementors to design systems.
Software architects who do not implement will be ignored by the
people who actually *do* implement. An architect cannot be effective
unless he/she really understands the problems that the implementors
are facing today, now, this minute.
Bill Gooch
Ell wrote:
>
> : Bill Gooch wrote:
> : >
> : > Ahmed wrote:
> : > > ....
> : > > 1 - high reusability of objects and frameworks
> : > While this may be claimed about specific frameworks, it is
> : > and important to design and implement objects which achieve
> : > immediate *reuse*, general *reusability* is quite rare, and
> : > exceedingly difficult to achieve, IME....
>
> like Window, SQLCA, MLE, SLE, etc. objects which one uses time and time
> again. Similarly with other frameworks like MFC, where one uses
Sure, there are generally reusable thingies out there,
but mostly they are either of a very generic nature (like
dialogs and documents), or they are targeted at a vertical
niche market. In either case, the effort to develop them
is much greater than that required for quality application-
specific code, and their reusability is still limited. If
you hit their limits, then you have to either extend them
at your own expense, or start from scratch. This can be a
very painful experience, depending on the circumstances (a
few years ago, I had the misfortune of needing to extend
Borland's OWL/C++ in Windows 3.1 - what a nightmare!).
The bulk of OO code does not achieve general reusability,
or any reusability at all outside of a very narrow scope.
OTOH, immediate reuse is fairly common (I'd say it's a key
characteristic of quality OO software).
Ahmed
Bill Gooch wrote:
>
> Ahmed wrote:
> > ....
> > development companies and organisations millions of pounds.
> >
> > 1 - high reusability of objects and frameworks
>
> While this may be claimed about specific frameworks, it is
> and important to design and implement objects which achieve
> immediate *reuse*, general *reusability* is quite rare, and
> outweigh the benefits.
>
> To be clear what I mean by "immediate reuse" - it is most
> often fine-grained (method and protocol level) reuse of
> behavior via inheritance, delegation, etc. which is readily
> achievable and most important. Medium-grained (class level)
> reuse is also feasible, although it requires greater design
> effort and foresight (and/or prior experience in the domain).
> Large-grained (framework level) reuse is much harder (I think
> somewhat exponentially with the number of classes/protocols/
> relationships involved), and much more rarely achieved.
>
Actually immediat reuse can be acheived to a certain extent with
the traditional structural methods if they adopted a good design
What I understand from this is that it is not convinient to reuse
objects of other applications because they are built with different
perspectives..
Does this mean,If two organizations developed almost typical applications
does not mean that the objects developed can be reusable between them..
Is not this a deficiency in OO.
Every programmer is tackling the same problem using his own perception
of the problem..his own abstraction..
The concept behind OO is that it deals with peices of software as
tangible objects exactly as real world works..however in real world
every object has a clear behaviour and perception by every body,
while in the OO software each object has a behaviour according to
the perception of his designer..!!
The problem is that many organization avoid moving toword OO because
the transfter cost to OO ( training programmers / organization change in
standards / new tools / new analysis and design methods / legacy
system/ etc. ) are much higher than the benifit of "immediate reuse"
Another point regarding inheritance, we know that Visiual Basic does not
have the capability of inheritance, however you can build a system
much faster compared to using visiual C++ with much less code.
I am not saying that we should move to the traditional structural methods
No, I have suffered enough from it, I actually like OO because of its
strong features..But I want to know why it is not moving so fast..
Regardless of the huge amout of push it got by the major players in the
software
industry..I believe that OO is still not mature enough in certain
aspects.
and this is what I am trying to find..
Cheers
Ahmed
Piercarlo Grandi
>>> "ACQ95AA" == Ahmed <ACQ...@shef.ac.uk> writes:
ACQ95AA> Hello Every Body I am a new research student working at the
ACQ95AA> field of Object Oriented Technology...I have several critical
ACQ95AA> opinions about Object Oriented in general, and I like to
ACQ95AA> participate it with you and hear you expert comments and
ACQ95AA> opinions
ACQ95AA> Object Oriented Technology came with quite promising claims
ACQ95AA> that if achieved can benefit the software development companies
ACQ95AA> and organisations millions of pounds.
ACQ95AA> Some of these claims for instance
ACQ95AA> 1 - high reusability of objects and frameworks
Of objects? What do you mean?
As to ``frameworks'', which I choose to interpret here as ``libraries of
software modules'', there is no guarantee that by using OO one _does_
achieve _high_ reusability; one _can_ achieve _higher_ reusability.
Whether higher reusability _is_ achieved depends on many factors other
than the adoption of OO technology, and whether the reusability achieved
is _high_ depends among other things on the problem domain.
That it is _possible_ to achieve _higher_ reusability with OO than other
approaches is substantiated by some sparse but compelling evidence.
ACQ95AA> 2 - Resilience to change, i.e. low software maintenance and
ACQ95AA> evolution cost
As a _possible_ consequence of _possibly_ _higher_ reuse. Again, there
is some sparse but compelling evidence that this actually happens.
ACQ95AA> 3 - Easier understanding by the user and Natural transition
ACQ95AA> between the analysis, design, implementation because they all
ACQ95AA> use tangible perceived objects.
This is not a claim in OO technology, but in OO speak, in other words it
is purely marketing hype unsubstantiated by any evidence whatsoever. You
won't find any such claim in anything but marketing drivel.
Any such claim, as you write it, is also manifestly absurd: the very
notion of something that is both "tangible perceived" is amusing to say
the least.
ACQ95AA> However the reality is not so bright as claimed..
Indeed, because most all OO-speak salesmen paint a rosy picture as you
describe it above.
OO in and by itself does not magically and necessarily "achieve" the
magic of "high reusability", and in particular because there is no
reason why the use of "tangible perceived objects" should give any
benefit like "Easier understanding by the user".
ACQ95AA> if so, then nobody today thought to develop a software on the
ACQ95AA> traditional structural methods...
Software technologies depend more on sociological than technological
factors. In particular on the twenty-year cycle of induction of new
generations of computer scientists in industry, and their reaching
``manager'' status.
ACQ95AA> My question is what is wrong with OO ? why it did not achieved
ACQ95AA> its targets yet.? What are the main obstacles?
Inflated expectations? Marketing drivel? Facile abuse of OO-speak?
Thsoe that do practice OO as a technology and not as the promise of the
age of Acquarium in CS find it a very useful concept that does deliver
some measurable benefits.
I find the discussion of OO and other issues in the second edition of
"The Mythical Man Month" a rather good argumentation of some of the
issues involved.
Ahmed
Harry Protoolis wrote:
>
> On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed <ACQ...@shef.ac.uk> wrote:
> >Hello Every Body
> >Object Oriented Technology came with quite promising claims that if achieved can
> > benefit the software
> >development companies and organisations millions of pounds.
> >
> >Some of these claims for instance
> >1 - high reusability of objects and frameworks
> >2 - Resilience to change, i.e. low software maintenance and evolution cost
> >3 - Easier understanding by the user and Natural transition between the analysis
> > , design,
> >implementation because they all use tangible perceived objects.
> >
> >However the reality is not so bright as claimed..if so, then nobody today though
> > t to develop a
> >software on the traditional structural methods...
> >
> >My question is what is wrong with OO ? why it did not achieved its targets yet.?
> >What are the main obstacles?
>
> I think this is overly negative, OO has not been and never will be a
> 'silver bullet' to solve all software development problems, but no-one
> but a few spin doctors ever claimed it would be.
>
> However, the real question should be 'has OO made a significant positive
> difference', and in my experience the answer is a resounding 'yes!'.
>
Dear Harry,
I agree with you that OO has many advantages, but I can not feel that significant improvement
as you said,
The important question is how measure the success of OO,
Can you please tell me on what crieteria you mesured this significant difference
is it
( code reusibility / software development time / software performace / software reliablity/
software cost / software portablity / ...etc .. ) these issues that count for any organization
actually I am looking for any references that compares " with figures and statistics"
between different applications developped using OO and the traditional methods.
All what I have found are examples that show OO is workable, for me this
is not an evidence to the significant difference"
Another thing, Since you are familiar with OO,
Could you please tell me what is the best environment to develop an OO application,
( in my case most of our applications are database systems )
Thank you very much
Regards,
Ahmed
Roger T.
Harry Protoolis <ha...@matilda.alt.net.au> wrote in article
<slrn5a9o60...@matilda.alt.net.au>...
> >My question is what is wrong with OO ? why it did not achieved its
targets yet.?
> >What are the main obstacles?
>
> The traditional techniques all suffered from a number of significant
> flaws. Perhaps the most damaging one was what I (rather unkindly) think
> of as 'The glorification of idiots' phenomenon. What I mean by this is
> that projects were typically infested by a group of people who never
> wrote any software, but spent most of the budget drawing diagrams that
> the implementors never used.
I agree with your thesis in general but I would like to point out that the
the glorification of idiots also included the glorification of those
implementors
that had no use at all for any high level analysis and design efforts.
There are plenty of implementors who could be called idiots for engaging in
what I call "stream of consciousness" coding.
> The main contribution of OO has been was could be termed 'The
> glorification on the implementor'. This has been achieved by the
> effective marriage of Analysis, Design and Implementation. The result
> is that every member of the team does all three of the key tasks.
This is true but the question I wonder about is how much importance and
therefore time does the implementor invest in the Analysis and Design
parts.
The most important result of OO is that it encourages the implementor to
value
these development stages more highly than he might otherwise.
Implementation is the ultimate goal and OO is a means to reach
that goal and also provide a quality product.
> In fact IMHO an OO team has no place for anyone who cannot do all
> three tasks. Jim Coplein wrote an excellent pattern called
> 'Architect also Implements' which covers very nicely the reasoning
> behind not allowing non-implementors to design systems.
Agree.
> Certainly the mecca of automatic reuse has not been achieved, but the
> quantity and quality of 3rd party components available for most OO
> languages already exceeds that available for their non-OO counterparts,
> and IHMO this suggests a bright future.
Agree.
> Certainly OO has not made writing software trivial or automatic, but
> then, *nothing ever will*.
It will make writing some ever-growing subset of software trivial or
automatic
and free us to attack more difficult coding problems.
Roger T.
Bill Gooch
Ahmed wrote:
>
> Actually immediat reuse can be acheived to a certain extent with
> the traditional structural methods if they adopted a good design
A key phrase here is "to a certain extent." OO allows
more effective reuse (less redundancy, less copy-and-edit)
than alternatives.
> What I understand from this is that it is not convinient to reuse
> objects of other applications because they are built with different
> perspectives..
I think "not convenient" is a bit of an understatement -
"very difficult" might typically be more accurate.
> Does this mean,If two organizations developed almost typical applications
> does not mean that the objects developed can be reusable between them..
> Is not this a deficiency in OO.
As compared to what? Non-OO software? I think not.
Two different automobile designs rarely share any
compatible parts (except those which are industry-
standardized, like oil filters), unless the designers
worked together with that goal in mind.
> Every programmer is tackling the same problem using his own perception
> of the problem..his own abstraction..
Yes, and the alternative is?...
> The concept behind OO is that it deals with peices of software as
> tangible objects exactly as real world works..
Not at all. "How the real world works" is by no means
obvious or well understood ("real world" in itself is
an exceedingly vague term), and you'd need to provide
some definitions of these things, as well as evidence
to support the above assertion.
> however in real world
> every object has a clear behaviour and perception by every body,
Not in the slightest.
> while in the OO software each object has a behaviour according to
> the perception of his designer..!!
Sometimes. The designer probably hopes it does.
> The problem is that many organization avoid moving toword OO because
> the transfter cost to OO ( training programmers / organization change in
> standards / new tools / new analysis and design methods / legacy
> system/ etc. ) are much higher than the benifit of "immediate reuse"
OK - why is this a problem?
> Another point regarding inheritance, we know that Visiual Basic does not
> have the capability of inheritance, however you can build a system
> much faster compared to using visiual C++ with much less code.
Depends what system, doesn't it? VB isn't ideal for
all computer applications; C++ is probably a better
choice for at least some of them.
> I am not saying that we should move to the traditional structural methods
> No, I have suffered enough from it, I actually like OO because of its
> strong features..But I want to know why it is not moving so fast..
Patience is a virtue. Rapid growth and early acceptance
can lead to backlash and equally rapid decline.
Dr. Richard Botting
(Followups trimmed to comp.object and comp.software-eng)
Robert C. Martin (rma...@oma.com) wrote:
: In another case, I have worked with a client who had a bunch of
: "architects" doing nothing but drawing pretty Booch diagrams and
: then throwing them over the wall to a bunch of programmers. The
: programmers hated the architects and ignored what they produced.
Software people have four traditional ways of handling any problems:
(1) ignore it
(2) invent a tool
(3) try to be methodical
(4) define your program to be the solution and standardize it.
OO seems to have inheritted these virtual methods.
(HHOS)
--
dick botting http://www.csci.csusb.edu/dick/signature.html
Disclaimer: CSUSB may or may not agree with this message.
Copyright(1996): Copy freely but say where it came from.
I have nothing to sell, and I'm giving it away.
Joe Winchester
Harry Protoolis wrote:
> In fact IMHO an OO team has no place for anyone who cannot do all
> three tasks. Jim Coplein wrote an excellent pattern called
> 'Architect also Implements' which covers very nicely the reasoning
> behind not allowing non-implementors to design systems.
Harry,
Do you know where I might be able to get hold of Coplien's pattern.
Regards,
--
Joe Winchester
Jo...@concentric.net
103276,2...@Compuserve.com
Matthew Gream
Hi Ahmed,
On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed (ACQ...@shef.ac.uk) wrote:
> Object Oriented Technology came with quite promising claims that if
> achieved can benefit the software development companies and
> organisations millions of pounds.
OO is no different from many other technologies. It comes with many
promises, and it can fulfill these if used in the right situations in
the right way. It is not a panacea, which is not a new or surprising
statement.
When you consider "Object Oriented Technology", you must also consider
Domain Analysis, Architecture, Patterns and other lifecycle goodies
which are not inherently Object Oriented, but seem to be a necessary
requirement for successful OO benefits.
> Some of these claims for instance
> 1 - high reusability of objects and frameworks
This can be achieved, but it requires discipline, investment and
experience. Discpline to work hard towards reusability, and to
maintain that reusability (though evolution). Investment in terms of
the effort involved to establish generic solutions (generic solutions
are generally [:-)] much harder than specific solutions). Experience
to make the correct decisions when constructing re-usable items (to
have some degree of visibility).
> 2 - Resilience to change, i.e. low software maintenance and evolution cost
How flexible is the software? This has a lot to do with architecture:
"if you don't get the architecture right up front, you may as well pack
up and go home" [quote made by a fellow engineer]. The architecture in
many ways predicts what will happen to the software over its
lifecycle. If you don't get this right, you will need to change the
architecture: this is usually not a trivial task. This is not exclusively
an OO issue though.
OO includes inheritence. This promotes generalisation -- factoring out
commonalities -- which reduces dependencies. Reduction in dependencies
makes maintenance and evolution more predictable and cheaper. It is
perhaps predictability that is more important than anything, better to
correctly assess that all the costs are high up front, before starting,
rather than finding out later.
There are also CASE tools, which make evolution and maintenance much
easier and achievable (they also keep you focused at a higher level of
logic). Having a CASE tool take care of menial details (file
organisation, includes, class definitions, method stubs, etc) and take
over some of the verification roles (use cases and scenarios) is very
important. Though, CASE tools are not inherently an OO thing.
There are probably many more items you can mention here as well.
> 3 - Easier understanding by the user and Natural transition between the analysis, design,
> implementation because they all use tangible perceived objects.
The transition is definitely a good thing. Being able to iteratively
build software is much more predictable as well. What you've said seems
to be much easier to say that to do, from the experience I've seen
around me. Getting the right architecture and objects up front requires
experience (and therefore, knowledge). It also requires an appropriate
balance between the actual system requirements, the system domain and
other domains. This requires time and experience.
> However the reality is not so bright as claimed..if so, then nobody today thought to develop a
> software on the traditional structural methods...
> My question is what is wrong with OO ? why it did not achieved its targets yet.?
> What are the main obstacles?
I would say that it is slowely acheiving its targets and that there are
three main inter-related obstacles: time, experience and collaboration.
We need more of these to help the overall feedback loop.
> Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ?
> or is it the deficiency in the development tools used like C++ or Smalltalk ?
> or is it the steep difference in thinking between the traditional and OO schools ?
> or is it related with the difficulty of object classification ?
> or is it because of vast legacy systems done using the traditional methods ?
> or is a combination of many other factors...?
All of these would seem to be problems from my, limited, experience. The
thinking "mindset" is perhaps one of the most important.
> I know that giving a precise answer is very difficult for such a complex question, but I like to
> hear the comments of people working at the feild and who suffered from many difficulties..
> I would really appreciate any participation, response or even leading to a good reference ,
> and would be very grateful if the opinions are supported by some evidences...
You want evidence ? I need more experience :-). Please excuse my bias
towards architecture in the above as well, I think that architecture
and organisation are very important. Architecture is everywhere, from
the big to the small (in the software, in the process, in the people,
in the organisation, etc). Most of the software problems I have
encountered can be traced back to architectural issues of one form or
another.
Cheers,
Matthew.
--
Email: Matthe...@Jtec.com.au
Phone: (02) 390-0194
Fax: (02) 364-0055
Post: Jtec (R&D) Pty Ltd.
Unit 3, 118-122 Bowden St.
Meadowbank NSW 2114.
Tom Bushell
On Wed, 04 Dec 1996 08:45:22 -0600, rma...@oma.com (Robert C. Martin)
wrote:
>ha...@matilda.alt.net.au (Harry Protoolis) wrote:
>
>> The traditional techniques all suffered from a number of significant
>> flaws. Perhaps the most damaging one was what I (rather unkindly) think
>> of as 'The glorification of idiots' phenomenon. What I mean by this is
>> that projects were typically infested by a group of people who never
>> wrote any software, but spent most of the budget drawing diagrams that
>> the implementors never used.
>
>Much to my dismay, there are some OO methods that are promoting
>the same scheme. The "analyst" draw nice pretty little diagrams, and
>even run them through simulators to "prove" that they work. These
>diagrams are then run through a program that generates code. Programmers
>who maintain that code generator have to make sure that the "right" code
>is generated. They have to make the program work.
It is my growing opinion that this is a fundamental problem with all
"formal" design methods, not just OO design. The effort involved in
doing the design is as great or greater than doing the construction
(coding). Contrast this with doing the blueprints for a bridge - the
design effort is orders of magnitude cheaper than the construction.
(Or so I believe - a civil engineer might correct me on this). Also,
the OO design models I've studied don't seem to be very good maps of
actual real world systems - there seems to be a big gap between high
level architecture and running code. I believe there should be a
fairly smooth continuim from high level to low level of detail.
I'm starting to believe that design and code don't make sense as
separate entities - the design should _become_ the code - the design
documents for an implemented system are used as the foundation of the
code, and then regenerated from the code. Major benefits would be
that design work would not be discarded because it was too difficult
to bring it up to date with reality. Therefore, the design should
never get out of synch. This a similar idea to reverse engineering,
but not identical.
If anyone has knows of tools that would facilitate this approach, I'd
certainly be interested. I've done some very simple prototypes, and
hope to work on the idea in future (when I have more time - Hah!).
-Tom
----------------------------------------------------------
Tom Bushell * Custom Software Development
Telekinetics * Process Improvement Consulting
2653 Highway 202 * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772 Email: tbus...@fox.nstn.ns.ca
----------------------------------------------------------
Ell
Bill Gooch (bi...@iconcomp.com) wrote:
: Ahmed wrote:
: >
: > Actually immediat reuse can be acheived to a certain extent with
: > the traditional structural methods if they adopted a good design
: A key phrase here is "to a certain extent." OO allows
: more effective reuse (less redundancy, less copy-and-edit)
: than alternatives.
: > What I understand from this is that it is not convinient to reuse
: > objects of other applications because they are built with different
: > perspectives..
: I think "not convenient" is a bit of an understatement -
: "very difficult" might typically be more accurate.
In my experience, and observations, it is not "cross application" reuse
of classes/objects that is a problem as much as it is "cross environment"
reuse of classes/objects. Especially wrt physical design reuse. I.e.
getting classes/objects to physically work across different environments
is difficult indeed.
: Two different automobile designs rarely share any
: compatible parts (except those which are industry-
: standardized, like oil filters), unless the designers
: worked together with that goal in mind.
: > Every programmer is tackling the same problem using his own perception
: > of the problem..his own abstraction..
: Yes, and the alternative is?...
Relying on domain experts for fundamental application semantics and as
well relying on domain experts to determine implementation necessaries for
application use. Relying on domain experts for implementation of Use
Cases.
: > The concept behind OO is that it deals with peices of software as
: > tangible objects exactly as real world works..
Yes! Well not *exactly* as the real world operates, but in a way that
utilizes, and is anchored upon "real world" domain abstractions,
patterns, and semantics.
: Not at all. "How the real world works" is by no means
: obvious or well understood ("real world" in itself is
: an exceedingly vague term), and you'd need to provide
: some definitions of these things, as well as evidence
: to support the above assertion.
If we grasp, as in you have alluded to in many of your previous posts that
development should start with understanding domain abstractions and
relationships how is that different from basing project analysis and
architecture on "tangible objects exactly as the real world operates".
: > however in real world
: > every object has a clear behaviour and perception by every body,
: Not in the slightest.
The perception of object behavior ranges in various cases between being
very clear to all to only discernable to a handful.
: > while in the OO software each object has a behaviour according to
: > the perception of his designer..!!
: Sometimes. The designer probably hopes it does.
Yes, the pragmatists and empiricists hope that they can do whatever they
want to analysis and physical design based on their narrow inclinations.
In actuality there is an objective reality (or at the very least objective
human conception) behind what goes on in an application and its domain
that developers should attempt to model as closely as possible.
: > The problem is that many organization avoid moving toword OO because
: > the transfter cost to OO ( training programmers / organization change in
: > standards / new tools / new analysis and design methods / legacy
: > system/ etc. ) are much higher than the benifit of "immediate reuse"
: OK - why is this a problem?
Because "immediate reuse" should not be the only, or main criteria by
which an organization adopts one development paradigm or another (e.g. OO
vs. others), as I see it.
: > I am not saying that we should move to the traditional structural methods
: > No, I have suffered enough from it, I actually like OO because of its
: > strong features..But I want to know why it is not moving so fast..
Seems pretty fast to me. From what I read in most literature in the
computer field, or area, OO is de rigeur - virtually the only thing being
talked about as a development paradigm. That is even in the mainframe
world.
: Patience is a virtue. Rapid growth and early acceptance
: can lead to backlash and equally rapid decline.
Excelsior! As quickly as possible! OO has at least nearly 30 years of
growth.
Elliott
Ell
Tom Bushell (tbus...@fox.nstn.ns.ca) wrote:
: rma...@oma.com (Robert C. Martin) wrote:
: >
: >ha...@matilda.alt.net.au (Harry Protoolis) wrote:
: >>
: >> The traditional techniques all suffered from a number of significant
: >> flaws. Perhaps the most damaging one was what I (rather unkindly) think
: >> of as 'The glorification of idiots' phenomenon. What I mean by this is
: >> that projects were typically infested by a group of people who never
: >> wrote any software, but spent most of the budget drawing diagrams that
: >> the implementors never used.
: >Much to my dismay, there are some OO methods that are promoting
: >the same scheme. The "analyst" draw nice pretty little diagrams, and
: >even run them through simulators to "prove" that they work. These
: >diagrams are then run through a program that generates code. Programmers
: >who maintain that code generator have to make sure that the "right" code
: >is generated. They have to make the program work.
: It is my growing opinion that this is a fundamental problem with all
: "formal" design methods, not just OO design. The effort involved in
: doing the design is as great or greater than doing the construction
: (coding).
Even if "doing" good OO analysis (drawing "nice pretty little diagram" and
*much* more) cost more time and dollars than OO coding, it pays off
because doing good OO analysis is generally decisive to the most rapid and
Use Case effective development of the project.
: I'm starting to believe that design and code don't make sense as
: separate entities - the design should _become_ the code - the design
: documents for an implemented system are used as the foundation of the
: code, and then regenerated from the code.
And if you think about it, the only real way for what you call "design" to
"become" the code is if a perspective larger than being mainly focused on
physical coding *leads* physical coding.
: Major benefits would be
: that design work would not be discarded because it was too difficult
: to bring it up to date with reality. Therefore, the design should
: never get out of synch.
This is precisely the approach of Booch/Coad/Jacobson/Rumbaugh from what I
know about their methods. Physical design and coding is based on/rooted
in analysis concepts. Physical design and coding are simply additive to
the analysis models.
Elliott
Brian Gridley
>: > Every programmer is tackling the same problem using his own perception
>: > of the problem..his own abstraction..
>
>: Yes, and the alternative is?...
>
Communication, teams, and a development environment 2 steps beyond ENVY.
If all the code that has been written in various shops became available to the
general developing public within 3 months of it's creation, we would have spent
far less time repeating ourselves, and have the most robust development
environment and reuseable code, and have eliminated all other language
competitors (not ST-based). Instead, we are still all solving the same problems
, over and over again. Is anyone interested in building a communal repository
with a system for charging users and rewarding developers for code?
Marnix Klooster
tbus...@fox.nstn.ns.ca (Tom Bushell) wrote:
> It is my growing opinion that this is a fundamental problem with all
> "formal" design methods, not just OO design. The effort involved in
> doing the design is as great or greater than doing the construction
> (coding). Contrast this with doing the blueprints for a bridge - the
> design effort is orders of magnitude cheaper than the construction.
> (Or so I believe - a civil engineer might correct me on this). Also,
> the OO design models I've studied don't seem to be very good maps of
> actual real world systems - there seems to be a big gap between high
> level architecture and running code. I believe there should be a
> fairly smooth continuim from high level to low level of detail.
Couldn't agree with you more.
> I'm starting to believe that design and code don't make sense as
> separate entities - the design should _become_ the code - the design
> documents for an implemented system are used as the foundation of the
> code, and then regenerated from the code. Major benefits would be
> that design work would not be discarded because it was too difficult
> to bring it up to date with reality. Therefore, the design should
> never get out of synch. This a similar idea to reverse engineering,
> but not identical.
One approach in the direction you sketch is the formal method
called the "refinement calculus". Essentially, a (formal)
specification is considered to be a very high-level
non-executable program, and programming tries to `refine' that
program to an equivalent one that is executable. The refinement
calculus gives formal proof rules with which refinements can be
proven correct. Therefore, the side-effect of developing a
program this way is a proof that it meets its specification. In
other words, we have a `provably correct program.'
> If anyone has knows of tools that would facilitate this approach, I'd
> certainly be interested. I've done some very simple prototypes, and
> hope to work on the idea in future (when I have more time - Hah!).
Because of the emphasis on proof, the refinement calculus
requires more mathematical skills of the programmer than other
methods. Also, for larger programs having some kind of proof
support tool is a necessity. Finally, it often happens that the
specification must be changed halfway. With proper tool support
it should be easy to check which refinements still hold, and
which don't. Such tools are under development; try the "Formal
methods" web page at
http://www.comlab.ox.ac.uk/archive/formal-methods.html
If you want to know more on the refinement calculus, you could
begin with Carroll Morgan, "Programming from Specifications",
Second Edition, Prentice-Hall, 1994, ISBN 0-13-123274-6.
> -Tom
Groetjes,
<><
Marnix
--
Marnix Klooster | If you reply to this post,
mar...@worldonline.nl | please send me an e-mail copy.
Richie Bielak
Matthew Gream wrote:
[...]
> How flexible is the software? This has a lot to do with architecture:
> "if you don't get the architecture right up front, you may as well pack
> up and go home" [quote made by a fellow engineer].
These kinds of statements always bother me. How are you supposed to
know that the architecture (or design for that matter) is right?
The only way I see is to implement it and see how it works. That's
why the iterative software development makes sense, you get to try
out out your ideas in practice and adjust them as needed.
...richie
--
* ric...@netlabs.net - at home | Richie Bielak *
* ric...@calfp.com - at work | *
* Home page: http://www.netlabs.net/hp/richieb *
* "The network is not the computer, the network is the bus." (me) *
Tim Ottinger
Matthew Gream wrote (And all in all, a thoughtful posting):
[in response to question:]
> > 2 - Resilience to change, i.e. low software maintenance and evolution cost
>
> How flexible is the software? This has a lot to do with architecture:
> "if you don't get the architecture right up front, you may as well pack
> up and go home" [quote made by a fellow engineer]. The architecture in
> many ways predicts what will happen to the software over its
> lifecycle. If you don't get this right, you will need to change the
> architecture: this is usually not a trivial task. This is not exclusively
> an OO issue though.
By the way, while this is "essentially" right, there are plenty of cases
where people did not build the correct architecture the first time out.
In fact, many of us will tell you that it's nigh impossible to build it
right the first time out if the software project is interesting enough.
The iterative incremental model ain't perfect, but using short cycles
and daring to revisit can cover an awful lot of design sins. If you
commit to an architecture, then you're probably stuck.
I propose the motto "design by distrust!". If the work is suitably
isolated from the physical and business requirements, then you can
reliably insulate yourself from those things you don't believe will
be invariant, even if you don't know which direction they'll go in.
Of course, this *is* your next point, but I wanted to stress that
it's not a top-down thing, and the process is not completely
unforgiving. Otherwise, we'd be better off outside of OO for large
projects.
The architecture thing, even the business model, can be essentially
right and correctably wrong, and sometimes it's a close to perfection
as you'll get. Especially early on in a project.
> OO includes inheritence. This promotes generalisation -- factoring out
> commonalities -- which reduces dependencies. Reduction in dependencies
> makes maintenance and evolution more predictable and cheaper. It is
> perhaps predictability that is more important than anything, better to
> correctly assess that all the costs are high up front, before starting,
> rather than finding out later.
Design by distrust! Estimate by distrust!
> > Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ?
> > or is it the deficiency in the development tools used like C++ or Smalltalk ?
> > or is it the steep difference in thinking between the traditional and OO schools ?
> > or is it related with the difficulty of object classification ?
> > or is it because of vast legacy systems done using the traditional methods ?
> > or is a combination of many other factors...?
>
> All of these would seem to be problems from my, limited, experience. The
> thinking "mindset" is perhaps one of the most important.
To begin with, I don't accept the idea that there is a "problem".
I'll talk about that in a second.
Secondly, I think that the difference in thinking between OO and
structured is a matter of breaking mental habits, not the deep and
nearly incrossible chasm people make it out to be. We have people
who jump from COBOL to C++ and OO in one great leap. We have a
number of people who came from procedural 4GLs to OO. It happens
very frequently, maybe every week or every day all over the world
with thousands and thousands of people.
A lot of the "problem" is with organizations. If they've been
successful
to any degree with other methods (including brute force) then they are
unlikely to "mess with the formula" by going into OO. A lot of people
still use Fortranm, COBOL, RPG, etc., successfully - untouched by the
Client/Server revolution, CASE, even RDBMS. No person or company is
obliged to stay "technically current", and so many will not. And they
might do fine at it.
The fact of the matter is that OO is a change in management and project
planning as much as anything else, and a lot of managers aren't too
keen on having their world ripped out from under them. That's just
an education thing. It'll come in time, but the focus on managing
OO is fairly recent in the scheme of things.
There's an underlying myth of the question which was originally asked.
"If method A is good, then why does anybody do anything else", or
"If some people don't use A, then it must not be very good".
If I asked "If software is a good career, then why do some people
still raise crops?" you might laugh. Software is not for every-
body. For that matter, you know that managers and financial people
make more money than programmers, so whats wrong with you that you
don't go into management instead? Well, maybe programming is fine
for you. Maybe that money benefit isn't all that important to you.
Does that mean that managers *don't* make more money?
Likewise OO. It's not a winner-take-all battle with the rest
of the DP world. It doesn't have to be popular, and it doesn't
have to be used exclusively by all software companies in order
to work.
It's just a set of mental tools you can use if you want the
benefits it can provide.
Some people are gung-ho, some are skeptical, some don't care. And
they have that right.
--
Tim
********************************************************************
In some sense, all of life is design. The way we pick our friends,
the way we plant a garden, and the way we choose software is all
design. Sometimes we do things by habit, other times by carefully
weighing the pros and cons, and sometimes we make experiments.
-- Ralph Johnson --
Ralph Cook
Richie Bielak wrote:
> Matthew Gream wrote:
> > How flexible is the software? This has a lot to do with architecture:
> > "if you don't get the architecture right up front, you may as well pack
> > up and go home" [quote made by a fellow engineer].
>
> know that the architecture (or design for that matter) is right?
>
> The only way I see is to implement it and see how it works. That's
> why the iterative software development makes sense, you get to try
> out out your ideas in practice and adjust them as needed.
>
> ...richie
No. That just makes "iterative software development" an excuse
not to design. We already know that coding before you design
and designing before you know what you are supposed to implement
lead to expensive rework and their attendant blown schedules,
buggy software, and poor quality products.
To 'know' that an architecture or a design is going to work, you have
to study it, think about it, step through it, argue it with other
people who understand the problem and that level of the design, etc.
There are some methods for automating this; if they fit, use them.
But often you just have to sit back and look at it (figuratively
or literally) and say "what if this happens? what if that happens?"
Without some kind of automation, it isn't like the code -- you cannot
"run" it and see if the machine checks or the OS or the runtime blow up.
But you CAN figure out if the design is workable, and you had better
if you want some assurance your project will succeed.
rc
--
When I DO speak for a company, I list my title and use "We".
Russell Corfman
It's in the proceedings from the PLoP-94 conference. The
proceedings are published by Addison-Wesley in the book
"Pattern Languages of Program Design" edited by
Coplien and Schmidt, ISBN 0-201-60734. Most good book stores
should have it and the PLoPD2 book from PLoP-95.
I believe there is a copy on the web that is reachable
from Coplien's homepage http://www.bell-labs.com/people/cope/
look for "organizational and process patterns"
Russell Corfman
corf...@agcs.com
In article <32A65E...@concentric.net>,
Bill Gooch
[followups trimmed]
Ell wrote:
>
> Bill Gooch (bi...@iconcomp.com) wrote:
> : Ahmed wrote:
> : ....
> : > Every programmer is tackling the same problem using his own perception
> : > of the problem..his own abstraction..
>
> : Yes, and the alternative is?...
>
> Relying on domain experts for fundamental application semantics and as
> well relying on domain experts to determine implementation necessaries for
> application use.
Fair enough. Also I would have said "sharing explicit
models among all interested parties" to avoid problems
that often arise due to miscommunication (or lack of
comunication).
> Relying on domain experts for implementation of Use Cases.
I'm not sure what "implementation of use cases" means
here - can you explain? I'm more familiar with the idea
of software analysts and designers implementing things
based on what they hear from domain experts and users.
> : > The concept behind OO is that it deals with peices of software as
> : > tangible objects exactly as real world works..
>
> Yes! Well not *exactly* as the real world operates, but in a way that
> utilizes, and is anchored upon "real world" domain abstractions,
> patterns, and semantics.
>
> : Not at all. "How the real world works" is by no means
> : obvious or well understood ("real world" in itself is
> : an exceedingly vague term), and you'd need to provide
> : some definitions of these things, as well as evidence
> : to support the above assertion.
>
> If we grasp, as in you have alluded to in many of your previous posts that
> development should start with understanding domain abstractions and
> relationships how is that different from basing project analysis and
> architecture on "tangible objects exactly as the real world operates".
Fine, all except for the quote, which I can't interpret in
a way that I'm comfortable with. Ill-defined terms combining
to form what looks to me like total nonsense. I can't answer
your question, because I don't know what the quote is trying
to say (your explanation is one of numerous possibilities).
> : > while in the OO software each object has a behaviour according to
> : > the perception of his designer..!!
>
> : Sometimes. The designer probably hopes it does.
>
> Yes, the pragmatists and empiricists hope that they can do whatever they
> want to analysis and physical design based on their narrow inclinations.
If you say so. (Here I have a strange unpleasant feeling of
deja vu.)
> In actuality there is an objective reality (or at the very least objective
> human conception) behind what goes on in an application and its domain
> that developers should attempt to model as closely as possible.
In actuality that is just one opinion. I'm curious,
though: what is "objective human conception?"
> : > The problem is that many organization avoid moving toword OO because
> : > the transfter cost to OO ( training programmers / organization change in
> : > standards / new tools / new analysis and design methods / legacy
> : > system/ etc. ) are much higher than the benifit of "immediate reuse"
>
> : OK - why is this a problem?
>
> Because "immediate reuse" should not be the only, or main criteria by
> which an organization adopts one development paradigm or another (e.g. OO
> vs. others), as I see it....
Good. What in your opinion are some other important criteria?
Actually my question was more about why it matters in general
whether or not "many organizations avoid moving toward OO."
But I like your answer, even if it's responding to a slightly
different question.
Bill Gooch
Brian Gridley wrote:
>
[ Ahmed wrote: ]
> >: > Every programmer is tackling the same problem using his own perception
> >: > of the problem..his own abstraction..
> >
> >: Yes, and the alternative is?...
> >
Good. Can you say a bit more about this?
> If all the code that has been written in various shops became available to the
> general developing public within 3 months of it's creation, we would have spent
> far less time repeating ourselves, and have the most robust development
> environment and reuseable code, and have eliminated all other language
> competitors (not ST-based).
I don't think so (especially about the part in parens,
since Smalltalk environments aren't clearly superior
to all others - superior to most, yes).
> Instead, we are still all solving the same problems
> , over and over again. Is anyone interested in building a communal repository
> with a system for charging users and rewarding developers for code?
We're working on it. Stay tuned.
Daniel Drasin
Ahmed wrote:
>
> Hello Every Body
>
> critical opinions about Object Oriented in general, and I like to participate it with you and hear
> you expert comments and opinions
>
> Object Oriented Technology came with quite promising claims that if achieved can benefit the software
> development companies and organisations millions of pounds.
>
> 1 - high reusability of objects and frameworks
> implementation because they all use tangible perceived objects.
>
> software on the traditional structural methods...
>
> My question is what is wrong with OO ? why it did not achieved its targets yet.?
> What are the main obstacles?
>
The problems I've seen with OO projects arise not from the use of OO,
but from the misuse of OO. Programmers trying to use non-OO methods,
incorrectly applying OO concepts, etc. This is a result of a lack of
OO teaching at eductational institutions. Even schools that offer
1 or 2 OO language courses usually fail to educate; they use C++
and only really teach the "C" part. There are very few
universities that make an effort to inculcate students with an
understanding of OO techiniques and methods. So it's no wonder
when these graduates try to apply them in the "real world," they
get all fouled up.
Dan
--
Daniel Drasin Applied Reasoning
dra...@arscorp.com 2840 Plaza Place, Suite 325
(919)-781-7997 Raleigh, NC 27612
http://www.arscorp.com
Dr. Richard Botting
Richie Bielak (ric...@calfp.com) wrote:
: Matthew Gream wrote:
: [...]
: > How flexible is the software? This has a lot to do with architecture:
: > "if you don't get the architecture right up front, you may as well pack
: > up and go home" [quote made by a fellow engineer].
: These kinds of statements always bother me. How are you supposed to
: know t