Какой ОО дизайн использовать (есть ли шаблон дизайна)?

У меня есть два объекта, которые представляют «Бар / Клуб» (место, где вы пьете / общаетесь).

В одном сценарии мне нужно имя бара, адрес, расстояние, слогон

В другом сценарии мне нужно название бара, адрес, URL сайта, логотип

Итак, у меня есть два объекта, представляющих одно и то же, но с разными полями.

Мне нравится использовать неизменяемые объекты, поэтому все поля задаются из конструктора .

Один вариант - иметь два конструктора и обнулять другие поля, т.е.

class Bar {
     private final String name;
     private final Distance distance;
     private final Url url;

     public Bar(String name, Distance distance){
          this.name = name;
          this.distance = distance;
          this.url = null;
     }

     public Bar(String name, Url url){
          this.name = name;
          this.distance = null;
          this.url = url;
     }

     // getters
}

Мне это не нравится, так как вам придется проверять ноль, когда вы используете геттеры

В моем реальном примере первый сценарий имеет 3 поля, а второй - около 10, так что было бы очень сложно иметь два конструктора , количество полей, которые я должен был бы объявить нулевым, а затем, когда объект используется, вы не захотите Не знаю, какие Barвы используете, и какие поля будут нулевыми, а какие нет.

Какие еще варианты у меня есть?

Два класса называется BarPreviewи Bar?

Какой-то тип наследования / интерфейс?

Что-то еще, что удивительно?

Мои мысли:

«Бар», представленный в вашем домене, содержит все, что может понадобиться в любом месте: имя, адрес, URL, логотип, слоган и «расстояние» (я полагаю, из местоположения запрашивающей стороны). Следовательно, в вашем домене должен быть один класс «Bar», который является официальным источником данных для одного бара, независимо от того, где эти данные будут использоваться позже. Этот класс должен быть изменяемым, чтобы при необходимости можно было вносить изменения в данные панели и сохранять их.

Однако у вас есть два места, в которых нужны данные этого объекта Bar, и им обоим нужно только подмножество (и вы не хотите, чтобы эти данные были изменены). Обычный ответ - «объект передачи данных» или DTO; POJO (обычный старый Java-объект), содержащий неизменяемые свойства get. Эти DTO могут быть получены путем вызова метода основного объекта домена Bar: "toScenario1DTO ()" и "toScenario2DTO ()"; результаты - гидратированный DTO (это означает, что вам нужно использовать только длинный и сложный конструктор в одном месте).

Если вам когда-нибудь нужно было отправить данные обратно в основной класс домена (чтобы обновить его; какой смысл в данных, если вы не можете изменить их по мере необходимости, чтобы отразить текущее состояние реального мира?), Вы можете создать один из DTO или используйте новый изменяемый DTO и передайте его обратно классу Bar с помощью метода updateFromDto ().

РЕДАКТИРОВАТЬ: предоставить пример:

public class Bar {
     private String name;
     private Address address; 
     private Distance distance;
     private Url url;
     private Image logo;
     private string Slogan;

     public OnlineBarDto ToOnlineDto()
     {
         return new OnlineBarDto(name, address, url, logo);
     }

     public PhysicalBarDto ToPhysicalDto()
     {
         return new PhysicalBarDto(name, address, distance, slogan);
     }

     public void UpdateFromDto(PhysicalBarDto dto)
     {
         //validation logic here, or mixed into assignments

         name = dto.Name;
         address = dto.Address;
         distance = dto.Distance;
         slogan = dto.Slogan;
     }

     public void UpdateFromDto(OnlineBarDto dto)
     {
         //Validate DTO fields before performing assignments

         name = dto.Name;
         address = dto.Address;
         url= dto.Url;
         logo = dto.Logo;
     }

     // getters/setters - As necessary within the model and data access layers;
     // other classes can update the model using DTOs, forcing validation.
}

public class PhysicalBarDto
{
     public final String Name;
     public final Address Address;
     public final Distance Distance;
     public final String Slogan;

     public PhysicalBarDto(string Name, Address address, Distance distance, string slogan) 
     { //set instance fields using parameter fields; you know the drill }
}

public class OnlineBarDto
{
     public final String Name;
     public final Address Address;
     public final Image Logo;
     public final Url Url;

