@postflow

Классы и методы в разных пакетах, должны быть PUBLIC?

Пытаюсь выстроить декомпозицию приложение, так чтобы функционал разнести в разные pakeges. К примеру классы связанные с UI в соответствующий package. Классы участвующие в получении данных с сервера сервера в другой.

Для вызова метода из одно класса в другом (в разных пакетах! ). Я вынужден делать вызываемый класс/метод как public ? Таким образом в моём проекте все классы и методы имеют тип public. А как же инкапсуляция кода, безопасность и т.п. ?

Может я что-то не так понимаю?
  • Вопрос задан
  • 214 просмотров
Пригласить эксперта
Ответы на вопрос 2
@dmitryKovalskiy
программист средней руки
Может что-то и не понимаете. В частности разницу между интерфейсом класса и его внутренней кухней. С public методами вы разобрались видимо. Проблема в том как они реализованы. Если они состоят из простынь кода - возможно есть необходимость свернуть простыни в private-методы. Если по вашей логике класс клиент для одной задачи вынужден последовательно вызвать 3 public метода одного класса в стороннем package - эти 3 класса надо сделать private и сделать 1 public метод, внутри которого последовательно вызываются эти 3 private. В любом случае без вашего кода я тут могу долго фантазировать о том что вы там понаписали и почему у вас все public.
Ответ написан
Комментировать
TanVD
@TanVD
Джуниор C++/QT
Судя по всему вы построили слишком сильно-связанный код. При разнесении в разные пакеты вы столкнулись с ситуацией, что всякий класс взаимодействует со всяким другим классом и соответственно всё должно быть Public. Правильным решением в таком случае является уменьшение связанности кода, например, с помощью паттерна ООП фасад. То есть, для уменьшения связанности кода вам необходимо разбить код на группы по функциональности и через фасад предоставлять необходимую функциональность одной группе другой группе.
К примеру, вы можете создать группу классов работы с сетью, группы разных видов бизнес-логики, группу классов графического интерфейса.
Фактически, вы будете проводить декомпозицию монолитного куска кода на кластеры по некоторой логике. Это задача довольно нетривиальна, однако она как раз позволит верно инкапсулировать логику в пакеты и создать к ним адекватные интерфейсы с помощью фасадов. В результате вы сможете скрыть сложность внутренней логики за фасадами и даже впоследствии вынести некоторые классы в библиотеки.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы