Do Ruby's "Open Classes" break encapsulation? -

in ruby, programmers allowed change predefined classes. bad programmer like:

class string   def ==(other)     return true   end end 

obviously, no 1 quite dumb, idea more subtle changes predefined class cause problems in already-working code seems me violate principle of encapsulation.

four questions:

1. first, this, in fact, violate oo principle of encapsulation?
2. second, there way, programmer, can guarantee in code working unmodified version of class?
3. third, should ever "opening" classes in code, reason?
4. finally, how sort of thing handled in large-scale, production coding environment? in other words, people in programming industry in code others use? or if don't, how ensure plugin author somewhere isn't doing ruin essential part of program?

i know subjective question, i'd know how wider programming community feels called "monkey patching."

first, this, in fact, violate oo principle of encapsulation?

yes.

second, there way, programmer, can guarantee in code working unmodified version of class?

not yet. classboxes in ruby 2.0 (hopefully) going solution.

third, should ever "opening" classes in code, reason?

only last resort.

you should never monkey-patch own classes. there's no point. control them, can make them want in first place.

you should never monkey-patch classes in library. (the exception rule libraries sole purpose monkey-patch something, e.g. marc-andré lafortune's backports library, monkey-patches ruby 1.8.6, 1.8.7, 1.9.0 , 1.9.1 as possible of functionality ruby 1.9.2.) may provide add-on library provides monkey-patches make easier use library (e.g. have encryption library provides kryptonite.encrypt(str) method , provide add-on string#encrypt method), add-on should in separate library, user needs explicitly require. should optional.

you should not monkey-patch core classes. refers classes array or symbol in ruby, rails library, include classes activerecord::base under "core" label. (same caveat above. e.g. in versions of rails before 3.0, there no well-defined plugin api, monkey-patching only way extend rails. without people broke rule, there never haven been plugins, , rails never now.)

try inheritance first. try composition (wrappers, proxies, facades, adapters, …) first. try refactoring first. try helper objects first. only if doesn't work, turn monkey-patching.

be respectful when monkey-patch: if adding new method, make sure doesn't exist, , deal if (e.g. call method). if wrapping existing method, make sure if else has wrapped it, wrapper gets called , when wants wrap afterwards, wrapper allows that. (in particular, means must preserve method's existing contract.)

put monkey-patches in mixin, if @ possible. way, show in inheritance chain, give tries debug code fighting chance figure out going on. put monkey-patches in separate, named files.

finally, how sort of thing handled in large-scale, production coding environment? in other words, people in programming industry in code others use? or if don't, how ensure plugin author somewhere isn't doing ruin essential part of program?

don't work "really bad programmers", call them.

as simplistic sounds, that's boils down to. yes, of course, can write tests, code reviews, practice pair programming, use static analysis tools, run code warnings enabled (e.g. code posted in question generate warning: method redefined; discarding old ==). me, that's not-really-bad-programmer anyway.