     public OnlineBarDto(string Name, Address address, Url url, Image logo) 
     { //ditto }
}

Классы Address, Distance и Url должны быть либо неизменяемыми, либо при использовании в DTO их следует заменять неизменяемыми аналогами.

Если вы заботитесь только о подмножестве свойств и хотите убедиться, что они не перепутаны, создайте два интерфейса и используйте их для связи с вашим базовым объектом.

Здесь может быть полезен Образец Строителя (или что-то близкое к нему).

Наличие неизменных объектов - замечательная вещь, но реальность такова, что с Reflection в Java нет ничего действительно безопасного ;-).

Ключевым моментом здесь является разница между тем, что такое «Бар», и тем, как вы используете его в том или ином контексте.

Бар - это единое целое в реальном мире (или искусственном мире, таком как игра), и только ОДИН экземпляр объекта должен представлять его. В любое время позже, когда вы не создадите этот экземпляр из сегмента кода, а загрузите его из файла конфигурации или базы данных, это станет более очевидным.

(Чтобы быть еще более эзотерическим: каждый экземпляр Bar имеет свой жизненный цикл, отличный от объекта, который представляет его при запуске вашей программы. Даже если у вас есть исходный код, который создает этот экземпляр, это означает, что сущность Bar, как она описана, "существует" "в состоянии покоя в исходном коде и" пробуждаться ", когда этот код фактически создает его в памяти ...)

Извините за долгое начало, но я надеюсь, что это проясняет мою точку зрения. У вас есть ОДИН класс Bar, имеющий все атрибуты, которые вам когда-либо понадобятся, и один экземпляр Bar, представляющий каждую сущность Bar. Это правильно в вашем коде и не зависит от того, как вы хотите видеть один и тот же экземпляр в разных контекстах .

Последний может быть представлен двумя различными интерфейсами , которые содержат необходимые методы доступа (getName (), getURL (), getDistance ()), и класс Bar должен реализовывать оба. (И, возможно, «расстояние» изменится на «местоположение», а getDistance () станет вычислением из другого места :-))

Но создание предназначено для сущности Bar, а не для того, как вы хотите использовать эту сущность: один конструктор, все поля.

Отредактировано: я могу написать код! :-)

public interface Place {
  String getName();
  Address getAddress();
}

public interface WebPlace extends Place {
   URL getUrl();
   Image getLogo();
}

public interface PhysicalPlace extends Place {
  Double getDistance();
  Slogon getSlogon();
}

public class Bar implements WebPlace, PhysicalPlace {
  private final String name;
  private final Address address;
  private final URL url;
  private final Image logo;
  private final Double distance;
  private final Slogon slogon;

  public Bar(String name, Address address, URL url, Image logo, Double distance, Slogon slogon) {
    this.name = name;
    this.address = address;
    this.url = url;
    this.logo = logo;
    this.distance = distance;
    this.slogon = slogon;
  }

  public String getName() { return name; }
  public Address getAddress() { return address; }
  public Double getDistance() { return distance; }
  public Slogon getSlogon() { return slogon; }
  public URL getUrl() { return url; }
  public Image getLogo() { return logo; } 
}

Соответствующий шаблон

То, что вы ищете, чаще всего называют Null Object Pattern. Если вам не нравится имя, вы можете называть его Undefined Value Patternодинаковой семантикой, другой меткой. Иногда этот шаблон называется Poison Pill Pattern.

Во всех этих случаях Объект является заменой или заменой Default Valueвместо null. It doesn't replace the semantic ofнулевого значения but makes it easier to work with the data model in a more predictable way becausenull`, теперь никогда не должно быть допустимым состоянием.

Это шаблон, в котором вы резервируете специальный экземпляр данного класса для представления другой nullопции как Default Value. Таким образом, вам не нужно проверять null, вы можете проверить идентичность по вашему известному NullObjectэкземпляру. Вы можете безопасно вызывать методы и тому подобное, не беспокоясь о них NullPointerExceptions.

Таким образом, вы заменяете свои nullзадания их представительными NullObjectэкземплярами, и все готово.

Правильный объектно-ориентированный анализ

Таким образом, вы можете иметь общее Interfaceдля полиморфизма и при этом иметь защиту от необходимости беспокоиться об отсутствии данных в конкретных реализациях интерфейса. Таким образом, некоторые Barмогут не иметь веб-присутствия, а некоторые могут не иметь данных о местоположении во время создания. Null Object Patterпозволяет установить значение по умолчанию для каждого из них , что является markerдля этих данных, говорит , что то же самое, ничего не было поставлено здесь, не имея дело с проверкой на NullPointerExceptionповсюду.

Правильный объектно-ориентированный дизайн

Во- первых есть abstractреализация , которая является супер набором всех атрибутов, как Barи Clubдоли.

class abstract Establishment 
{
     private final String name;
     private final Distance distance;
     private final Url url;

