Objects + Idea of Single Responsibility

Two questions:

1) Let's say you have an instant messenging server. (I am using the conditional because I have already made the server and am really curious about the client, yet this is the same problem with an easier example to explain.) The server has to validate the user's registration, register the user on the MySQL database, and then send a packet to the user indicating whether the registration was successful. I am not using RMI, so the server will have to put together a packet containing a header (message ID, message length) and a body (NTStrings, integer flags, etc.). Should I have a single User object handle these three responsibilities and give the User object helper objects (a socket interface, a MySQL database interface, and an interface that handles the protocol) or should I create a RegistrationValidator object for validating the user's registration, a RegistrationInformer object for building a packet, and a DatabaseRegistration object for the database (with all of these objects using their logical helper objects that I mentioned before).

2)

{

Let's say for question (1), I choose to break the responsibilities of the User into a few classes. For sending packets to clients, should the server have classes for each packet (there are only like 5 or so packets) and have those packets build and send themselves? If so, should I use this in conjunction with a PacketFactory that takes theknow-the-implementation-and-do-the-instantiation responsibility away from the rest of the program?

Or if I choose the User-class-do-it-all route for (1), I could just have a PacketFactory that constructs a packet and returns an array of bytes to the requestor (in this case the User). This is what I did in my already-existing server program. (Once again, I'm using a hypothetical case because it best explains my questions in another case.)

}

I know that these questions may be a matter of preference but I am just wondering what you think is best in this situation. This may seem like a really picky and weird question but this is one of the few places that I can get second opinions =(.

[2167 byte] By [ktm5124a] at [2007-10-2 21:47:42]
# 1
Database should be in its own layer.Communications should be in its own layer.As to how many classes are in each that depends on what they do.
jschella at 2007-7-14 1:03:23 > top of Java-index,Other Topics,Patterns & OO Design...
# 2

Ah, thanks.

A follow-up question:

How should you connect these layers to the GUI layer (controller). The GUI will be generating events and will thus have to inform the model layer (which consists of the database and communications layers among other layers). Should the GUI instantiate the model layer? Should it be passed a reference to the model layer by constructor, method, or factories/builders? Will it be a problem that the model layers are acting in the GUI's thread?

ktm5124a at 2007-7-14 1:03:23 > top of Java-index,Other Topics,Patterns & OO Design...
# 3

> Should the GUI instantiate the

> model layer? Should it be passed a reference to the

> model layer by constructor, method, or

> factories/builders?

It's better to have some composer class (e.g. the program's main class) instantiate the model, then instantiate the "GUI" (or merely, as you mention, the controller), and pass it a reference to the model (by constructor or method, that's a matter of preference).

Note that you may even not code the wiring explicitly, by using an IOC framework ?la spring, where the dependencies may be configured externally to the Java code. But if the purpose of this development is self-teaching, you can leave that point for a next iteration.

> Will it be a problem that the

> model layers are acting in the GUI's thread?

It may be a problem, but it has nothing to do with the way you instantiate eother of them.

The problem will arise if the model operations take time (which is likely to happen if the model operations end up doing networking, or intense processing): then the graphical thread will be late or stuck before handling its graphical responsibilities (handling events and repaints). Swing in particular has only one such event thread, so blocking it hogs the whole GUI.

jdupreza at 2007-7-14 1:03:23 > top of Java-index,Other Topics,Patterns & OO Design...
# 4

it is a problem for the model methods to be called in the GUI thread. You have to mark your interface to tell the caller which methods may block and which return instantly. That way the GUI can decide if it wants to spawn a seperate thread for that call to the model so the GUI can continue to update itself.

This works both ways as well. Sometimes the GUI listens to the model. Then the model fires an event and it ends up the GUI is manipulated in the model's thread which is equally as bad but typically fails instantly :P

_dnoyeBa at 2007-7-14 1:03:23 > top of Java-index,Other Topics,Patterns & OO Design...