Интерфейс не должен иметь свойств?
Вот то, что я говорил Нейту Куку, в комментариях к его качественному ответу. Это то, что я считаю «легким [добавлением] элементов в массив внутри словаря»:
dict["key"] = dict["key"]! + 4
dict["key"] = dict["key"] ? dict["key"]! + 4 : [4]
Сейчас нам нужно определить оператор + самостоятельно.
@infix func +<T>(array: T[], element: T) -> T[] {
var copy = array
copy += element
return copy
}
Я думаю, что эта версия снимает слишком много безопасности; Может быть, определить его с помощью составного оператора?
@infix func +<T>(array: T[]?, element: T) -> T[] {
return array ? array! + element : [element]
}
dict["key"] = dict["key"] + 4
Наконец, это самое чистое, что я могу получить, но я не совсем понимаю, как работают значения / ссылки на массивы в этом примере.
@assignment func +=<T>(inout array: T[]?, element: T) {
array = array + element
}
dict["key"] += 5
8 ответов
Я просто добавлю сюда свой голос - я никогда не встречал этой рекомендации. Свойство фактически представляет собой пару методов получения / установки.
Как и любое другое дизайнерское решение. Если это действительно имеет смысл; если это подходит для разрабатываемой системы, если не вызывает проблем с обслуживанием, если не вызывает проблем с производительностью, не должно быть причин, по которым вы не можете это сделать.
Я никогда не встречал никого, кто делал бы это заявление, и не вижу для этого никаких веских причин. Платформа .NET полна интерфейсов со свойствами.
Интерфейс - это контракт, который должен реализовать класс, и я не вижу причин, по которым свойства должны быть исключены из такого контракта. Кроме того, свойства являются неотъемлемой частью .NET.
В качестве примера: ICollection имеет как Count , так и IsReadOnly .
Я не могу придумать никакой документации, подтверждающей это предположение. Вдобавок я могу вспомнить множество примеров в BCL, которые делают прямо противоположное. Взгляните практически на любой из интерфейсов коллекции, и вы увидите свойства.
Никогда не видел ничего подобного как такового, но некоторое время назад были разговоры о том, что свойства не используются в определениях межплатформенного интерфейса, поскольку существует множество платформ, которые не поддерживают свойства, а просто примерно все поддерживает методы.
Существует широко известный термин «запах кода». Предлагаю ввести понятие «запах программиста» - если кто-то настаивает на каком-то правиле, но не может объяснить почему - это запах. Ваш коллега должен объяснить, почему свойства интерфейса плохие. Если не может - он, вероятно, ошибается, даже если статья, на которую он ссылается, верна.
В этой статье, возможно, говорилось о некоторых конкретных типах интерфейсов, может быть, это как-то связано с COM, совместимостью или чем-то еще. Или он может просто ошибиться. Понимание правил и умение их объяснять - важная часть использования правил.
На практике свойство представляет собой набор двух функций : один для получения значения и один для установки значения.
Я не вижу причин, чтобы не использовать свойства как часть вашего интерфейса. Как еще вы бы реализовали доступ к элементам данных? Получите методы и установите методы вместо свойств. Это было бы просто уродливо и так в 1990-е годы.