Является ли это анти-паттерном, если свойство класса создает и возвращает новый экземпляр класса?

У меня есть класс с именем, Headingкоторый делает несколько вещей, но он также должен иметь возможность возвращать значение, противоположное текущему значению заголовка, которое, в конечном итоге, должно использоваться посредством создания нового экземпляра самого Headingкласса.

У меня может быть простое свойство, вызываемое reciprocalдля возврата противоположного заголовка текущего значения, а затем вручную создать новый экземпляр класса Heading, или я могу создать метод, подобный createReciprocalHeading()автоматическому созданию нового экземпляра класса Heading и возвращению его в пользователь.

Однако один из моих коллег порекомендовал мне просто создать свойство класса с именем, reciprocalкоторое возвращает новый экземпляр самого класса через его метод getter.

Мой вопрос: не является ли это анти-паттерном для свойства класса, которое ведет себя так?

Я нахожу это менее интуитивным, потому что:

1. На мой взгляд, свойство класса не должно возвращать новый экземпляр класса, и
2. Имя свойства, которое reciprocalне помогает разработчику полностью понять его поведение, без получения помощи от IDE или проверки подписи получателя.

Я слишком строг в отношении того, что должно делать свойство класса, или это действительно проблема? Я всегда пытался управлять состоянием класса с помощью его полей и свойств, а его поведения - с помощью его методов, и я не вижу, как это соответствует определению свойства класса.

Не секрет, что есть такие вещи, как Copy () или Clone (), но да, я думаю, вы правы, что беспокоитесь об этом.

возьмем для примера:

h2 = h1.reciprocal
h2.Name = "hello world"
h1.reciprocal.Name = ?

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

Вы также можете предположить, что:

h2.reciprocal == h1

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

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

Если многие из этих предположений верны, а немногие ошибочны, интерфейс - это хорошо.

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

Распространенное предположение о свойствах заключается в том, что вызов функции get является дешевым. Другое распространенное предположение о свойствах состоит в том, что вызов функции get дважды подряд вернет одно и то же.

Вы можете обойти это, используя последовательность, чтобы изменить ожидания. Например, для небольшой трехмерной библиотеки, где вам нужно Vector, Ray Matrixи т. Д. Вы можете сделать ее такой, чтобы получатели, такие как Vector.normalи Matrix.inverse, почти всегда были дорогими. К сожалению, даже если ваши интерфейсы постоянно используют дорогие свойства, интерфейсы в лучшем случае будут такими же интуитивно понятными, как и тот, который использует, Vector.create_normal()и Matrix.create_inverse()- тем не менее, я не знаю убедительных аргументов в пользу того, что использование свойств создает более интуитивный интерфейс даже после изменения ожиданий.

Свойства должны возвращаться очень быстро, возвращать одно и то же значение при повторных вызовах, и получение их значения не должно иметь побочных эффектов. То, что вы здесь описываете, не должно быть реализовано как свойство.

Ваша интуиция в целом верна. Заводской метод не возвращает одно и то же значение при повторных вызовах. Каждый раз он возвращает новый экземпляр. Это в значительной степени дисквалифицирует это как собственность. Это также не быстро, если последующая разработка добавляет вес созданию экземпляра, например, сетевых зависимостей.

Свойства обычно должны быть очень простыми операциями, которые получают / устанавливают часть текущего состояния класса. Фабричные операции не соответствуют этим критериям.

Я не думаю, что есть независимый от языка ответ на этот вопрос, поскольку то, что составляет «свойство», является языковым вопросом, и то, что ожидает вызывающий «свойство», также является языковым вопросом. Я думаю, что самый плодотворный способ думать об этом - думать о том, как это выглядит с точки зрения звонящего.

В C # свойства отличаются тем, что они (условно) пишутся с большой буквы (например, методы), но не содержат скобок (например, переменные общедоступного экземпляра). Если вы видите следующий код, отсутствие документации, что вы ожидаете?

