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?

Improve this question
7
  • 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, 2015 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, 2015 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, 2015 at 18:16
  • Ok, I've edited the message to include more detail.
    – john01dav
    Apr 9, 2015 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, 2015 at 8:22

1 Answer 1

Reset to default
4

You may need to consider some re-structuring.

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.

Improve this answer
1
  • Exactly this, it's a perfect example of when not to get too dogmatic with OOP.
    – Turksarama
    Feb 13 at 4:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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