     public Bar(final String name, final Distance distance, final Url url)
     {
          this.name = name;
          this.distance = distance;
          this.url = url;
     }

     public Bar(final String name, final Distance distance)
     {
          this(name, distance, Url.UNKOWN_VALUE);
     }

     public Bar(final String name, final Url url)
     {
          this(name, Distance.UNKNOWN_VALUE, url);
     }

     // other code
}

Тогда можно реализовать вложенные классы этого Establishmentкласса и добавить только определенные вещи , которые нужны для каждого из Barи Clubклассов , которые не применяются к другим.

Упорство

Эти объекты-заполнители, если они построены правильно, могут прозрачно храниться в базе данных без какой-либо специальной обработки.

На будущее

Если вы решили перейти к победе в Inversion of Control / Dependency Injection позже, этот шаблон также позволяет легко вводить эти маркерные объекты.

Я думаю, проблема в том, что вы не моделируете Бар в любом из этих сценариев (и вы моделируете две разные проблемы, объекты и т. Д.). Если я увижу бар класса, я бы ожидал, что некоторые функции, связанные с напитками, меню, доступными местами, и ваш объект не имеют ничего подобного. Если я вижу поведение ваших объектов, вы моделируете информацию об учреждении. Бар - это то, для чего вы используете их в данный момент, но это не внутреннее поведение, которое они реализуют. (В другом контексте: если вы моделируете Брак, у вас будет две переменные экземпляра «Личность»; «Личность»; «Жена» - это текущая роль, которую вы отводите этому объекту в данный момент, но объект по-прежнему «Личность»). Я бы сделал что-то вроде этого:

class EstablishmentInformation {
     private final String name;

     public EstablishmentInformation(String name){
          this.name = name;
     }

     // getters
}

class EstablishmentLocationInformation {
    EstablishmentInformation establishmentInformation;
     private final Distance distance;

     public EstablishmentLocationInformation (String name, Distance distance){
          this.establishmentInformation = new EstablishmentInformation(name)
          this.distance = distance;
     }
}

class EstablishmentWebSiteInformation {
    EstablishmentInformation establishmentInformation;
     private final Url url;

     public EstablishmentWebSiteInformation(String name, Url url){
          this.establishmentInformation = new EstablishmentInformation(name)
          this.url = url;
     }
}

Там действительно нет необходимости слишком усложнять это. Вам нужны два разных типа объектов? Сделай два занятия.

class OnlineBar {
     private final String name;
     private final Url url;
     public OnlineBar(String name, Url url){
          this.name = name;
          this.url = url;
     }

     // ...
}
class PhysicalBar {
     private final String name;
     private final Distance distance;
     public PhysicalBar(String name, Distance distance){
          this.name = name;
          this.distance = distance;
     }
     //...
}

Если вам нужно работать с ними одинаково, рассмотрите возможность добавления интерфейса или использования отражения.

Мой ответ всем, кто сталкивается с такой проблемой, - разбить ее на управляемые шаги .

1. Сначала просто создайте два класса BarOneи BarTwo(или назовите их оба, Barно в разных пакетах)
2. Начните использовать ваши объекты как отдельные классы, пока не беспокойтесь о дублировании кода. Вы заметите, когда вы переходите (повторяющиеся методы) от одного к другому
3. Вы можете обнаружить, что они никоим образом не связаны, и поэтому вы должны спросить себя , действительноbar ли они оба, если не переименовать класс-нарушитель в то, что он теперь представляет
4. Если вы нашли общие поля или поведение, вы можете извлечь interfaceили superclassс общим поведением
5. Если у вас есть interfaceили superclassвы можете создать builderили factoryсоздать / получить ваши объекты реализации

(4 и 5 - то, о чем другие ответы на этот вопрос)

Вам нужен базовый класс, например, Location, который имеет имя и адрес . Теперь у вас есть два класса Bar и BarPreview, расширяющие базовый класс Location . В каждом классе вы инициализируете общие переменные суперкласса, а затем свои уникальные переменные:

public class Location {
    protected final String name;
    protected final String address:

    public Location (String locName, String locAddress) {
    name = locName;
    address = locAddress
    }

}

public class Bar extends Location {
    private final int dist;
    private final String slogan;

    public Bar(String barName, String barAddress,
               int distance, String barSlogan) {
    super(locName, locAddress);
    dist = distance;
    slogan = barSlogan;
    }
}

И похоже на класс BarPreview ..

Если это заставляет вас спать лучше ночью, замените все экземпляры Location в моем коде на AnythingYouThinkWouldBeAnAppresponNameForAThingThatABarExtendsSuchAsFoodServicePlace - ffs.