Мне поручено создать многократно используемое программное обеспечение как библиотеку /API. Сейчас у меня есть все классы, которые являются публичными в нескольких пакетах, а методы внутри них в основном закрыты.
Поскольку это должен быть API, я хочу скрыть все классы, за исключением того, что выставляете несколько классов и методов.
Я не могу использовать частный модификатор для классов, поскольку я обращаюсь к ним в других пакетах проекта. Я также не хочу наследовать классы без необходимости, чтобы получить доступ к методам внутри.
Что делать, чтобы выставлять определенные классы и методы, сохраняя при этом возможность доступа к ним в моем проекте?
Я действительно предлагаю вам составить диаграмму ниже на листе бумаги, прежде чем приступать к разработке вашего API.
Предварительная работа
Вы идентифицировали все типы взаимодействующих объектов. Каждый объект может быть сформирован в объект.
На каком уровне (Controller/Facade/DAO и т.д.) Вы хотите использовать каждый из них.
Любой объект, который предполагается передать по сети.
Какие данные будет отображаться для всего вашего API.
Проектирование Обычно вы хотите сделать следующее: - Если ваши сущности (в части 1) связаны и могут содержать общую информацию, создайте 1 объект (пример Common
), чтобы сохранить общие данные (например, отметки времени запроса, информация об устройстве и т.д.), и сделать других, которые могут содержать эту информацию, наследовать эту сущность. обеспечить, чтобы свойства общей организации были защищены. Обычное будет выглядеть примерно так
public class Common{
protected _deviceId;
protected _reqTimeStamp;
protected _osVersion;
//Getters and Setters.
}
Например, если API использует данные запроса JSON, полученные от Mobile Apps, вы можете иметь Common, чтобы содержать данные, приведенные выше в пункте 1. Вы можете создать другой объект следующим образом
public class UserInfo extends Common{
private String _userName;
private String _userMailId;
//getters and setters
}
Попытайтесь сохранить минимальные объекты для передачи данных между слоями. Если сервисные уровни, обслуживаемые вашим API, расположены на разных серверах, тогда вы можете захотеть сохранить Serializable и убедиться, что такие DTO не содержат кусков огромной информации.
Аналогично, когда вы отделяете функциональность вашего API, попробуйте увидеть, какие функции похожи и обычно требуются. Переместите их в абстрактные классы и сделайте реализации интерфейсов, которые классифицируют другое поведение, расширят абстрактные классы.
См. Этот пример ниже.
public abstract class CommonBehaviour {
protected String _commonId;
public void commonBehaviourOne()
{
//Behaviour common to implementations
}
abstract public void overrideThisBehaviour();
//getters and setters
}
Итак, теперь, если у вас есть два типа поведения в реализациях, которые имеют общую функциональность между ними.
public interface Designable {
}
public class DesignerImpl extends CommonBehaviour implements Designable {
@Override
public void overrideThisBehaviour() {
// TODO Auto-generated method stub
}
}
Решение сделать классы общедоступными, частными или дефолтными будет легким, если у вас есть предварительные условия ясными. Вы должны провести мозговой штурм, обсудить между заинтересованными сторонами и провести мозговой штурм снова. Вы обязательно придумаете хороший API
Ссылки для вашей помощи
Существует много информации, доступной в Интернете для людей, которые входят в проектирование. Что касается книг, я сослался на " Head First Design Patterns " и " Design Patterns" от Gamma. Хотя я нашел Gamma более всеобъемлющим, бывший хорош для новичков.
Дайте мне знать, если это вам поможет.
Сделайте ваши классы общедоступными, если у вас есть методы для раскрытия. Метод, который используется локально в своем классе, должен быть закрытым. Метод, который должен быть раскрыт, воспринимается публично. Метод, который должен быть видимым внутри вашего API, а не отключен, берется защищенным или по умолчанию.
В API вы должны показывать только интерфейсы и бизнес-объекты. Обычно они находятся на разных артефактах maven, чем реализация интерфейсов.
Короче: создайте проект maven для объектов домена, другой для интерфейсов API и другой для реализации API. Затем раздайте своим клиентам только первые два.
Что касается зависимостей: проект реализации должен зависеть как от проектов API, так и от бизнес-объектов. Проект API должен зависеть только от проекта бизнес-объектов. Проект бизнес-объекта не должен зависеть ни от того, ни от того.
default
илиprotected
элементах управления доступом. они могут быть тем, что вам нужно.