We Keep Coding

How to process polymorphic events without using instanceof

I'm designing an API that receives several event types all inheriting from a common base class. So lets say EventA and EventB inherit from BaseEvent
These events need to go trough several different processors.
So I though the visitor pattern would be a good choice here.
So the BaseEvent would look something like this:
public class BaseEvent implements Visitable {
void visit(Visitor visitor) {
visitor.visit(this);
}
}
So now I have an API that includes the Visitable and the Visitor types, but they are not really related to the API.
the processing is only done on the receiving side.
So I though about defining the API types without the Visitor interfaces and to define new types that include the visitors on the receiver of the events
But then I have to translate the API types to the new types and I don't see a way to do it without using instanseof for every event type
Does anyone see a solution for this?
Or maybe some other design that can solve the problem?
Thanks
Edit (Adding Some more info):
The events just hold information and on the receiver side they need to go through the processors.
I currently have 3 types of events (but that is likely to grow),
and 2 processors (this can also change but less likely)
I wanted to use the visitor pattern cause it forces me to add new methods to the processors when new events are added
If I just override the process() method for each type I will only catch errors in runtime when new events are added

I'm not sure what your use-case or architecture looks like, but I had a similar issue I think, with a trade routing system. There were events defined for routing a trade, getting acknowledgements, getting executions, etc. Events were only dumb objects, and there were processors with lots of if statements with instanceofs.
We decided to redesign the whole thing using "real" objects instead of events and processors. This means the "events" are no longer just holders of information, but they can "process themselves". Since they (at least in our use-case) had all the necessary information, they can actually process themselves better than one or multiple "external" processors.
There were multiple curious sideffects:
Dependencies became much clearer and easier.
We got rid of most of getters/setters, because asking an object for all of its information became unnecessary. This I found pretty cool.
So basically instead of a "bean" like this:
public class LimitOrderExecution ... {
private int executedAmount;
private int remainingAmount;
private BigDecimal executionPrice;
private Order order;
...more fields...
... setter / getter for everything ...
}
We now have:
public class LimitOrderExecution ... {
...fields...
public void apply() {
...applies itself using other objects...
}
}

There are several options:
instanceof
instanceof may not be that bad. Neither in regards of performance, nor from a coding-style POV. So why even use some workaround, if you don't need to?
Method overriding
Simply override the method for each Event that needs to be processed separately:
class EventReceiver{
void eventReceived(BaseEvent e){
}
void eventReceived(EventA e){
}
...
}
Same could of course be done for your visitor-pattern. Though the visitor-pattern would be rather superfluous here.
Another event-structure
If you don't want to distinguish your events by type, just add a variable that allows identification of the event without instanceof. Though that'd just be a workaround to the instanceof operator.

Imposing constraints or restrictions on method body, in Java