var reciprocalHeading = myHeading.Reciprocal;

Как относительный новичок в C #, но тот, кто читал Руководство по использованию собственности Microsoft , я ожидаю Reciprocal, среди прочего:

1. быть логическим членом данных Headingкласса
2. быть недорогим, чтобы звонить, чтобы мне не нужно было кэшировать значение
3. отсутствие видимых побочных эффектов
4. дать тот же результат, если вызывается дважды подряд
5. (возможно) предложить ReciprocalChangedмероприятие

Из этих предположений (3) и (4), вероятно, являются правильными (предполагая, Headingчто это тип неизменяемого значения, как в ответе Юана ), (1) является дискуссионным, (2) неизвестен, но также дискуссионен, и (5) вряд ли производить семантический смысл (хотя то , что имеет заголовок , возможно , следует иметь HeadingChangedсобытие). Это наводит меня на мысль, что в C # API «получить или вычислить обратное значение» не следует реализовывать как свойство, но особенно если вычисление дешевое и Headingнеизменное, это пограничный случай.

(Тем не менее, обратите внимание, что ни одна из этих проблем не имеет никакого отношения к тому, создает ли вызов свойства новый экземпляр , даже (2). Создание объектов в CLR само по себе довольно дешево.)

В Java свойства являются соглашением именования методов. Если я увижу

Heading reciprocalHeading = myHeading.getReciprocal();

мои ожидания аналогичны приведенным выше (если они изложены менее четко): я ожидаю, что звонок будет дешевым, идемпотентным и не будет иметь побочных эффектов. Однако вне платформы JavaBeans концепция «свойства» не так уж и значима в Java, и, в частности, при рассмотрении неизменяемого свойства, не имеющего соответствующего setReciprocal(), getXXX()соглашение теперь несколько старомодно. Из Effective Java , второе издание (уже более восьми лет):

Методы, которые возвращают booleanнефункцию или атрибут объекта, для которого они вызваны, обычно именуются существительным, именной или глагольной фразой, начинающейся с глагола get…. Существует вокальный контингент, который утверждает, что только третья форма (начиная с get) является приемлемой, но для этого утверждения мало оснований. Первые две формы обычно приводят к более читаемому коду… (с. 239)

В современном, более свободном API я бы ожидал увидеть

Heading reciprocalHeading = myHeading.reciprocal();

- что еще раз говорит о том, что вызов дешев, идемпотентен и не имеет побочных эффектов, но ничего не говорит о том, выполняется ли новый расчет или создается новый объект. Это хорошо; в хорошем API, мне все равно.

В Ruby нет такой вещи как собственность. Есть «атрибуты», но если я увижу

reciprocalHeading = my_heading.reciprocal

У меня нет непосредственного способа узнать, обращаюсь ли я к переменной экземпляра с @reciprocalпомощью attr_readerили с помощью простого метода доступа, или я вызываю метод, который выполняет дорогостоящие вычисления. Тот факт, что имя метода является простым существительным, хотя, скорее, чем, скажем calcReciprocal, предполагает, опять же, что вызов, по крайней мере, дешево и, вероятно, не имеет побочных эффектов.

В Scala соглашение об именах заключается в том, что методы с побочными эффектами принимают скобки, а методы без них - нет, но

val reciprocal = heading.reciprocal

может быть любым из:

// immutable public value initialized at creation time
val reciprocal: Heading = … 

// immutable public value initialized on first use
lazy val reciprocal: Heading = … 

// public method, probably recalculating on each invocation
def reciprocal: Heading = …

// as above, with parentheses that, by convention, the caller
// should only omit if they know the method has no side effects
def reciprocal(): Heading = …

(Обратите внимание, что Scala допускает различные вещи, которые, тем не менее, не поощряются руководством по стилю . Это одно из моих главных раздражений в Scala.)

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

