Decouple logic from business processes

If we have more complex business conditions, we can once again use Rules to keep that logic decoupled from the business process in a declarative way.

http://salaboy.com/2012/07/28/processes-rules-or-rules-processes-2x/

...unless we like working in spaghetti code...

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

Big Ball of Mud and Intolerance of it

The following may be one of the most quoted paragraphs in software literature (my emphasis added):

A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.

http://www.laputan.org/mud/mud.html

MVC Model Is a ViewModel

Confirmation below that the "model" in the MVC world is not a place for business logic:

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

Our models should be "request models", i.e. dumb data objects used for passing information from MVC to the business logic. Optionally, I see no problem including input validation in the models, but nothing more. Business logic should not be in the models.

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.

LSP Applies to Interfaces too

@albertoblaz: Yes, absolutely. LSP, summed up, really says "if Y subclasses/implements X, be sure that Y is really an X". In your case, Y is a Wall. If it implements IMovable, it breaks LSP because it's not movable. You get into more complex debates like whether a Square is a Rectangle (technically yes, programmatically no), but you're still in easily-defined territory here. – pdr May 24 '13 at 9:14

http://programmers.stackexchange.com/questions/199218/is-it-good-to-have-an-interface-plenty-of-methods-which-belong-to-different-conc?rq=1

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...