Algorithms and OOP

In addition to DCI, "generic programming" as well as the move to functional programming appears to add nuance to the OOP notion of joining behavior with data, at the least at the static class definition level. In other words, the notion of OOP I think is becoming more of a runtime notion rather than static notion where the object's definition is enhanced at runtime with injected behaviors, rather than having those behaviors baked into the object's class definition.

The Iterator abstraction is fundamental to an emerging technology called "generic programming". This strategy seeks to explicitly separate the notion of "algorithm" from that of "data structure". The motivation is to: promote component-based development, boost productivity, and reduce configuration management.

https://sourcemaking.com/design_patterns/iterator

Business Logic in OOP

It appears logic should not be mistaken with behavior when it comes to OOP, which embraces the coupling of state and behavior (that modifies that state). Logic belongs elsewhere, e.g. in a rules engine.

One of the "Advantages of [a] Rule Engine" is "Logic and Data Separation (breaking OO coupling of data and logic)" - http://training-course-material.com/training/JBPM_and_Drools_Introduction

Which tables are affected is business logic as well. The database should not have any knowledge of which tables constitute a customer on the business level. These are better served in the business layer.

https://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic

Modified Command Pattern

There's some support for a sort of split Command Pattern where the data lives in one object called the "Command" while the behavior resides explicitly in another object e.g. "handler" or implicitly as in the case of Spring MVC (see example code).

As mentioned it appears in Spring MVC and more recently adopted by CQRS developers.

see http://stackoverflow.com/questions/6617976/dependency-injection-when-using-the-command-pattern and https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91

It has benefits for testing because the runtime data is separated from the compile time behavior. This separation is discussed  in the context of dependency injection by Misko Hevery.

I wonder though what OO proponents like Martin Fowler would say to this; i.e. would they deem the artifacts, the commands, to make up an anemic domain model?

On the other hand, according to some the trend seems to be toward separating behavior from objects in certain respects. E.g. I recall Coplien (of DCI) saying "good objects are dumb" implying albeit that the behavior can be injected at runtime. So maybe that's not the best example. But here's a quote from 'User' on Stackoverflow for what it's worth. It's on the example of where should 'validate()' go:

I think in the past CreditCard.Validate() would have been considered good object oriented design but the trend seems to be away from that towards many separate classes.

http://stackoverflow.com/questions/3117800/dependency-injection-when-the-class-created-also-needs-runtime-values

However, Ayende Rahien asserts the opposite is (or should be) taking place (i.e. to move toward putting data and behavior back together?): http://ayende.com/blog/4503/component-oriented-design-and-why-it-be-retired

Notes
The author of this Command/Handler pattern also demonstrated the Query/Handler analog which is extremely telling and revolutionary with regard to deconstructing the Repository pattern as it's commonly implemented: https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=92

Private Inner / Local Classes - Advantages / Disadvantages

Good debate found here: http://stackoverflow.com/questions/3353318/how-do-i-test-local-inner-class-methods-in-java

The consensus (and accepted answer) is that in general if it's important enough for a local / private inner class to be tested, it should refactored out, e.g. to a separate package.

On the other hand, "bob" makes a good point about keeping the class internal as an implementation detail for the sake of cohesion.

Kai Sternad provides an answer that probably could have been accepted.

Procedural Code Complements OO Objects

When we create applications we 1) Create classes that encapsulate behavior 2) Create procedural code to make objects interact
Source: AppDev

DTOs are not Objects

A DTO is a representation of such a piece of data mapped into an object-oriented language. That still doesn’t make them objects in the sense of encapsulation. It would be impossible. Since all input is suspect, we can hardly enforce any invariants at all.

 http://blog.ploeh.dk/2011/05/31/AtTheBoundariesApplicationsAreNotObjectOriented.aspx

You usually can’t send the domain object itself, because it’s tied in a web of fine-grained local inter-object references. So you take all the data that the client needs and bundle it in a particular object for the transfer—hence the term.

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

Information Expert

Basically, put code in the same object with the data. This sounds simple, but I continually see "data only" and "code only" objects. That is the way procedural programming did things, and it is the natural result of focusing on the process while writing code. OO programming requires a certain level of design work before coding starts, and applying the Information Expert pattern is critical to that effort.

http://thinkingthroughjava.blogspot.com/2011/05/grasping-gang-of-four.html

Object-Oriented Programming

One of the fundamental principles of object-oriented programming is to localize all logic operating on state to the object holding the state, and to hide an object's internal structures and their state transitions. The emphasis should be on how objects communicate with other objects in the environment when triggered by an event.

 http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

Most PMs end up as property bags. It is either that the ORM framework forces you to use public getter/setters or that programmers make PM a property bag even if the ORM supports private setters. Either case, you end up with classes that expose all (or most) of their inner state through properties which breaks class encapsulation and makes classes more tightly coupled. An almost inevitable side effect of this is violation of Tell Don't Ask and Single Responsibility Principle principles.

 http://www.mehdi-khalili.com/orm-anti-patterns-part-4-persistence-domain-model

A class is a coupling of state and behaviour, where the behaviour modifies that state, and this is called encapsulation. Generally you try and encapsulate as much as possible, which means that the state should be manipulated by the object itself (and only that object). Only for behaviour that cannot be modelled within the class would you delegate to an external class, such as a manager, which is why the existence of manager classes is often considered a sign of poorly-written object-oriented code.

Kylotan - http://gamedev.stackexchange.com/questions/18305/is-domain-driven-design-good-for-games

One can find a quick smell to help identify the places where we may have incorrectly applied SRP and created procedural code by noticing the parameter arguments that are being passed. If we are passing an Employee how are we accessing it? Are we breaking state encapsulation? If we have getters and setters being called in that method we should really be reconsidering whether that code actually falls under the responsibility of our object.

 http://codebetter.com/gregyoung/2010/03/24/the-98th-thing-every-programmer-should-know/