Должны ли кортежи наследовать друг друга? - PullRequest
1 голос
/ 12 февраля 2009

Учитывая набор классов кортежей на языке ООП: Pair, Triple и Quad, должен ли Triple подклассы Pair и Quad подкласс Triple?? 1001 *

Вопрос, на мой взгляд, заключается в том, следует ли заменять тройку в качестве пары, а также четверку на тройку или пару. Является ли Triple также парой, а Quad также тройкой и парой.

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

С другой стороны, должны ли они быть разными типами? Я вижу выгоду в более строгой проверке типов - когда вы не можете передать Triple в метод, который ожидает пару.

Я склоняюсь к использованию наследования, но был бы очень признателен за мнение других?

PS: В случае, если это имеет значение, классы (конечно) будут общими.

PPS: На более субъективной стороне имена должны быть Tuple2, Tuple3 и Tuple4?


Редактировать: Я думаю об этом скорее как о слабо связанных группах; не специально для таких вещей, как координаты x / y x / y / z, хотя они могут использоваться для таких целей. Это может быть как общее решение для нескольких возвращаемых значений из метода, но в форме с очень простой семантикой.

Тем не менее, мне интересны все способы, которыми другие фактически использовали кортежи.

Ответы [ 6 ]

1 голос
/ 12 февраля 2009

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

Если вы ищете традиционный дизайн Tuple, Tuple2, Tuple3 и т. Д. Проблема с наследованием заключается в том, что прежде всего Triplet не является типом Pair. Как бы вы реализовали для него метод equals? Триплет равен паре с первыми двумя предметами? Если у вас есть коллекция пар, можете ли вы добавить в нее триплет или наоборот? Если в вашем домене это нормально, вы можете перейти с наследованием.

В любом случае стоит иметь интерфейс / абстрактный класс (может быть, Tuple), который все они реализуют.

1 голос
/ 12 февраля 2009

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

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

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

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

Редактировать: Если вам нужна общая информация, попробуйте немного изучить Haskell или семейство ML (OCaml / F #), чтобы увидеть, как они используются, а затем сформировать свои собственные решения.

1 голос
/ 12 февраля 2009

это зависит от семантики, которая вам нужна -

  • пара противоположностей не семантически совместима с 3-мя кортежами подобных объектов
  • пара координат в полярном пространстве не семантически совместима с 3-мя кортежами в евклидовом пространстве

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

1 голос
/ 12 февраля 2009

Мне кажется, что вы должны создать общий интерфейс Tuple (или использовать что-то вроде упомянутой выше коллекции), и ваши классы pair и 3-tuple реализуют этот интерфейс. Таким образом, вы можете воспользоваться преимуществами полиморфизма, но также позволить паре использовать более простую реализацию, чем кортеж произвольного размера. Возможно, вы захотите, чтобы ваш интерфейс Tuple включал аксессоры .x и .y как сокращение для первых двух элементов, и более крупные кортежи могут реализовывать свои собственные сокращения в зависимости от элементов с более высокими индексами.

0 голосов
/ 12 февраля 2009

Гилад Брача написал в блоге о кортежах , которые я нашел интересным чтением.

Он высказал одно замечание (правильно я или нет пока не могу судить):

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

{S. Т.У.В} <= {С. T. U} <= {S. T} <= {S} </p>

[и] кортежи только для чтения являются ковариантными:

T1 <= T2, S1 <= S2 ==> {S1. T1} <= {S2. Т2} </p>

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

0 голосов
/ 12 февраля 2009

Я бы пошел с 0,1,2 или бесконечности. например null, 1 объект, ваш класс Pair или еще какая-то коллекция.

Ваша пара может даже реализовать интерфейс Collection.

Если существует определенная связь между тремя или четырьмя предметами, вероятно, ее следует назвать.

[Возможно, я упускаю проблему, но я просто не могу вспомнить случай, когда я хочу специально связать 3 вещи общим способом]

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...