In OOP there is the Open/Closed principle that states that

"software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification".

Taking in consideration that in Ruby it is to possible to reopen a class, don't you think that this breaks the Open/Closed principle?

When do you think we should favor reopening classes instead of just extending them?

What do you think that are pitfalls in reopening classes?

  • @Tomasz, I disagree. This question deals with a particular issue or Ruby with concrete consequences. May 10, 2011 at 16:20

1 Answer 1


Ruby's open classes provide a way to programatically build up complex classes. For complicated libraries this makes configuration easier, and code smaller and more maintainable. If you ever meet a Lisp programmer, they will talk you ear off about how wonderful it is to use code to write code.

This power can be used for both good and evil. The practice of Monkey Patching functionality into a class is expedient, but is also a form of technical debt that will make it harder to stay current and maintain code.

A good rule of thumb is that a class should be reopend only by the person (group) that originally wrote it. If others are feeling then need to reopen one of your classes, that is probably a sign that it needs to be refactored so it is more configurable, that is open for extension. This is the D of SOLID.

  • 2
    The open/closed principle is the O in SOLID. D is for dependency inversion. Aug 12, 2014 at 20:06
  • D would be dependance injection which is exactly what I am referring to. Open/Closed says to treat others classes as black boxes which can be extended but not modified. Dependance Injection says that those black boxes should accept input so that their functionality can be used for object that Author of the original class was not aware of. Aug 13, 2014 at 20:11
  • 1
    You just said that the class should be "configurable, that is open for extension." This doesn't make it clear that you're talking about dependency inversion (or dependency injection, which is related but not quite equivalent), since there are multiple ways to make classes "configurable" that don't really conform to the dependency inversion principle or the dependency injection pattern. Aug 14, 2014 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.