Re: creaping coupling......

From: Robert C. Martin (unclebob_at_objectmentor.com)
Date: 02/27/05 

Date: Sun, 27 Feb 2005 08:40:52 -0600

On Fri, 25 Feb 2005 16:41:14 -0000, "Mark Nicholls"
<nicholls.mark@mtvne.com> wrote:

>
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
>news:g52t1158vejh1dk89uep1t9cotjk13jqhh@4ax.com...
>> On Thu, 24 Feb 2005 21:22:01 GMT, "H. S. Lahman"
>> <h.lahman@verizon.net> wrote:
>>
>> >It's not you. The basic problem you describe can be summarized as:
>> >physical coupling. The OOPLs do a great job on minimizing logical
>> >coupling between program units but they do a terrible job on physical
>> >coupling.
>>
>> No. A statically typed OOPL does a better job at minimizing physical
>> couplings than a statically typed non-OOPL. A dynamically typed OOPL
>> (like smalltalk, phython, or Ruby) does a *tremendous* job of
>> minimizing physical couplings. It reduces them to near zero.
>>
>> Even in statically typed OOPLS the problem is not that bad. With a
>> good knowledge of OO design principles and design patterns, a designer
>> can reduce physical coupling in C++, Java, and C# to very low levels.
>> Indeed, *THAT* is the reason that OO language, and OO design
>> principles and patterns, are beneficial to the software industry.
>>
>
>You need to demonstrate how to solve the following trivial problem, before I
>will believe that claim.

In C++ it would be trivial to break that source code dependency, as
follows
>
------IWriteable.h-------
>class IElement;
>class IWriteable
>{
> public: virtual void Write(IElement* element) = 0;
>}

-----CPipe.h-------
#include IWriteable.h
>class CPipe : public IWriteable
>{
>...
>}

-----CPipeWriter.h-------
#include IWriteable.h
>class CPipeWriter
>{
> public: void CPipeWriter(IWriteable* writeable)
> {
> ...
> }
>
> void WriteABC();
> ...
>}

----CPipeWriter.cpp----
#include CPipeWriter.h
#include CElement.h
> void CPipeWriter::WriteABC()
> {
> writeable.write(new Element("ABC"));
> }
>
-----main.cpp-----
#include IWriteable.h
#include CPipe.h
#include CPipeWriter.h
>
>IWriteable* pipe = new CPipe();
>CPipeWriter* writer = new CPipeWriter(pipe);
>writer->WriteABC();

In this case main.cpp does not #include IElement.h. In fact the only
source file to #include IElement.h is CPipeWriter.cpp. This breaks
the source code dependency that you were worried about. That's one of
the benefits of the .h/.cpp file division in C++.

In Java and C# you can't do this. The reason is that neither compiler
depends solely on source code. When you compile a .java module, it
tries to find declarations from the .class files that it depends upon.
This means that there is a mixed source and binary dependency. So in
your example above there is no way to keep the source code of
IWriteable from depending on the binary code of IElement.

To be fair, the C++ system also depends on the binary of IElement
since it won't run without it. But in C++ that dependency is not
asserted at compile time. It's only asserted at link time (or runtime
in the case of dlls.). In Java and C# it's asserted at compile time.

The advantage of the C# and Java system is *much* faster compile
times. In C++, compile times cannot get better than O(nlogn) and even
a little carelessness will make them O(n^2). In java and c# compile
times are much closer to O(n) simply because there is no #include tree
to load for each module. So the small extra coupling is probably
worth the benefit.

If you *really* want to get rid of that coupling of IElement to the
main program, you can do it by using reflection. But I doubt it would
be worth it in most cases.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.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

Relevant Pages

  • Re: How to avoid the message "Unknown source"?
    ... You haven't provided any source code and you haven't even identified the ... If you are getting a compiler error, javac, the java compiler, should be ... If you are geting a compile ... exception message that will give you a clue about your problem. ...
    (comp.lang.java.help)
  • Re: Java server wont run after reboot
    ... > package definitions in your source code. ... Execute from that directory, no classpath definition needed. ... > java HelloWorld ... > If you compile to a different location, ...
    (RedHat)
  • Re: Java classes called from .net program
    ... if the java classes are available in source code, you can compile them from ... >I need to call methods of java classes from a .net program. ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Java server wont run after reboot
    ... execute from outside the directory where the java files is located, ... then I need to go to ~, and compile it from there: ... the source code is dependent on what directory you want to compile ... I'm not out to destroy Microsoft. ...
    (RedHat)
  • Re: Division by zero
    ... >> compile time error, whereas the latter is a run-time error. ... Suppose I have a constant Widgets that is different on different ... If divide by zero were illegal at compile time, ... extra-lingual features such as OS-specific source code versions)? ...
    (comp.lang.ada)