Re: Questions of Rob Martin's article
From: Robert C. Martin (unclebob_at_objectmentor.com)
Date: 05/11/04
- Next message: Robert C. Martin: "Re: Questions of Rob Martin's article"
- Previous message: Robert C. Martin: "Re: Design Problem Aggregation"
- In reply to: iamfractal_at_hotmail.com: "Re: Questions of Rob Martin's article"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 11 May 2004 12:57:46 -0500
On 11 May 2004 05:01:31 -0700, iamfractal@hotmail.com wrote:
>Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<pr6v90d3jnud9cf9c7leaoorpi1utt6m8h@4ax.com>...
>> On Mon, 10 May 2004 06:05:30 GMT, "pub" <pub@nospam.com> wrote:
>>
>> >In an article, Rob Martin wrote about package...
>> >
>> >Does he mean "package" at source code or binary level?
>>
>> Binary. I consider a package to be equivalent to a dll or jar file.
>> >
>> >When he talking about "OPC" principle, "...Such modules can be created in
>> >C++ by using abstract classes." Does he mean "module" here the same thing as
>> >"package"?
>>
>> I think you are referring to the Stable Abstractions Principle which
>> tells you to have concrete packages depend on abstract packages. In
>> this case the term "module" refers to "package.
>> >
>> >Should each "package" have only one abstract or more than one accessible to
>> >its client?
>>
>> That's up to you. I often have many different classes (abstract or
>> concrete) that other packages can use.
>
>Why do people have such rigorous standards when it comes to class
>encapsulation, yet such loose standards when it comes to package
>encapsulation?
Have you looked at the six principles of package coupling and cohesion
that I have written about? I don't have loose standards about
packages, or package encapsulation. Rather, the best way to
encapsulate it to effectively partition. Rather than hide a variable
or a class, partition the class or package so that the variable or
class isn't even there.
See
http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles
For a list of article that deal with these principles, and others.
>[Ok, I mean, "Package," here as just a collection of cooperating
>classes, as in a Java package.]
Actually, no. A Java package is just a namespace, a way to hide
otherwise duplicate names. The packages that I'm talking about are
binary, like .jar files.
>Most people usually have as few public methods as possible within a
>class, yet within a package, why have more than one public, concrete
>class? Public abstract classes are ok, because they hide the
>implementation class somewhere behind them. But more than one public,
>concrete class seems ... nasty.
The interface of a package should certainly be minimal, though it does
not need to be as minimal as a Facade. One way to minimize package
interfaces is to minimize the packages themselves. The fewer classes
in the package, the smaller the interface.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
- Next message: Robert C. Martin: "Re: Questions of Rob Martin's article"
- Previous message: Robert C. Martin: "Re: Design Problem Aggregation"
- In reply to: iamfractal_at_hotmail.com: "Re: Questions of Rob Martin's article"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
