[MockObject]

> However, as the years went by, people started to realize that the strict approach to object orientation created a number of problems. These problems tended to be of the kind that makes code complex, hard to understand, and hard to test.

No, ease of testing is one of the reasons for OO adoption, and probably the primary reason software is much more stable than it was in the mid 90s.

> Many of those higher-level classes are “polluted” with methods and properties that are only relevant to a small number of subclasses.

Well, then it's broken and needs to be refactored.

> During my last couple years working at Google, I created a new user interface toolkit called “Quantum Wiz”

Of course, in true Google style, you wrote something from scratch instead of refactoring the old.

> composition > inheritance

Not a new finding. I learned this in 2000, at the peak of OO craze.

> Because object oriented inheritance is about organizing things into classes, it doesn’t model the real world very well; what it does model well is the way humans think about the real world.

That's the idea. Good software is written for the simplicity of those poor slobs charged with maintaining it -- often ourselves a year later.

> A physical object has many uses other than the specific purpose for which it was built. I can use a coffee cup as a paperweight or a doorstop;

The whole idea of modeling is to remove certain details! Otherwise the model would be identical to the genuine article, and would provide no benefit.

[tabtab]

Re: Well, then it's broken and needs to be refactored.

Refactoring means the original design didn't handle change well. Refactoring is badge of disgrace, and should not be considered a standard practice any more than putting out kitchen fires should be considered a standard practice of cooking. One of the key points of abstraction is to make the code change-friendly. If you have to refactor, the code failed that job. Minor rework is expected upon new requirements, but complete structural overhauls should be avoided, in part because it can create cascading side-effects.

Re: The whole idea of modeling is to remove certain details! Otherwise the model would be identical to the genuine article, and would provide no benefit.

But in some cases OO-based modelling becomes awkward or forced. Does the action of "gluing" belong with the glue or with the object being glued (fixed)? We can force it to be with one or the other to satisfy "OO rules", but that doesn't necessarily mean it's a good model. It's a forced model.

Re: [article] it doesn’t model the real world very well; what it does model well is the way humans think about the real world.

It doesn't model all thinking well. For smaller sub-systems it's fine. But OOP seems to get messy and tangled on a larger scale.

[Rooster61]

> Refactoring is badge of disgrace, and should not be considered a standard practice any more than putting out kitchen fires should be considered a standard practice of cooking.

You are taking the idea of refactoring to an extreme and then attacking it. Refactoring != complete structural overhaul (at least not always), and it certainly shouldn't be a badge of disgrace. It's a perfectly reasonable and acceptable practice to write code to make something work that might be kludgy or not so clearly written with the intention of refactoring once the overall solution is in mind. Programmers don't always have the luxury of designing it perfectly before implementation. That's just unrealistic in today's market.

[hinkley]

This is the sort of thinking that leads to analysis paralysis, and massive overengineering for what-ifs. Yes, the design you had when you had a smaller customer base in mind and when you were deep in Dunning-Kruger territory about your problem domain is not going to work once you actually know what the fuck you're doing. Shit happens, get over it. And yourself.

Being bad at refactoring will only make the experience more painful. Same with unit tests. Same with deployment. Same with pretty much everything.

> Refactoring means the original design didn't handle change well. Refactoring is badge of disgrace

I'm not sure how you intended this, but this reeks of shame-based project management, which is a bane and a scourge of the industry. Get out of here with your failure talk. You're spooking the natives.

[MockObject]

> Refactoring is badge of disgrace, and should not be considered a standard practice any more than putting out kitchen fires should be considered a standard practice of cooking.

I can only grant you the benefit of the doubt and assume you aren't quite using the word the way the rest of the industry does.

Replacing two similar code fragments with two calls to a single method is an example of refactoring. In no universe would that ever be considered any sort of kitchen fire.

[tabtab]

"Refactoring" is also often used when for example somebody uses the wrong OOP pattern (doesn't fit changes) and has to convert it to a different OOP pattern.