Context (Edit)
Some clarification was on demand, so I'll try to sum up what influences the question.
The goal of the project is to provide a certain functionality to programmers, most probably in the form of a library (a JAR with class files, I guess).
To use said functionality, programmers would have to conform to the constraints that must (should) be satisfied. Otherwise it won't function as expected (just like the locks from java.util.concurrent, that must be acquired / freed at the appropriate time and place).
This code won't be the entry point to the applications using it (ie, has no main).
There's a limited (and small) amount of operations exposed in the API.
Examples:
Think of a small game, where almost everything is implemented and managed by the already implemented classes. The only thing left for the programmer to do, is to write a method, or a couple of them, that describe what the character will do (walk, change direction, stop, inspect object). I would want to make sure that their methods (possibly marked with an annotation?) just walk, or changeDirection, or calculate diff = desiredValue - x, and not, say, write to some file, or open a socket connection.
Think of a transaction manager. The manager would be provided by this library, as well as some constant attributes of transactions (their isolation level, time-outs, ...). Now, the programmers would like to have transactions and use this manager. I would want to make sure that they only read, write, commit, or rollback on some resources, known to the manager. I wouldn't want them to launchRocket in the middle of the transaction, if the manager does not control any rockets to launch.
The Problem
I want to impose some invariants / restrictions / constraints on the body of a method (or group of methods), to be later implemented by some other programmer, in some other package/location. Say, I give them something along the lines of:
public abstract class ToBeExtended {
// some private stuff they should not modify
// ...
public abstract SomeReturnType safeMethod();
}
It is important (probably imperative), for the purposes of this project, that the method body satisfies some invariants. Or rather, it is imperative that the set of commands this method's implementation uses is limited. Examples of these constraints:
This method must not perform any I/O.
This method must not instantiate any unknown (potentially dangerous) objects.
...
Put another way:
This method can call the methods of a known (specific) class.
This method can execute some basic instructions (maths, assign local variables, ifs, loops...).
I've been looking through Annotations, and there seems to be nothing close to this.
My options so far:
Define some annotation, #SafeAnnotation, and apply it to the method, defining a contract with the implementer, that he will follow the rules imposed, or else the system will malfunction.
Define an Enum with the allowed operations. Instead of exposing the allowed methods, only a method is exposed, that accepts a list of these enum objects (or something similar to a Control Flow Graph?) and executes it, giving me the control of what can be done.
Example:
public enum AllowedOperations { OP1, OP2 }
public class TheOneKnown {
public void executeMyStuff (List<AllowedOperations> ops) {
// ...
}
}
My Question
Is there any feature in the language, such as annotations, reflection, or otherwise, allowing me to inspect (either at compile time or runtime) if a method is valid (ie, satisfies my constraints)?
Or rather, is there any way to enforce it to call only a limited set of other methods?
If not (and I think not), would this second approach be a suitable alternative?
Suitable, as in intuitive, well designed and/or good practice.
Update (Progress)
Having had a look at some related questions, I'm also considering (as a third option, maybe) following the steps given in the accepted answer of this question. Although, this may require some rethinking on the architecture.
The whole idea of using annotations to impose restrictions seems to require implementing my own annotation processor. If this is true, I might as well consider a small domain-specific language, so that the programmer would use these limited operations, later translating the code to Java. This way, I would also have control over what is specified.

Have a look at java policy files. I've not used them, and I'm not sure they'll fit your problem exactly, but with some digging into the docs they may be a fit. Here's a couple SO questions that may be of help
Limiting file access in Java
What is a simple Java security policy for restricting file writes to a single directory?
And here's some documentation on the policy file.
http://docs.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html

I think that the direction in this question is good.
Use a specific ClassLoader lo load the class. Beware, that they're an interesting type of horse, it usually happens that the class itself is loaded by a parent classloader. Probably you want some sort of UrlClassLoader, and the parent classloader would be set to the Root classloader It is not enough, though.
Use threads to avoid infinite loops (rather implementing Runnable than extending Thread, like there) - this may be unnecessary if you're not worrying about it.
Use SecurityManager to avoid java.io operations
In addition to the above, I recommend 2 options:
Give the method a controller, that would contain the functions it can call
For example:
public void foo(Controller ctrl) {
}
public class Controller {
public boolean commit();
public boolean rollback();
}
This can give the user a handle, what operations are allowed.
Use an Intent-like command pattern
In Android, the components of the system are quite closed. They cannot directly communicate to each other, they only can fire an event, that "this happened", or "I want to do that".
This way the set of the usable commands are not restricted. Usually, if the methods do only small business logic, that is enough.

You can restrict the classes used by untrusted code with a custom class loader:
public class SafeClassLoader extends ClassLoader {
Set<String> safe = new HashSet<>();
{
String[] s = {
"java.lang.Object",
"java.lang.String",
"java.lang.Integer"
};
safe.addAll(Arrays.asList(s));
}
#Override
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException {
if (safe.contains(name)) {
return super.loadClass(name, resolve);
} else {
throw new ClassNotFoundException(name);
}
}
}
public class Sandboxer {
public static void main(String[] args) throws Exception {
File f = new File("bin/");
URL[] urls = {f.toURI().toURL()};
ClassLoader loader = new URLClassLoader(urls, new SafeClassLoader());
Class<?> good = loader.loadClass("tools.sandbox.Good");
System.out.println(good.newInstance().toString());
Class<?> evil = loader.loadClass("tools.sandbox.Evil");
System.out.println(evil.newInstance().toString());
}
}
public class Good {
#Override
public String toString() {
return "I am good";
}
}
public class Evil {
#Override
public String toString() {
new Thread().start();
return "I am evil.";
}
}
Running this will result in
I am good
Exception in thread "main" java.lang.NoClassDefFoundError: java/lang/Thread
at tools.sandbox.Evil.toString(Evil.java:7)
at tools.sandbox.Sandboxer.main(Sandboxer.java:18)
Caused by: java.lang.ClassNotFoundException: java.lang.Thread
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 2 more
Of course, this assumes care is taken with the classes you white list. It also can't prevent denial of service stuff such as
while (true) {}
or
new long[1000000000];

