Answer the question
In order to leave comments, you need to log in
Are classes and methods in different packages supposed to be PUBLIC?
I'm trying to build a decomposition of the application, so that the functionality is spread into different pakeges. For example, classes related to UI in the corresponding package. Classes involved in getting data from a server to another server.
To call a method from one class in another (in different packages! ). Am I forced to make the called class/method as public ? Thus, in my project, all classes and methods are of type public. But what about code encapsulation, security, etc. ?
Maybe I'm misunderstanding something?
Answer the question
In order to leave comments, you need to log in
Maybe you don't understand something. In particular, the difference between a class interface and its internal kitchen. You probably figured out the public methods. The problem is how they are implemented. If they consist of sheets of code, there may be a need to wrap the sheets into private methods. If, according to your logic, the client class for one task is forced to sequentially call 3 public methods of one class in a third-party package - these 3 classes must be made private and 1 public method should be made, inside which these 3 private ones are sequentially called. In any case, without your code, I can fantasize for a long time about what you wrote there and why you have everything public.
It looks like you've built overly-coupled code. When expanding into different packages, you are faced with the situation that every class interacts with every other class and, accordingly, everything should be Public. The correct solution in this case is to reduce the coupling of the code, for example, using the Facade OOP pattern . That is, to reduce code cohesion, you need to break the code into groups according to functionality and provide the necessary functionality to one group to another group through the facade.
For example, you can create a group of networking classes, groups of different types of business logic, a group of GUI classes.
In fact, you will decompose a monolithic piece of code into clusters according to some logic. This task is rather non-trivial, but it will just allow you to correctly encapsulate the logic in packages and create adequate interfaces to them using facades. As a result, you can hide the complexity of internal logic behind facades and even later move some classes to libraries.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question