Sunday, January 22, 2017

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

Sunday, August 30, 2015

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

Thursday, August 27, 2015

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

Tuesday, August 11, 2015

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

Thursday, March 26, 2015

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

Wednesday, January 21, 2015

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