Simple code design question

Question

I have a 3 layer app. The second layer is receiving and object from the 3rd layer and there are two attributes from this object that I need to pass on to the 1st layer (UI). Should I make this object's class visible in the 1st layer (by importing it's package/namespace, which I'm trying to avoid) or should I pass on these attributes as an string array (I'd rather have an Object array, but they're a string and an int types in Java 1.4) and cast them to their proper types in compilation time (Their types are fixed, so thankfully this is an option)?

Answer 1

That's what DTOs (Data Transfer Objects) are for. So in short: use Objects in your top-level interface.

• makoshichi: That would be my first choice. But I'm kinda new to Java (specially working with 1.4, which lacks of A LOT of things) and since one of these attributes is an int (primitive type), Java doesn't allow me to cast it to Object (opposed to C#) and I really think it's unecessary to have an Integer type (which can be cast to Object and back). What are your thoughts on that?
• Jan Galinski: You won't need to care about primitives. Just create a class MyDTO implements Serializable { private int myNumValue; private String myStringValue; ... getters/setters } and use it in your Facade-API

Answer 2

I'm no java expert, but I can offer some general advice from a .NET perspective. Since that's your background it should be relevant to you.

Should I make this object's class visible in the 1st layer (by importing it's package/namespace, which I'm trying to avoid

Its OK to import the namespace. While it may feel like you decrease coupling, this is better than a string array as it does not require expensive boxing.

Do not forget that readability is always a serious consideration. I recommend you take a look at the MVC pattern.

• makoshichi: That was my first choice (as a .NET developer, as yourself put it)... I'm not really into Java's inner workings yet so I figure I should stick with that.

Answer 3

Sounds like JavaBeans are your friend, although you'll probably not profit from reusability/serializabiliy.

JavaBeans are classic DTOs (Data Transfer Objects), used to pass along information in your program.

Answer 4

What kind of UI do you have? Swing? Then DTOs is probably the way to go. Consider to put the DTO classes in a project of its own, which then can be shared by the client side and the server side.

• makoshichi: Actually it's an embedded app for a MFP (Multifunctional Printer), so I basically use a subset of JVM 1.4 and the UI classes are from the printer manufacturer... I'm pretty tight restraints here...
• Puce: But the other 2 layers run on a stand-alone server or in embedded mode? Or in other words: are there remote calls/ are there 2 JVMs involved? If yes, have a look at the DTO pattern.