2

I am currently working on a semi-large project that has several packages. There are 3 main packages, a "client" package, a "server" package and a "common" package. There are two jars, one for the client and one for the server each containing their own package and the common package. As is implied by the package names, there is a server and a client. The clients connect to the server and exchange messages. These messages take the form of a serilized subclass of Message. All subclasses of Message are in the common package. When a message is recieved, a method is called on the message class to handle the message. There is one subclass of Message that is responsible for sending the name of the clients to the servers. In the method that is called when the server recieves it, it then calls a setName() method on the object representing the connection between the server and client.

For obvious reasons, I don't want external programmers calling the setName() method however it has to be public because the message and the class to represent a connection are in different packages. I would like to know if it is good form to deprecate the method with a reason along the lines of "for internal use only", and if not, what is a better option?

  • Are you sure that code truly belongs in the server package and not common? Dependencies should never go two ways. That is madness! – user22815 Apr 9 '15 at 18:08
  • It works by serilizing subclasses of the "Message" class which is in common (along with all subclasses). Then, when the message is recieved a method is called on it depending on whether the server or client recieved it. This method is supposed to execute the code to handle the message. There is one message that tells the server what the name of the client is, and it calls a "setName" method on a server class. I do not want other programmers modifying the names of the clients because that will only serve to mess things up and cause weird bugs. – john01dav Apr 9 '15 at 18:10
  • 1
    Could you please edit your question and add more detail? I think you might be asking the wrong question, but I need more information to know how to address this. – user22815 Apr 9 '15 at 18:16
  • Ok, I've edited the message to include more detail. – john01dav Apr 9 '15 at 18:22
  • The only things it makes sense to deprecate are public ones. If they were private, you'd just refactor them away immediately. – Kilian Foth Apr 10 '15 at 8:22
3

You may need to consider some re-factoring.

So it looks like we have [Client] -message-> [Server] and Message (and all derivatives of) are stored in the [Common] package. In your comment you explain that the Message contains a function which gets called by either the Server or the Client depending on which received the message, which in turn calls a method on either the client or the server.

In my eyes, and just from what I can gather from your explanations, is that you should consider writing the message handling mechanisms right into either the client and server portions instead of having the message handling included as part of the message class.

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.