Procedural vs OO

In any complex system there are going to be times when we want to add new data types rather than new functions. For these cases objects and OO are most appropriate. On the other hand, there will also be times when we’ll want to add new functions as opposed to data types. In that case procedural code and data structures will be more appropriate.

https://medium.com/mindorks/how-to-write-clean-code-lessons-learnt-from-the-clean-code-robert-c-martin-9ffc7aef870c

Why not to use PowerMock

In my opionion [sic], creating a new collaborating service is not bad primarily because it's untestable, but because it introduces coupling and undermines polymorphism, and similarly for the static invocations of the Database class. 

 http://blog.xebia.com/mocking-the-unmockable-too-much-of-a-good-thing/

So "testability" has always been more than just whether a class is literally testable in terms of lack of technical limitations. Author seems to suggest "testability" has really been a proxy argument for good OOP design.

Having realized this, I now understand what Misko Hevery meant when he said the following (unfortunately without elaborating):

 Yes I am aware of them, and I think it is a bad idea. You are trying to compensate bad design with Monkey Patching.

http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/

Downsides of Inheritance

...using inheritance is too tightly coupled with the implementation. That is, the actual implementation is written so that one of the public methods actually use another. If you override both, and you call super, then you might get unwanted side-effects. If the implementation changes in a later version, then you will have to update your handling of it as well.

http://stackoverflow.com/questions/23121890/difference-between-delegate-mixin-and-traits-in-groovy

Large Conditionals in Static Factory Methods

Create a static factory method with the same parameters as the superclass constructor. It must contain the parameter that will take the starting values of the coded type. Depending on this parameter, the factory method will create objects of various subclasses. To do so, in its code you must create a large conditional but, at least, it will be the only one when it is truly necessary; otherwise, subclasses and polymorphism will do.

https://sourcemaking.com/refactoring/replace-type-code-with-subclasses

Validation via Static Typing

Furthermore, most type system lack means to statically describe types such as “a list with at least two elements” or “a floating-point number larger than or equal to zero”.
Such requirements should be described as far as possible using static typing; anything else has to be worked around via run-time validation. 

http://programmers.stackexchange.com/a/258281

Fundamental Goal of OOP

A fundamental goal of OO design is to place the behaviour (methods) as close to the data they operate on (attributes), so that changes are less likely to propagate across multiple classes.

http://www.codemanship.co.uk/parlezuml/metrics/OO%20Design%20Principles%20&%20Metrics.pdf

A Rule of Thumb for Cohesion

from http://code.tutsplus.com/tutorials/how-to-write-code-that-embraces-change--net-29716

You can think of ISP as a higher-level cohesion principle.
When both UI classes depended on the Broker interface, they were similar to two classes, each having four fields, of which two were used in a method and the other two in another method. The class would have not been very cohesive.

Getters/Setters is Fine-Grained Interface is good OOP?

Martin Fowler seems to agree with this notion by mentioning all three in the same breath in an article on the disadvantages of distributing objects.

from http://www.drdobbs.com/errant-architectures/184414966

A local interface is best as a fine-grained interface. Thus, if I have an address class, a good interface will have separate methods for getting the city, getting the state, setting the city, setting the state and so forth. A fine-grained interface is good because it follows the general OO principle of lots of little pieces that can be combined and overridden in various ways to extend the design into the future.

What Class Am I?

This post and the following pithy remark by a commenter reminded me of my own question regarding a not-identical but related quandary I posed here.

...by Walky_one:
The basics of object oriented design with polymorphism is:
The base class defines functionality that is COMMON for all derived classes.
Functionality that is NOT COMMON should NOT be in the base class.
I know the UnsupportedOperationException approach (and sometimes I even agree that it's a workable way): However it's still an approach that violates one of the most central aspects of object oriented design...

Association and aggregation -- semantic mismatch

At the code level, a pointer (reference in Java and C#) is used to represent both association and aggregation. There is a semantic mismatch between the code and the object model .

http://www.agiledeveloper.com/articles/cloning072002.htm

Protected instance variables are an abomination

[A]n object's instance variables (member fields that aren't constants), should always be private. Period. No exceptions. Ever. I mean it. (You can occasionally use protected methods effectively, but protected instance variables are an abomination.) You should never use get/set functions for the same reason—they're just overly complicated ways to make a field public (though access functions that return full-blown objects rather than a basic-type value are reasonable in situations where the returned object's class is a key abstraction in the design). 

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?page=2