Re: OCP and Java

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

Date: Wed, 02 Feb 2005 07:06:19 -0600

On 1 Feb 2005 09:36:53 -0800, stevenwurster@lycos.com wrote:

>You are correct, though, in that good developers could develop a
>"OCP-ish" system in Java. My thought is that attempting to adhere to
>the OCP in Java will either lead to immense code bloat, or classes that
>do not support the OCP because the developers didn't like the code
>bloat they were getting in an attempt to adhere to the OCP.

Conforming to the OCP in Java, or C++, or C# is not nearly as
difficult as you seem to think; nor does it lead to code bloat. All
these languages are flexible and powerful enough for competent
designers to create modules that are open for extension and closed for
modification.

The OCP state of a system is not binary. Good designers try to
maximize it over time. If they are wise, they frequently subject the
system to critique and change during it's early development. They
repeatedly put the growing system in front of users, stakeholders, and
customers to elicit feedback and observe usability. They use this
feedback to make changes to the system; and they use those changes to
adjust the design so that it conforms more closely to the OCP in those
areas that are experiencing change.

Focussing on the accessibility of variables as an impediment to the
OCP is a red herring. It implies that the OCP is enhanced by
promoting high coupling to variables between classes. The opposite is
true. A well designed system, that conforms closely to the OCP,
minimizes it's dependence on variables. Specifically, derived classes
that use their base class variables *detract* from the OCP, they do
not enhance it.

-----
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: OCP and Java
    ... >>do not support the OCP because the developers didn't like the code ... > difficult as you seem to think; nor does it lead to code bloat. ... instance of Date with the next day) we have to subclass Date. ... Or perhaps I want to create a class that is everything String is, ...
    (comp.object)
  • Re: OCP and Java
    ... > the OCP in Java will either lead to immense code bloat, ... > that do not support the OCP because the developers didn't like the ... > code bloat they were getting in an attempt to adhere to the OCP. ... Can you give an example of the coad bloat you can see in Java, ...
    (comp.object)
  • Re: OCP and Java
    ... > The OCP state of a system is not binary. ... That is, you assume that developers ... know what the OCP is, how to design to it, and how to spot when the ... Descendant classes may need to use their ancestor class' variables. ...
    (comp.object)
  • Re: OCP and Java
    ... > The OCP state of a system is not binary. ... That is, you assume that developers ... know what the OCP is, how to design to it, and how to spot when the ... Descendant classes may need to use their ancestor class' variables. ...
    (comp.object)
  • Re: OCP and Java
    ... > The OCP state of a system is not binary. ... That is, you assume that developers ... know what the OCP is, how to design to it, and how to spot when the ... Descendant classes may need to use their ancestor class' variables. ...
    (comp.object)