Liskov substitution principle говорит о типах, которые наследуют друг от друга. Как насчет ситуации, когда типы не связаны наследованием, но выполняют похожие функции, например массивы и списки в .NET? Для такой ситуации тоже полезно сделать интерфейс этих классов максимально близким, чтобы можно было заменить один на другой с минимумом гемора.
Для этого принципа есть какое-то формальное название?
Здравствуйте, Codealot, Вы писали:
C>Liskov substitution principle говорит о типах, которые наследуют друг от друга. Как насчет ситуации, когда типы не связаны наследованием, но выполняют похожие функции, например массивы и списки в .NET? Для такой ситуации тоже полезно сделать интерфейс этих классов максимально близким, чтобы можно было заменить один на другой с минимумом гемора.
Если мне склероз не изменяет, для этой цели придуман IEnumerable.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Codealot, Вы писали:
SVZ>>Если мне склероз не изменяет, для этой цели придуман IEnumerable.
C>Будет очень эффективно, если ты попытаешься сделать через него Reverse
Он для этого и не предназначен.
Ты же не пытаешься обращаться к элементам списка по индексу?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Codealot, Вы писали:
C>Нет. Если названия и сигнатуры методов в похожих типах не совпадают, то никакой duck typing не сработает.
Ну должен же компилятор как-то догадаться, что некие два метода по сути своей одинаковые. Duck typing предлагает конкретный, весьма простой, механизм, как ему это объяснить.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну должен же компилятор как-то догадаться, что некие два метода по сути своей одинаковые. Duck typing предлагает конкретный, весьма простой, механизм, как ему это объяснить.
Чтобы он догадался, у них должна быть сделана одинаковая сигнатура. И вот именно про это и был мой вопрос, а не про то, что происходит после.
Здравствуйте, Muxa, Вы писали:
M>Дык ты обозначь что за похожие функции, выполняемые списком и массивом ты имеешь в виду. Хранение более чем одного элемента чтоли?
Как я уже писал — Reverse, в качестве примера.
Работает одинаково для обоих коллекций. Значит, и сигнатура у методов должна быть максимально одинаковой, чтобы можно было легко заменить в коде один класс на другой. Вопрос — у этой идеи есть какое-нибудь умное название, чтобы вдолбить в голову тех, кто не понимает зачем это нужно?
C>Как я уже писал — Reverse, в качестве примера. C>Работает одинаково для обоих коллекций. Значит, и сигнатура у методов должна быть максимально одинаковой, чтобы можно было легко заменить в коде один класс на другой. Вопрос — у этой идеи есть какое-нибудь умное название, чтобы вдолбить в голову тех, кто не понимает зачем это нужно?
Здравствуйте, Codealot, Вы писали:
Pzz>>Ну должен же компилятор как-то догадаться, что некие два метода по сути своей одинаковые. Duck typing предлагает конкретный, весьма простой, механизм, как ему это объяснить.
C>Чтобы он догадался, у них должна быть сделана одинаковая сигнатура. И вот именно про это и был мой вопрос, а не про то, что происходит после.
Ну вот, сведение типов по сигнатурам методов и называется duck typing.
Здравствуйте, Codealot, Вы писали:
C>Liskov substitution principle говорит о типах, которые наследуют друг от друга. Как насчет ситуации, когда типы не связаны наследованием, но выполняют похожие функции, например массивы и списки в .NET? Для такой ситуации тоже полезно сделать интерфейс этих классов максимально близким, чтобы можно было заменить один на другой с минимумом гемора. C>Для этого принципа есть какое-то формальное название?
Здравствуйте, Codealot, Вы писали:
C>Для этого принципа есть какое-то формальное название?
interface segregation principle вполне достаточно. Вкупе с такой фичей как Intersection Types, чтоб не городить новых интерфейсов которые являются
комбинацией более мелких.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, omgOnoz, Вы писали:
O>>сабж?
C>Нет. Если названия и сигнатуры методов в похожих типах не совпадают, то никакой duck typing не сработает.
А кто тебе сказал, что они НЕ СОВПАДАЮТ?? Duck принцип про то и говорит — если ты можешь это "открыть", "записать" и "закрыть", значит это ФАЙЛ! Независимо от объекта. Значит вызовы априори идентичны.
Здравствуйте, Codealot, Вы писали:
C>Liskov substitution principle говорит о типах, которые наследуют друг от друга. Как насчет ситуации, когда типы не связаны наследованием, но выполняют похожие функции, например массивы и списки в .NET? Для такой ситуации тоже полезно сделать интерфейс этих классов максимально близким, чтобы можно было заменить один на другой с минимумом гемора. C>Для этого принципа есть какое-то формальное название?
Структурный полиморфизм или статическая утиная типизация. Примеры можно посмотреть в интерфейсах go и в питоновских протоколах. Если же вопрос касается только .net, то в C# в явном виде такого нет, но массивы и списки реализуют IList<T>.
Здравствуйте, Kolesiki, Вы писали:
K>А кто тебе сказал, что они НЕ СОВПАДАЮТ??
А вот потому что кто-то сделал так, что они не совпадают.
duck typing — это система типизации, а не принципы проектирования классов. А мой вопрос — про принципы проектирования классов.
