Имеет ли смысл иметь два класса, связанных соотношением 1: 1?

Question

Я в настоящее время изучаю компьютерную инженерию и помню, как преподаватель класса под названием «Введение в информационные системы» говорил, что два класса, связанных с кардинальностью 1: 1, не имеют смысла.

Например: у меня есть класс Client и класс Telephone. Предположим, что у клиента может быть только один телефон. Профессор сказал, что не имеет смысла создавать Telephone class, и телефон должен быть атрибутом класса Client. Я абсолютно согласен с ним.

Но сейчас я беру урок по программной инженерии, и профессор (не тот же самый) не комментирует эту проблему, и теперь я действительно смущен этим.

Каков правильный подход?

Answer 1

Я бы сказал, что ваш профессор по введению в информационные системы был прав. И ваш профессор SE тоже (если его отсутствие комментариев делает его противником). Каждый из них прав в зависимости от ваших требований и домена, с которым вы работаете. Но без каких-либо других деталей это трудно смоделировать для вас, и я бы склонялся к тому, что сказал ваш профессор СЕ. Помните все эти забавные маленькие принципы, которые вы изучили: ПОЦЕЛУЙ, СУХОЙ и т. Д., И примените их к своей проблеме.

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

Если кто-то в будущем решит, что Client s может использовать более одного телефонного номера, или в вашем домене введена другая сущность, для которой нужен телефонный номер, это довольно просто выполнить рефакторинг.

Итак, с учетом этого предположим, что у вашего Client был отдельный класс Address, который вместо этого включал телефонный номер. Может быть, этот класс Address повторно используется другим классом, может быть Invoice или Shipment, где Address может использоваться совместно или применяться в обоих случаях. В этом примере вы можете захотеть, чтобы Address (Telephone) был его собственным классом.

В вашем примере Telephone может быть немного надуманным. Вы бы хотели, чтобы это был отдельный класс для повторного использования, если бы он имел много свойств (AreaCode, InternationalPrefix, Number и т. Д.), Но если бы Client просто требовалось строковое значение с именем Telephone что пользователь будет вводить просто для справки, тогда, вероятно, не имеет смысла быть его собственным классом.

Answer 2

Если вы хотите повторно использовать класс Telephone, не очень полезно иметь его как часть класса Client.Это была бы одна действительно веская причина.Если вы оставите его в классе Client, это означает, что он неотъемлемо является частью Client, даже если вы используете его в другом месте, что я сомневаюсь, что вы когда-либо имели в виду.моделировать 2 сущности с отношением 1: 1 как отдельные классы.Возможно, у вас есть Client, и у вас также есть ClientBilling.Вы не хотите, чтобы все ваши программисты имели доступ к ClientBilling, поэтому вы перемещаете его в свой собственный класс, которым он может управляться отдельно.

Возможно, ваша структура огромна, и все это можнообычно не нужно.Разбивая его на функциональные части, вы можете уменьшить размер данных до тех, которые необходимы для конкретной функции.

Возможно, 1: 1 не обязательно присущ данным, и разумным предположением будет то, чтотак будет не всегда.Тур Telephone пример попадает в эту категорию я думаю.

Answer 3

Я бы сказал, что отношения 1: 1 (обязательные с обеих сторон) являются подозрительными и должны быть тщательно продуманы, чтобы убедиться, что они необходимы.Обычно это компромисс между гибкостью и простотой диаграммы (гибкостью, потому что в будущем будет легче изменить диаграмму и адаптировать ее к новым требованиям, если вы будете придерживаться двух классов против простоты необходимости поддерживать один класс вместо двух)