> Refactoring is a fact of life. Refactoring is a symptom of screwing up the architecture of your application. Excessive refactoring is caused by excessively s

> Refactoring is a fact of life. Refactoring is a symptom of screwing up the architecture of your application. Excessive refactoring is caused by excessively screwing up. I'd argue that if refactoring seems like a fact of life with OOP, that might indicate there's something very wrong with that paradigm. > Encapsulation makes it trivial to identify all places that need to be addressed. If encapsulation was all you needed, there wouldn't be so many refactoring tools for OOP languages that rename and move methods and classes around. > Talking about 'certain this' and 'possible that' is subjective. I'm not being subjective. In virtually every OOP application there will be an object that implements at least part of the functionality of a map. At the bare minimum, there will be at least one object that has a getter or a setter method. >If you value transparency then inheirit. Inheritance doesn't provide transparency in any meaningful way. The private members of the class are still private. The getters and setters are still opaque. >your 'data structure' is actually an object itself e.g. a hash map Data structures are only objects in object-orientated languages. In other systems, they're either primitives or constructed from primitives. At the lowest level, you can construct any data structure you like from an ordered array of bytes.