5

I and two university colleagues of mine are designing a simple CMS software for a university exam using UML. Such software just needs to deal with sending an article, assigning an article for review, sending a review and scoring an article. Our solution expects a 3-tier client-server architecture, with tiny clients requesting services and a server responding to requests by interfacing with a DBMS (persistent data) and a SMTP server (e-mail notifications).

I'm at a point where I can't decide how to structure my client-side classes. I figured out a set of boundary classes representing single services and contain related methods (authentication, submit paper, review paper...), and a single control class which roles are requesting connection to the server and the creation of a new session, and it contains the methods to actually send messages to the server.
This is according to the single responsibility principle that states that any class should be responsible over a single functionality of the software: so, I have a class for signing up/logging in, one to submit an article, and so on, and then the control class that receives requests from other boundary classes and send messages to the server.

Client requests are sent to the server via a control class

On the other hand, I was told by other people I asked that I could even get rid of my client-side controller class and give boundary classes methods to directly send request messages to the server. This still seems legit to me: boundary classes only send requests according to the particular service they were supposed to provide to the user.

Question is: is having a control class in my client application useful, redundant, or wrong at all? How can I improve my classes structure?

Improve this question
6
  • 1
    Well, as always: it depends. You can get rid of your client controller, but at what cost. Look at your browser. It received more and more controllers you don't notice. When you type in Google search it interacts. And clients get faster each day. So what's the point in removing it? To strip it to 74xx logic bricks?
    – user188153
    Nov 20, 2015 at 9:29
  • You have tagged this question with "java". Does this mean that the client-side classes will be Java classes? Do you have any constraints on the client-side technology to be used, like libraries / frameworks? Based on functional and non-functional requirements, you should choose the technologies and libraries first. This choice will probably give you a direction with regard to the client software design.
    – www.admiraalit.nl
    Nov 20, 2015 at 9:43
  • @www.admiraalit.nl No costrains about technology, nor frameworks. Libraries include JavaMail, Swing, JDBC-ODBC, and the socket library. These packages are included but not shown in my figure because I'm focusing on application classes rather than components.
    – liggiorgio
    Nov 20, 2015 at 9:50
  • 1
    I don't have experience with Swing, but I know it is based on the MVC pattern. When applying this pattern, I would expect one controller per view. In addition, I would expect one extra controller to encapsulate the messaging over the socket for all views, like ctrClientManager, which is responsible for creating the socket, the message streams and other message-related plumbing, to avoid code duplication in the boundary classes.
    – www.admiraalit.nl
    Nov 20, 2015 at 10:36
  • 1
    No, the quality of software is not correlated to the number of classes. Good quality means that every class has a well-defined responsibility, that different concerns are separated in different classes and that code is not duplicated.
    – www.admiraalit.nl
    Nov 20, 2015 at 13:11

1 Answer 1

Reset to default
3

Question is: is having a control class in my client application useful, redundant, or wrong at all? How can I improve my classes structure?

It is useful. Your controller, ctrClientManager, encapsulates the messaging over the socket; it is responsible for creating the socket, the message streams and other message-related plumbing. Every boundary class needs this functionality and it would lead to code duplication if every boundary class would directly send messages.
It improves maintainability, because if something needs to be changed generically in the communication between client and server, you can do that at a central place (the controller) instead of adapting each and every boundary class.
It improves reliability, because the chance that there is a bug in one central piece of code is less than the chance that there is a bug in one of the many copies of the same code.

By the way, it is recommended to apply the MVC pattern, where each view (boundary class) has its own controller, to control the user interaction. In addition, you should have the central messaging controller, called ctrClientManager in your example.

Improve this answer
1
  • Thanks for the answer and your advices, I'll deepen knowledge about MVC pattern in order to better structure my system.
    – liggiorgio
    Nov 21, 2015 at 20:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.