The Principles of OOD
Librarian
>From: rma...@rcmcon.com (Robert Martin)
>Subject: The Principles of OOD
>Date: Tue, 6 Jun 1995 04:56:38 GMT
>I am in the midst of working on my next book: "The Principles and Patterns
>of Object Oriented Design". As part of that exercize, I have been compiling
>a set of principles, some of which I posted to comp.object several months
>back. They are included at the end of this posting.
>Over the next few weeks I will be posting articles that expound upon
>each of the principles in turn. My object, of course, is to present these
>principles to the OO community and get some early feedback and reviews for
>my book.
>I'll post an article about the first principle in a subsequent posting.
> 1. Software entities (classes, modules, etc) should be open for
> extension, but closed for modification. (The open/closed
> principle -- Bertrand Meyer)
Nyet. I see your C++and Eiffel background showing through, Robert. You are
assuming that the designer of a class is omniscient and perfect. That's a
crock. Class designers make mistakes, sometimes bad ones. In the Smalltalk
world everyone except IBM believes that source code should be open to all
developers. In this manner, we can repair a badly factored class, or fix bugs
that we can't wait for the class developer (usually a vendor) to get around to.
> 2. Derived classes must usable through the base class interface
> without the need for the user to know the difference. (The
> Liskov Substitution Principle)
Good assumption.
> 3. Details should depend upon abstractions. Abstractions should
> not depend upon details. (Principle of Dependency Inversion)
This one will need lots of explanation. I think I understand what you're
saying, but I think you could say it more clearly.
> 4. The granule of reuse is the same as the granule of release.
> Only components that are released through a tracking system can
> be effectively reused.
That's a good principle, in general. However, the granule of reuse can, in my
experience be SMALLER than the granule of release. I can always choose to
ignore parts of a framework, or to use only part of a classes protocol.
> 5. Classes within a released component should share common closure.
> That is, if one needs to be changed, they all are likely to need
> to be changed. What affects one, affects all.
What? Doesn't that sort of kill the idea of encapsulation? Changes to one
class should NEVER affect another class, unless you are changing the meaning
or implementation of the public protocol of that class. You should be able to
extend a classes public protocol without affecting any other class as well.
> 6. Classes within a released componen should be reused together.
> That is, it is impossible to separate the components from each
> other in order to reuse less than the total.
Nyet, Nein, Nix. Let's take a simple example from the MVC framework from
Smalltalk. I can easily decide that I want to write an interface that
displays a graph, but does not allow changes to the graph. In this case, I
need a Model, and a View, but not a Controller.
You are assuming, again that framework and class designers are omniscient.
That will get you into trouble!
> 7. The dependency structure for released components must be a DAG.
> There can be no cycles.
ABSOLUTELY! In Smalltalk, ENVY/DEVELOPER (the most common CM system) makes
the assumption that this is true, but unfortunately, there are ways to break
it by creating cycles. Boy does that give you headaches!
> 8. Dependencies between released components must run in the
> direction of stability. The dependee must be more stable than
> the depender.
Agreed.
> 9. The more stable a released component is, the more it must
> consist of abstract classes. A completely stable component
> should consist of nothing but abstract classes.
NO, NO, NO. There are two basic types of reuse. The first kind is the kind
you are assuming, which is that you will create new components by customizing
old ones. However, another, perfectly valid type of reuse is the "toolkit"
approach that consists of taking concrete components and recombining them in
new and interesting ways. This is how most window-builder products work,
regardless of the language.
See Ralph Johnson's "Designing Reusable Classes" and "Reusing Object-Oriented
Designs", both on st.cs.uiuc.edu, for more information on the distinction.
> 10. Where possible, use proven patterns to solve design problems.
AMEN, and AMEN.
> 11. When crossing between two different paradigms, build an
> interface layer that separates the two. Don't pollute one side
> with the paradigm of the other.
Terrific, but I would move it up the ladder to emphasize its importance.
Good overall, but I think you need to go back and rethink some of the basic
assumptions you're working from.
Kyle Brown
Senior Member, Technical Staff
Knowledge Systems Corp.
kbr...@ksccary.com
>--
>Robert Martin | Design Consulting | Training courses offered:
>Object Mentor Assoc.| rma...@rcmcon.com | Object Oriented Analysis
>2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design
>Green Oaks IL 60048 | Fax: (708) 918-1023 | C++
Patrick Logan
: > 1. Software entities (classes, modules, etc) should be open for
: > extension, but closed for modification. (The open/closed
: > principle -- Bertrand Meyer)
: Nyet. I see your C++and Eiffel background showing through, Robert. You are
: assuming that the designer of a class is omniscient and perfect. That's a
: crock. Class designers make mistakes, sometimes bad ones. In the Smalltalk
: world everyone except IBM believes that source code should be open to all
: In this manner, we can repair a badly factored class, or fix bugs...
Robert's point and Librarian's point are "orthogonal", if you will.
The Open/Closed Principle has nothing to do with source code availability
or badly designed classes. It is a *design* principle for designing
a method for an abstraction that can be reused by every implementation
without modification.
To illustrate that this is language independent (I could say you're
showing your ignorance, Librarian), here is an example from Smalltalk...
Collection>>collect: aBlock
| answer |
answer := self species new: self size.
self do:
[ :each |
answer add: (aBlock value: each)].
^answer
This method follows the open/closed principle. It is desirable to
have methods like this because they only have to be written once,
but they can be used by every subclass. (In this case, all subclasses
of Collection will have a working implementation of collect:
for free and the method will never have to be modified.
--
Patrick...@ccm.jf.intel.com
Intel/Personal Conferencing
"Form follows function." -Le Corbusier
David Karr
In article <1995Jun6....@rcmcon.com> rma...@rcmcon.com (Robert Martin) writes:
Robert> 1. Software entities (classes, modules, etc) should be open for
Robert> extension, but closed for modification. (The open/closed
Robert> principle -- Bertrand Meyer)
Robert> 2. Derived classes must usable through the base class interface
Robert> without the need for the user to know the difference. (The
Robert> Liskov Substitution Principle)
Robert> 3. Details should depend upon abstractions. Abstractions should
Robert> not depend upon details. (Principle of Dependency Inversion)
Robert> 4. The granule of reuse is the same as the granule of release.
Robert> Only components that are released through a tracking system can
Robert> be effectively reused.
Robert> 5. Classes within a released component should share common closure.
Robert> That is, if one needs to be changed, they all are likely to need
Robert> to be changed. What affects one, affects all.
Robert> 6. Classes within a released componen should be reused together.
Robert> That is, it is impossible to separate the components from each
Robert> other in order to reuse less than the total.
Robert> 7. The dependency structure for released components must be a DAG.
Robert> There can be no cycles.
Robert> 8. Dependencies between released components must run in the
Robert> direction of stability. The dependee must be more stable than
Robert> the depender.
Robert> 9. The more stable a released component is, the more it must
Robert> consist of abstract classes. A completely stable component
Robert> should consist of nothing but abstract classes.
Robert> 10. Where possible, use proven patterns to solve design problems.
Robert> 11. When crossing between two different paradigms, build an
Robert> interface layer that separates the two. Don't pollute one side
Robert> with the paradigm of the other.
My first comment would be that these are all very salient and
important points, and they are all very familiar to me, as you covered
all of them very well in your last book "Designing Object-Oriented C++
Applications Using the Booch Method". I'm not quite sure what else
you could add to these principles. It might be more valuable to
publish a catalog of case studies of applications of these principles.
--
============================================================================
David M. Karr | Unix/X/C++/Emacs | GTE - Government Systems
dk...@nmo.gtegsc.com | Software Engineer | w:(206)487-8578 h:(206)483-1732
dk...@eskimo.com | |
Orpheus
David Karr <dk...@nmo.gtegsc.com> wrote:
>>>>>> "Robert" == Robert Martin <rma...@rcmcon.com> writes:
>In article <1995Jun6....@rcmcon.com> rma...@rcmcon.com (Robert Martin) writes:
>
>It might be more valuable to
>publish a catalog of case studies of applications of these principles.
Yeah. Theory is great, but good, substantative examples are rare.
Here's my idea, if I were going to write a book, I would write:
Examples of Object Oriented Designs and their
Implementations from the Real World.
Such a book would start with simple examples and evolve, chapter
by chapter, into more complex or more specialized applications
showing how the design lead to the implementation, illustrating
design tradeoffs, showing how constraints affect the "purity" of
the implementation, etc.
(There! Now that I have revealed my idea, if anyone writes the
book, I get royalties! :) )
:-t
--
"Groove is in the heart..."
Robert Martin
of Object Oriented Design". As part of that exercize, I have been compiling
a set of principles, some of which I posted to comp.object several months
back. They are included at the end of this posting.
Over the next few weeks I will be posting articles that expound upon
each of the principles in turn. My object, of course, is to present these
principles to the OO community and get some early feedback and reviews for
my book.
I'll post an article about the first principle in a subsequent posting.
1. Software entities (classes, modules, etc) should be open for
extension, but closed for modification. (The open/closed
principle -- Bertrand Meyer)
2. Derived classes must usable through the base class interface
without the need for the user to know the difference. (The
Liskov Substitution Principle)
3. Details should depend upon abstractions. Abstractions should
not depend upon details. (Principle of Dependency Inversion)
4. The granule of reuse is the same as the granule of release.
Only components that are released through a tracking system can
be effectively reused.
5. Classes within a released component should share common closure.
That is, if one needs to be changed, they all are likely to need
to be changed. What affects one, affects all.
6. Classes within a released componen should be reused together.
That is, it is impossible to separate the components from each
other in order to reuse less than the total.
7. The dependency structure for released components must be a DAG.
There can be no cycles.
8. Dependencies between released components must run in the
direction of stability. The dependee must be more stable than
the depender.
9. The more stable a released component is, the more it must
consist of abstract classes. A completely stable component
should consist of nothing but abstract classes.
10. Where possible, use proven patterns to solve design problems.
11. When crossing between two different paradigms, build an
interface layer that separates the two. Don't pollute one side
with the paradigm of the other.
--
Christian Millour
|> In article <1995Jun6....@rcmcon.com> rma...@rcmcon.com (Robert Martin) writes:
|> >From: rma...@rcmcon.com (Robert Martin)
|> >Subject: The Principles of OOD
|> >Date: Tue, 6 Jun 1995 04:56:38 GMT
|> > 4. The granule of reuse is the same as the granule of release.
|> > Only components that are released through a tracking system can
|> > be effectively reused.
|>
|> That's a good principle, in general. However, the granule of reuse can, in my
|> experience be SMALLER than the granule of release. I can always choose to
|> ignore parts of a framework, or to use only part of a classes protocol.
|>
Methinks that if a subpart is useable and useful on its own then
the granule of release was too large.
|> > 5. Classes within a released component should share common closure.
|> > That is, if one needs to be changed, they all are likely to need
|> > to be changed. What affects one, affects all.
|>
|> What? Doesn't that sort of kill the idea of encapsulation? Changes to one
|> class should NEVER affect another class, unless you are changing the meaning
|> or implementation of the public protocol of that class.
What about friends ? Or abstraction hierarchies ? I think Robert is just advocating for tightness.
|> You should be able to
|> extend a classes public protocol without affecting any other class as well.
|>
hardly possible when iplementing collaboration patterns such as
component/composite or subject/observer.
|> > 6. Classes within a released componen should be reused together.
|> > That is, it is impossible to separate the components from each
|> > other in order to reuse less than the total.
|>
|> Nyet, Nein, Nix. Let's take a simple example from the MVC framework from
|> Smalltalk. I can easily decide that I want to write an interface that
|> displays a graph, but does not allow changes to the graph. In this case, I
|> need a Model, and a View, but not a Controller.
In that case the framework is just too big and the granule of release
inadequate. An alternate release might be MV, optionaly extended to MVC.
(really hard though).
|>
|> You are assuming, again that framework and class designers are omniscient.
|> That will get you into trouble!
|>
Now here's a good point. But can laxity in implementation or release
really compensate for lack of foresight/science/wisdom in design ?
Ole-Hjalmar Kristensen TF.E/DELAB
|> >From: rma...@rcmcon.com (Robert Martin)
|> >Subject: The Principles of OOD
|> >Date: Tue, 6 Jun 1995 04:56:38 GMT
|>
|> >I am in the midst of working on my next book: "The Principles and Patterns
|> >of Object Oriented Design". As part of that exercize, I have been compiling
|> >a set of principles, some of which I posted to comp.object several months
|> >back. They are included at the end of this posting.
|>
|> >Over the next few weeks I will be posting articles that expound upon
|> >each of the principles in turn. My object, of course, is to present these
|> >principles to the OO community and get some early feedback and reviews for
|> >my book.
|>
< stuff deleted >
|>
|> > 5. Classes within a released component should share common closure.
|> > That is, if one needs to be changed, they all are likely to need
|> > to be changed. What affects one, affects all.
|>
|> What? Doesn't that sort of kill the idea of encapsulation? Changes to one
|> class should NEVER affect another class, unless you are changing the meaning
|> or implementation of the public protocol of that class. You should be able to
|> extend a classes public protocol without affecting any other class as well.
I think he is addressing tho cases where the interface to a component is at the
module level, not at the level of a single class. You seem to assume that module
== class. This is not always so. I think there is a real need to distinguish
modules as a separate concept from classes. You too, seem to assume that the
class designer is omniscient and is capable of subdividing the design in classes
which only depend on the public interface of other classes. Although this may in
principle always be possible, it is not always desirable.
|>
|> > 6. Classes within a released componen should be reused together.
|> > That is, it is impossible to separate the components from each
|> > other in order to reuse less than the total.
|>
|> Nyet, Nein, Nix. Let's take a simple example from the MVC framework from
|> Smalltalk. I can easily decide that I want to write an interface that
|> displays a graph, but does not allow changes to the graph. In this case, I
|> need a Model, and a View, but not a Controller.
|>
|> You are assuming, again that framework and class designers are omniscient.
|> That will get you into trouble!
|>
See above. That you have an example showing that it is possible to keep
everything separate, does not mean it always is so.
< stuff deleted >
|>
|> Kyle Brown
|> Senior Member, Technical Staff
|> Knowledge Systems Corp.
|> kbr...@ksccary.com
|>
|>
|>
|>
|>
|> >--
|> >Robert Martin | Design Consulting | Training courses offered:
|> >Object Mentor Assoc.| rma...@rcmcon.com | Object Oriented Analysis
|> >2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design
|> >Green Oaks IL 60048 | Fax: (708) 918-1023 | C++
|>
Ole-Hj. Kristensen
Orpheus
Doug Morgan <do...@monet.ads.com> wrote:
>
>> 11. When crossing between two different paradigms, build an
>> interface layer that separates the two. Don't pollute one side
>> with the paradigm of the other.
>
I think he means "don't mix OO with non-OO"--the Jim Crow law of
programming? :)
Interesting, though. I do think "paradigm" tends to be ill defined.
It relates to the underlying model used to express solutions. Do we
need a taxonomy of paradigms? If I am not mistaken, some examples
include...
Procedural Programming
Object-Oriented Programming
Knowledge-/Rule-Based Programming
Declarative/Logic Programming
Functional Programming
Relational Database Programming?
X Windows :)
others--demand driven, vectorized, event driven?
What's missing?
(Note that the categories are not disjoint...eg, OOP is a form of
procedural, rule-based languages use rules to trigger procedural
code, etc.)
>but if the paradigm is a good one
>and stable, why not pollute. Why wrap everything?
One thing I've noticed is a tendency to try to impose OO concepts on
top of all the other "paradigms"--eg, Object-Oriented Prolog...
I think that perhaps point #11 is hinting at a bigger picture...
or is it another question altogether? Ie, when designing a system,
it is useful to partition into subsystems and the choice for what the
subsystems are usually has to do with crossing conceptual boundaries of
one sort or another. Eg, segregating database usage by defining a
fixed interface that doesn't change when the database does. This
fits the Object-Oriented paradigm fairly well.
>If the paradigm is unstable (or not stable enough), then 11 does
>follows from 8 (this list could be a DAG). If the paradigm is
>generally lousy or incompatible with an otherwise great system, then
>11 also follows, but for a different reason.
Sounds good.
Doug Morgan
>
> I am in the midst of working on my next book: "The Principles and Patterns
> of Object Oriented Design". As part of that exercize, I have been compiling
> a set of principles, some of which I posted to comp.object several months
> back. They are included at the end of this posting.
>
> Over the next few weeks I will be posting articles that expound upon
> each of the principles in turn. My object, of course, is to present these
> principles to the OO community and get some early feedback and reviews for
> my book.
>
>
>
> 1. Software entities (classes, modules, etc) should be open for
> extension, but closed for modification. (The open/closed
> principle -- Bertrand Meyer)
Nice goal for many software entities.
> 2. Derived classes must usable through the base class interface
> without the need for the user to know the difference. (The
> Liskov Substitution Principle)
"without the need for the user to know the difference" should be
tighted up to something like "with the derived classes satisfying the
guarantees stated with the base class." It is important to state that
the base class designers should be stating just which differences a
user can be concerned with. Otherwise, a random user might be
interested in the time difference in redrawing a 100,000-line polygon
and redrawing a rectangle. However, the base class guarantee might
only be that derived classes get redrawn, somehow. If time is
important it should be a promise of the base class, not some random
thing noticed or not by a user.
> 3. Details should depend upon abstractions. Abstractions should
> not depend upon details. (Principle of Dependency Inversion)
Reasonable definition of abstraction. Where does "Inversion" come
from? Isn't "abstraction" vocabulary enough without inventing terms
like the "Principle of Dependency Inversion?"
> 4. The granule of reuse is the same as the granule of release.
> Only components that are released through a tracking system can
> be effectively reused.
What does the second sentence mean? Is all software that is
effectively reused from various net sites being released through a
tracking system? Is no software being effectively reused? Does any
numbering of a fixed software version constitute release through a
tracking system?
Suppose someone steals some software and builds a successful product
with it, was a tracking system involved or was the reuse not
effective?
> 5. Classes within a released component should share common closure.
> That is, if one needs to be changed, they all are likely to need
> to be changed. What affects one, affects all.
>
> 6. Classes within a released componen should be reused together.
> That is, it is impossible to separate the components from each
> other in order to reuse less than the total.
5 and 6 are essentially equivalent. To see that 5 implies 6, suppose
5 holds, but not 6. Then, separate the component into two separately
usable subcomponents, use only one and change (destroy, say) the
other. This contradicts 5 (disallowing the unlimited slack that might
be derived from the use of "are likely" in 5). For the opposite
implication, suppose 6 holds, but not 5. Find the class or classes
that can be changed without changing the others. Assuming that the
changes can be arbitrary (this is an extension of what 5 actually
says), eliminate that class (or classes). The remainder is a usable
subcomponent and 6 is contradicted. So 5 and 6 are equivalent (modulo
the hedging allowed by "are likely to" and "should be").
> 7. The dependency structure for released components must be a DAG.
> There can be no cycles.
4, 5, 6, and 7 can be summarized with something a bit shorter:
There should exist release sequences for all components in which each
component is useable immediately upon release. Further, the
components should be individually "as small as possible" consistent
with the individual usability constraint.
I believe that the "small" part can lead to extremely sticky questions
of definition and implementation. Similar problems (actually simpler
ones) in "optimal" conversion of arbitrary hypergraphs to acyclic
hypergraphs are NP complete. I think that in practise, most
applications have simple enough structure that acceptably good
component breakdowns can be found without much trouble.
> 8. Dependencies between released components must run in the
> direction of stability. The dependee must be more stable than
> the depender.
Perhaps better said as an observation followed by a derived rule:
The stability of a component is bounded by its least stable part.
Therefore, if you want to give someone a stable interface, you must
isolate unstable (often external) interfaces behind your own stable
ones. (See also 11.)
> 9. The more stable a released component is, the more it must
> consist of abstract classes. A completely stable component
> should consist of nothing but abstract classes.
I don't think is "stability" is the primary beneficiary of abstract
classes. I think it is more "usability in general situations."
Usability is primary and stability is secondary: usable things don't
have to be changed, therefore they are stable. Contrary to 9, many
extremely stable packages have lots of concrete classes and possibly
no classes at all (LinPack?). They are stable because they are useful
as-is. Also, the set of useful abstractions change too, sometimes
both fast and over long periods.
> 10. Where possible, use proven patterns to solve design problems.
Sure. Why not? Mileage will vary. Might try some other things too.
> 11. When crossing between two different paradigms, build an
> interface layer that separates the two. Don't pollute one side
> with the paradigm of the other.
I have no idea what a paradigm is, but if the paradigm is a good one
and stable, why not pollute. Why wrap everything? "Purity" perhaps?
If the paradigm is unstable (or not stable enough), then 11 does
follows from 8 (this list could be a DAG). If the paradigm is
generally lousy or incompatible with an otherwise great system, then
11 also follows, but for a different reason.
Doug
----------
Doug Morgan, do...@ads.com
Booz-Allen & Hamilton
1500 Plymouth St.
Mountain View, CA 94043-1230
(415) 960-7444
FAX: (415) 960-7500
----------
Patrick Logan
: Yeah. Theory is great, but good, substantative examples are rare.
: Here's my idea, if I were going to write a book, I would write:
: Examples of Object Oriented Designs and their
: Implementations from the Real World.
: Such a book would start with simple examples and evolve, chapter
: by chapter, into more complex or more specialized applications
: showing how the design lead to the implementation, illustrating
: design tradeoffs, showing how constraints affect the "purity" of
: the implementation, etc.
At least one book of this nature has been written:
"Designing Object-Oriented C++ Applications Using the Booch Method",
Robert C. Martin, Prentice-Hall.
Robert C. Martin
>In article <uyrb57i...@cheetos.nmo.gtegsc.com>,
>David Karr <dk...@nmo.gtegsc.com> wrote:
>>>>>>> "Robert" == Robert Martin <rma...@rcmcon.com> writes:
>>It might be more valuable to
>>publish a catalog of case studies of applications of these principles.
>>[...]
>
>
>Here's my idea, if I were going to write a book, I would write:
>
> Examples of Object Oriented Designs and their
> Implementations from the Real World.
>
>Such a book would start with simple examples and evolve, chapter
>by chapter, into more complex or more specialized applications
>showing how the design lead to the implementation, illustrating
>design tradeoffs, showing how constraints affect the "purity" of
>the implementation, etc.
>
Designing Object Oriented C++ Applications using the Booch Method.
It does just as you say, starts with simple examples and works
up through more and moe complex ones. The last one is 3 chapters
long and explores the design of a building security system.
Robert C. Martin
>In article <1995Jun6....@rcmcon.com> rma...@rcmcon.com (Robert Martin) writes:
>
>> 1. Software entities (classes, modules, etc) should be open for
>> extension, but closed for modification. (The open/closed
>> principle -- Bertrand Meyer)
>
>Nyet. I see your C++and Eiffel background showing through, Robert. You are
>assuming that the designer of a class is omniscient and perfect. That's a
>crock. Class designers make mistakes, sometimes bad ones. In the Smalltalk
>world everyone except IBM believes that source code should be open to all
>developers. In this manner, we can repair a badly factored class, or fix bugs
>that we can't wait for the class developer (usually a vendor) to get around to.
I never meant to imply that the code should be closed to designers.
Closed code is code that does not *need* to be changed. That can
be exteneded without modification.
I agree, that this requires a certain amount of precience, and that no
code can be 100% closed. However, the goal is still a very important one
to shoot for. The more closure we can attain, the better.
>> 3. Details should depend upon abstractions. Abstractions should
>> not depend upon details. (Principle of Dependency Inversion)
>
>This one will need lots of explanation. I think I understand what you're
>saying, but I think you could say it more clearly.
I'll be explaining it more in a later posting. However in capsule,
abstract classes should contain high level reusable policies.
Concrete classes should contain low level implementations. Cncrete
classes should depend upon high level abstract classes. High
level abstract classes should not depend upon low level concrete
classes.
>> 5. Classes within a released component should share common closure.
>> That is, if one needs to be changed, they all are likely to need
>> to be changed. What affects one, affects all.
>
>What? Doesn't that sort of kill the idea of encapsulation? Changes to one
>class should NEVER affect another class, unless you are changing the meaning
>or implementation of the public protocol of that class. You should be able to
>extend a classes public protocol without affecting any other class as well.
You misunderstand me. Again, I will be posting more about this later. However,
consider that a framework can consist of *many* released component. A *single*
released component should therefore be composed of classes that experience the
same kind of changes. In that way, fewer released components will have to be
re-released when changes are made.
Also. As you discussed in my point 1, it is unrealistic to suppose that a
change to one class will NEVER change other classes. Classes collaborate
with each other. WHen the interface of one class changes, the collaborators
must be changed with it.
>
>> 6. Classes within a released componen should be reused together.
>> That is, it is impossible to separate the components from each
>> other in order to reuse less than the total.
>
>Nyet, Nein, Nix. Let's take a simple example from the MVC framework from
>Smalltalk. I can easily decide that I want to write an interface that
>displays a graph, but does not allow changes to the graph. In this case, I
>need a Model, and a View, but not a Controller.
>
>You are assuming, again that framework and class designers are omniscient.
>That will get you into trouble!
No. Again, I will be posting more on this later. The point here is that,
if you need to reuse one class in a unit of release, you should need to
reuse all the classes in the unit of release. Remembering that a single
framework can consist of many units of release. (i.e. class categories).
>
>> 9. The more stable a released component is, the more it must
>> consist of abstract classes. A completely stable component
>> should consist of nothing but abstract classes.
>
>
>NO, NO, NO. There are two basic types of reuse. The first kind is the kind
>you are assuming, which is that you will create new components by customizing
>old ones. However, another, perfectly valid type of reuse is the "toolkit"
>approach that consists of taking concrete components and recombining them in
>new and interesting ways. This is how most window-builder products work,
>regardless of the language.
Of course, and this principle does not deny the two forms of reuse. Stability
can be achieved in concrete classes. But this is based upon knowledge that is
"outside the system". i.e. you know hat the concrete components are
stable because nobody had needed to change them for a long time, or because
they represent an extremely stable concept. I count such components as
exceptions, given special dispensation to be stable. One must be careful to
confer stability upon a concrete class. If you are wrong, then changes
will ripple through the system. It is always safer to confer stability to
abstract classes.
unknown
Hi;
I haven't read much about CORBA since Revision 1.1 of the CORBA document
(1991). I want to reeducate myself about it:
1. Has the IDL/C++ binding ever been standardized? Where can I read about it?
2. Where can I buy the latest CORBA document from?
3. Are there any free implementations of an ORB and IDL->C++ compilers?
Generally, any references to good documentation would be appreciated.
Thanks!
Brian
--
Brian Glendenning - National Radio Astronomy Observatory
bgle...@nrao.edu Charlottesville Va. (804) 296-0286
Ian Fairman
: Hi;
: I haven't read much about CORBA since Revision 1.1 of the CORBA document
: (1991). I want to reeducate myself about it:
: 1. Has the IDL/C++ binding ever been standardized? Where can I read about it?
I think it's part of CORBA 2.0
: 2. Where can I buy the latest CORBA document from?
: 3. Are there any free implementations of an ORB and IDL->C++ compilers?
Try ftp://labrea.stanford.edu/pub/pomoco/
: Generally, any references to good documentation would be appreciated.
Ian.
--
Ian Fairman, BT.
Email: ifai...@jungle.bt.co.uk
Disclaimer: My opinions are my own and not those of my employer.