Another alternative will be to use en embedded script interpreter, for example groovy one (https://docs.groovy-lang.org/latest/html/documentation/guide-integrating.html) and to evaluate the third-party methods content at runtime with a pre-execution validation.
Advantage is that you will be able to limit access to only the variables you will bind for the script execution.
You could also write your own validation dsl and apply it, for example using custom annotation, to the method that will execute the script.

There are several design by contract libraries available for Java, but I'm not able to recommend one in particular. Java Argument Validation appears to be a lightweight solution, but again, I don't have first-hand experience with it.

How to write test cases for complex underlying entity?

I am wriring unit test cases for an existing system. The architecture for the underlying classes if very complex in itself.
Blockquote
RequestHanndler ==> processes ==> Order ===> is dependent on ==> service layer == connected to ==> DB layer.
I am writing a test case for RequestHandler. The method in test(doProcess()) creates a new instance of Order class. Order class itself has very tight dependency on the service layer. I want to create an atomic test case, so, not any other layer of code will be executed.
What should the best process to create test cases for these scenrios?

It might get a bit complicated when you want to write unit-tests for tighly coupled code. To make uni-testing easier you should better rely on abstractions and not on real implementations. E.g. the Order class shouldn't depend on the real implementation of the service layer, instead introduce an interface which is much easier to mock instead of a class which might be set to final.
Since your RequestHandler is responsible for creating the Order instances you'll have to provide a way to mock out the order class in unit-tests. A simply way is to create a protected method that simply creates a new order instance.
protected Order createOrder(String someParam) {
return new Order(someParam);
}
In your Unit-Tests you can now extend the class and overwrite the factory-method.
Using Mockito this would look like:
protected Order createOrder(String someParam) {
Order order = Mockito.mock(Order.class); // create mock object
// configure mock to return someParam when
// String Order#getSomeParam() gets invoked
Mockito.doReturn(someParam).when(order).getSomeParam();
return order;
}

Typical approach for unit testing of such systems is mocking. There are several mockup frameworks for java. I personally used EasyMock but there are others.
So, I think that you should to try to test the logic of request handler first. You should mock Order (i.e. create dummy, not real instance of order using mockup frameork). When this layer is tested go deeper and start testing internal layers.
Other strategy is going from down to up, i.e. test first the internal layers. This strategy is probably "right" but it you will not get fast results that you can show to your manager because managers typically like to see the "big" picture and very seldom go into the details.
Bottom line: good luck.

How much should be done in a constructor

This is a theory question I guess that I am using to find the standard procedure for this.
If I have a Constructor method that does a whole lot of setup operations gathering data and such, should I keep "all things construction" in the constructor, or should I try to call other methods from inside the constructor (for code looks basically), or should I just initialize everything I have to and leave other things to be dealt with later if they are actually needed?
Here is an example.
I am creating an object that is a collection manager basically. It needs to read in data from a file and it stores it inside of an array.
Do I use the constructor to just create an object with base properties and read data later,
or should I read in all the info and set up the array inside the constructor which saves time later but takes up extra time here, or should I do something along the lines of
public myConstructor(String filename) {
data = readDataIn(filename);
}
This is not actual code, just an example of outsourcing to different methods to "pretty up the code" instead of a super long constructor method I can have say 5-6 short and good looking methods that can only be accessed by the constructor.

The constructor should do just enough work to get the instance into a state that satisfies its contract. Each method should then do just enough work to fulfill the method's contract and leave the instance in a state that satisfies its contract.
Very rarely should a constructor call cause side-effects or modify its inputs. These are just not often required to satisfy a contract. For example, a connection class shouldn't touch the network on construction. Since it has to be closeable, the closed state must be part of its contract, and so the "just enough work" standard dictates that the constructor puts it in a ready, but not yet open state.
Your particular example couples your class to the file system. You would probably get a more testable, more general class by using Guava Files to do the reading and taking a string with the content instead. You can get the convenience of a constructor coupled to the file system by writing a convenient static MyClass fromFile(String path) factory function that does new MyClass. That moves the portion of your code that is coupled to the filesystem outside the portion that interacts with instance variables reducing the number of possible interactions to test. As others have noted, dependency injection is another good way to achieve decoupling.

Really depends on your API style. Note that you may wish to have multiple constructors, such as:
public MyThing(String filename) { }
public MyThing(FileInputStream filestream) {}
public MyThing(File file) { }
public MyThing(byte[] rawdata) { }
at which its judicious to consolidate the file loading operation into a method or two (file open and file parse)

In this case, I would use dependency injection, so that your constructor requires data that has already been computed, and defers the computation to whatever invokes the constructor. I might provide an additional static factory function that does all this complicated setup so that it is convenient to construct this object (e.g. in tests), but at least it would be possible for the user of this class to come up with a more clever (possibly parallelized or lazily-initialized) way of creating this class.

Java Socket RPC protocol

I've been asking some questions about adapting the command protocol for use in my client server environment. However, after some experimentation, I have come to the conclusion that it will not work for me. It is not designed for this scenario. I'm thus at a loose end.
I have implemented a sort of RPC mechanism before whereby I had a class entitled "Operation". I also had an enum entitled "Action" that contained names for actions that could be invoked on the server.
Now, in my old project, every time that the client wanted to invoke an action on the server, it would create an instance of 'Operation' and set the action variable with a value from the "Action" enum. For example
Operation serverOpToInvoke = new Operation();
serverOpToInvoke.setAction(Action.CREATE_TIME_TABLE);
serverOpToInvoke.setParameters(Map params);
ServerReply reply = NetworkManager.sendOperation(serverOpToInvoke);
...
On the server side, I had to perform the horrible task of determining which method to invoke by examining the 'Action' enum value with a load of 'if/else' statements. When a match was found, I would call the appropriate method.
The problem with this was that it was messy, hard to maintain and was ultimately bad design.
My question is thus - Is there some sort of pattern that I can follow to implement a nice, clean and maintainable rpc mechanism over a TCP socket in java? RMI is a no go for me here as the client (android) doesn't support RMI. I've exhausted all avenues at this stage. The only other option would maybe be a REST service. Any advice would be very helpful.
Thank you very much
Regards

Probably the easiest solution is to loosely follow the path of RMI.
You start out with an interface and an implementation:
interface FooService {
Bar doThis( String param );
String doThat( Bar param );
}
class FooServiceImpl implements FooService {
...
}
You deploy the interface to both sides and the implementation to the server side only.
Then to get a client object, you create a dynamic proxy. Its invocation handler will do nothing else but serialize the service classname, the method name and the parameters and send it to the server (initially you can use an ObjectOutputStream but you can use alternative serialization techniques, like XStream for example).
The server listener takes this request and executes it using reflection, then sends the response back.
The implementation is fairly easy and it is transparent from both sides, the only major caveat being that your services will effectively be singletons.
I can include some more implementation detail if you need, but this is the general idea I would follow if I had to implement something like that.
Having said that, I'd probably search a bit more for an already existing solution, like webservices or something similar.
Update: This is what an ordinary (local) invocation handler would do.
class MyHandler implements InvocationHandler {
private Object serviceObject;
#Override
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
return method.invoke(serviceObject, args);
}
}
Where serviceObject is your service implementation object wrapped into the handler.
This is what you have to cut in half, and instead of calling the method, you need to send the following to the server:
The full name of the interface (or some other value that uniquely identifies the service interface)
The name of the method.
The names of the parameter types the method expects.
The args array.
The server side will have to:
Find the implementation for that interface (the easiest way is to have some sort of map where the keys are the interface names and the values the implementation singleton instance)
Find the method, using Class.getMethod( name, paramTypes );
Execute the method by calling method.invoke(serviceObject, args); and send the return value back.

You should look into protocol buffers from google: http://code.google.com/p/protobuf/
This library defines an IDL for generating struct like classes that can be written and read from a stream/byte array/etc. They also define an RPC mechanism using the defined messages.
I've used this library for a similar problem and it worked very well.

RMI is the way to go.
Java RMI is a Java application
programming interface that performs
the object-oriented equivalent of
remote procedure calls (RPC).