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

Static State Shared from Libs Shared Among Webapps

One of the disadvantages of placing application libraries in the Tomcat lib folder is thread safety issues.

... if any of the classes has static state, you will find that the state is now shared across all webapps. This can cause the objects / types from one webapp to be seen by another, which can cause problems.

Stephen C http://stackoverflow.com/questions/12162654/how-to-make-war-file-take-up-less-memory

Advantage of Compiled vs Interpreted Languages

Same reason you'd choose GWT vs JavaScript:

One of the primary ways GWT speeds AJAX development is by allowing you to write your applications in the Java language. Because of this, you can take advantage of static type checking and time-tested patterns of object-oriented programming. These, when combined with modern IDE features like code completion and automated refactoring, make it easier than ever to write robust AJAX applications with well-organized code bases.

http://www.gwtproject.org/doc/latest/tutorial/codeclient.html

so:
1) static type checking
2) code completion
3) automated refactoring

How Agents Work

Wondering about exactly what agents are and what they are supposed to do. Finally found a simple example scenario which I believe is a compelling reason to use agents for when appropriate (in this case negotation):

Agents cooperate on a number of levels. First, they share their perception.
Next, we enabled our agents to share their agent state (e.g. that the
agent carries no gold items) and intentions (such as “I plan to pick gold at
X,Y”) as they may choose to go to the same unknown field or to pick the
same gold item. Now every agent can appraise from what it knows if it will
be better to leave the team member alone or to take the intention as its
own when its more promising.
Our approach to communication and cooperation is fully decentralised.
Each agent has the capability for finding the other agent on the network.
It then directly tells every agent about its perception, agent state and intentions.
There is neither a message broker nor a central instance which
coordinates the contest agents. Every agent builds its own world model from
what it is told by the server and the other agents. Every agent also plans for itself, taking the states and intentions of its teammates into account.

opus4.kobv.de/opus4-tuberlin/files/3610/hessler_axel.pdf

OWL vs Java

Also be careful when declaring properties: properties in OWL can inherit other
properties and can be attached to more then one class. Not so in Java.

opus4.kobv.de/opus4-tuberlin/files/3610/hessler_axel.pdf

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

Class Factories and Factory Scopes

Misko Hevery seems to favor factories that perform the manufactoring process for all objects within an object lifetime. See http://misko.hevery.com/2009/03/30/collaborator-vs-the-factory/
This leads to aggregate factories for different scopes such as Application, servlet, Request, etc. I consider these to be equivalent to the IoC container as in Spring's ApplicationContext which is a  factory i.e. a BeanFactory.

But what about "small lifetime" objects which are the factories we usually think of as in the Factory Method pattern which create objects on the fly? This is broached to Misko by Giorgio Sironi at http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/ regarding the creation of a TagFactory as "an example of creation of non-newables (Song example) in the application logic, that is simply delegation to the TagFactory" - alluding to http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/.

Surprising Misko didn't have much to say on it other than "I think you are on the right track."

Mocks Shouldn't Return Mocks

It appears to be a code smell when a mock returns a mock. See hints of why from this thread: http://programmers.stackexchange.com/questions/232442/unit-testing-factories-and-the-law-of-demeter which point to here which shows how application of LoD quickly fixes the problem.

Misko Hevery says the mocked item, e.g. the factory, should actually be returning a "newable" -- the exception being when returning third party objects such as java.io.File. See response to Tom at http://misko.hevery.com/your-suggestions/

Middle Ground between 'Newable' and 'Injectable'?

As noted previously, Misko Hevery asserts that every objects should be either an "injectable" or a "newable."

The question is: why does then Spring support prototype scoped objects which can be injected with well injectables? The condensed and recently supported alternative (through this initiative) to creating a prototype scope object -- which requires access to the ApplicationContext through ApplicationContextAware or BeanFactoryaware (not good* because it becomes a Service Locator "DI Catch 22") -- i.e. the @Lookup or lookup-method with parameters supported is really just syntactic sugar for a prototype scope object, IMO.

On the other hand, the fact that Spring does the wiring under the covers may make @Lookup-with-parameters okay. However, if one tried to do the same in code it would probably violate Misko's rule stating you should not inject an injectable into a newable, where the newable is the prototyped scoped object.


*Note: it may be more nuanced than black and white whether usage of an injected ApplicationContext is or is not good IoC. e.g. see comments by Alex Worden regarding enabling a sort of polymorphism where you "dynamically create new bean instances based on a bean name that is unknown at compile time but matches one of the implementations defined in my spring.xml file" - http://stackoverflow.com/questions/812415/why-is-springs-applicationcontext-getbean-considered-bad this might be a valid use of 'ContextAware. Commenters note that this is not really IoC but rather ordinary factory or Service Locator but pap notes that "Spring is about more than just IoC."

Similar question raised here.

Found this problem is similar to the question of how to do DI and the Command Pattern at the same time. Turns out they may be incompatible. see and see

DI - When to 'new'

Misko advises to keep "newables" separate from "injectables" - so newing things up are okay if they are value objects. http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

I go to that article via a comment in http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/  where he's emphatic about doing the DI. The "newable" exception is very important to consider. Specifically, a newable is an object a DI container would have NO WAY of know how to instantiate -- like a User() or PhoneNumber.

Continued...