Короче говоря: знайте язык, который вы используете, и знайте, чего ожидают другие программисты от вашего API. Все остальное - деталь реализации.

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

Наименование должно идти рука об руку с соглашениями об именовании языка.

Например, в Java я бы, вероятно, ожидал, что он будет вызван getReciprocal();

При этом я бы рассмотрел изменчивые против неизменных объектов.

С неизменными все довольно просто, и не повредит, если вы вернете тот же объект или нет.

С изменчивыми это может стать очень страшным.

b = a.reciprocal
a += 1
b = what?

Теперь, что б имеет в виду? Взаимное от первоначального значения? Или ответная реакция измененного? Это может быть слишком коротким примером, но вы понимаете.

В этих случаях ищите лучшее наименование, которое сообщает, что происходит, например, createReciprocal()может быть лучшим выбором.

Но это действительно зависит от контекста.

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

Это зависит. Я обычно ожидаю, что свойства будут возвращать вещи, которые являются частью экземпляра, поэтому возвращение другого экземпляра того же класса будет немного необычным.

Но, например, строковый класс может иметь свойства "firstWord", "lastWord" или, если он обрабатывает Unicode, "firstLetter", "lastLetter", которые будут объектами с полными строками - просто обычно меньшими.

Поскольку другие ответы касаются части недвижимости, я просто расскажу о вашем # 2 о reciprocal:

Не используйте ничего, кроме reciprocal. Это единственный правильный термин для того, что вы описываете (и это формальный термин). Не пишите некорректное программное обеспечение , чтобы сохранить разработчик от обучения домена они работают. В навигации, термины имеют весьма специфические значения и использовать что - то , как , казалось бы , безобидные , как reverseи oppositeмогут привести к путанице в определенных контекстах.

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

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

Как правило, если установка не имеет смысла, вероятно, это не должно быть свойство. Конечно, его установка может быть запрещена, но теоретически возможно и целесообразно добавить сеттер.

Теперь, в некоторых языках, может иметь смысл иметь его как свойство, как указано в контексте этого языка, в любом случае, если это дает некоторые преимущества из-за механики этого языка. Например, если вы хотите сохранить его в базе данных, возможно, целесообразно сделать его как свойство, если это позволяет автоматизировать обработку в рамках ORM. Или, может быть, это язык, в котором нет различия между свойством и функцией-параметром без параметров (я не знаю такого языка, но я уверен, что они есть). Затем разработчик и документатор API должен различать функции и свойства.

Изменить: В частности, для C #, я бы посмотрел на существующие классы, особенно из стандартной библиотеки.

• Есть BigIntegerи Complexструктуры. Но они являются структурами и имеют только статические функции, а все свойства имеют различный тип. Так что не так много дизайна поможет вам Headingкласс.
• У Math.NET Numerics есть Vectorкласс , который имеет очень мало свойств и, кажется, довольно близок к вашему Heading. Если вы пойдете этим путем, то у вас будет функция для взаимности, а не свойство.

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

Действительно очень интересный вопрос. Я не вижу нарушения SOLID + DRY + KISS в том, что вы предлагаете, но, тем не менее, оно плохо пахнет.

Метод, который возвращает экземпляр класса, называется конструктором , верно? поэтому вы создаете новый экземпляр из неконструктивного метода. Это не конец света, но как клиент я бы этого не ожидал . Обычно это делается при определенных обстоятельствах: завод или, иногда, статический метод одного и того же класса (полезно для одиночных игр и для ... не очень объектно-ориентированных программистов?)

Плюс: что произойдет, если вы вызовете getReciprocal()возвращенный объект? Вы получаете другой экземпляр класса, который может быть точной копией первого! И если вы вызываетеgetReciprocal() на ЭТОГО? Кто-нибудь растянулся?

Опять же: что, если invoker требуется обратная величина (я имею в виду скаляр)? getReciprocal()->getValue()? Мы нарушаем Закон Деметры ради небольших выгод.