Re[29]: Наследование квадратов и прямоугольников - Философия программирования

Здравствуйте, Serginio1, Вы писали:
S> Интерфейс это по сути и есть та самая утиная типизация.
Нет. Не надо наделять общепринятые термины вашими личными определениями.

S> Есть базовый класс с массивом точек по которому можно построить фигуру, На основании их можно построить создать простые формы. Можно для каждой фигуры выбирать близкий по виду. Как правило самый простой алгоритм это прямоугольники. Затем прямоугольники с треугольниками итд. Для обсчета нужны простые фигуры. Фигуры по своей сути не наследуются, но там возможны функции трансформации.
Ключевое выделено.

S> А тем, что для алгоритма нужно знать только базовые данные от которого зависит первичный алгоритм. Например для списания по ЛИФО нужны те же данные, что и списание по ФИФО.
Ну, то есть всё строится на вашей внутренней уверенности. Простите, для промышленной разработки этого недостаточно.

S> Ну вот пример. Для того, что бы использовать функцию хэлпер, данные должны быть сгруппированы в некую структуру имеющие в том числе и табличные части. Это ничем не отличается от Интерфейса.
Это если удаётся выделить такой интерфейс. Не во всех системах типов можно описать в терминах интерфейсов требование иметь некоторый набор атрибутов, в том числе и "табличных".
Но если удаётся — то это замечательно: вам больше не нужно выбирать, от кого отнаследовать нужный вам класс. Хелпер работает с любым, кто предоставляет ему нужные данные.

S>Для примера есть контракт который имеет 100 свойств. Мне проще создать объект у которого заполнить только 3 свойства, а остальные заполнить по умолчанию, вместо того, что бы городить интерфейс и реализовывать все 100 свойств.
Совершенно непонятно, зачем вам потребовались остальные 97 свойств в этом "контракте", если для успешной работы вполне хватает трёх. Похоже, что вы ошиблись при проектировании контракта, и теперь исправляете ошибку при помощи костылей.

S>Ничего в типобезопасности я не потеряю. Для примера в NET прекрасно пользуются трансформаторы например IEnumerator IEnumerable.GetEnumerator() который в 99 процентов случаев создает класс оболочку.
Не понял, о каком трансформаторе вы говорите? Вы, кстати, в курсе, я надеюсь, что foreach — одно из немногих мест в C# 1.0, где применяется реальная утиная типизация?

S>Тогда я должен это прописать в методе хэлпере. Чем метод хэлпера отличается от классового метода?
Тем, что его можно применить не только к потомкам конкретного класса. Это улучшает cohesion и снижает coupling.

S> Есть складские документы. У которых есть свойство склад и табличная часть товары одинаковая состав полей базоваго класса одинаков для всех. Вот и приходится для создания нового документа просто копировать документ только добавляя в него новые. Так что у всех будут поля А,Б,В. А вот другие поля могут быть различными даже при одинаковом названии.
А есть и другие документы, у которых нет свойства "склад". Тем не менее, это не мешает им иметь некоторые общие черты со складскими документами.
S>И таких копи пастов в 1С пруд пруди.
Ну и что? С каких пор 1С стал образцом для подражания?
S> Ну и многое решается на уровне виртуальных свойств.
Проблема, которую я обозначил, не решается на уровне виртуальных свойств.

S> Это не приделывание. Если ты моделируешь походку для абстрактного класса человек, то она будет так же применена для его наследников женщина и мужчина.
Если я идиот — да. А если нет — то походка будет моделироваться системой решений задач инверсной кинематики, а объект "человек" независимо от пола будет всего лишь описывать кинематическую схему. Никакого наследования женщины от человека у меня не будет, а будет конструирование через клонирование образцов, а также конструкторы "людей" по заданным параметрам — типа пол, рост, ширина бёдер и т.п.

S>Просто в реальности есть реальные иерархии, а не притянутые за уши. Вот их и нужно разделять как в твоем примере с фигурами.
В реальности почти что нет "реальных иерархий".
Вам промыли мозг, и вы пытаетесь увидеть иерархии там, где их нету, потому что думаете, что они должны быть. Теми элементами картины, которые не вписываются в иерархическую классификацию, вы стараетесь пренебрегать — иначе картина мира рассыпается.

Здравствуйте, Serginio1, Вы писали:

S> Я уже писал, что для того что бы создать новый документ, я беру близкий к нему просто копирую и добавляю новые поля. Вместо того, что бы отнаследоваться и добавить новое поле.
А лишние поля вы что, при этом не удаляете?
Кстати, вы сейчас про экземпляр документа или про класс документа?
S>Если я в базовом классе добавлю поле, то мне без наследования придется добавлять во все классы это поле. Как я это делаю в 1С 8 ке.
Зачем?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>> Интерфейс это по сути и есть та самая утиная типизация.
S>Нет. Не надо наделять общепринятые термины вашими личными определениями.
Интерфейс это контракт. Я уже давно говорю об псевдоинтерфейсах для объектов с двойной диспетчиризацией.
Дисп интерфейс например это не является Интерфейсом но уберает одну степень диспетчеризациии и вводит типизацию. Так применяя псевдоинтерфейсы к таким объектам можно использовать интеллисенс и вывод типов.
Кстати Воронков Василий в свое время делал обертку на рефлекшине для утинной типизации класса на C#.
Интерфейс это контракт на уровне VMT, утинная типизация это тоже контракт но на уровне названий полей и методов. Зная контракт можно легко из утинной типизации сделать интерфейс и обратно.

S>> Есть базовый класс с массивом точек по которому можно построить фигуру, На основании их можно построить создать простые формы. Можно для каждой фигуры выбирать близкий по виду. Как правило самый простой алгоритм это прямоугольники. Затем прямоугольники с треугольниками итд. Для обсчета нужны простые фигуры. Фигуры по своей сути не наследуются, но там возможны функции трансформации.
S>Ключевое выделено.
Но это не значит, что треугольник, чем то отличается от базового класса имеющего массив точек для соединения. Это нужно для резки. А для раскроя проще пользоваться более простыми фигурами.
Взе зависит от задачи.

S>> А тем, что для алгоритма нужно знать только базовые данные от которого зависит первичный алгоритм. Например для списания по ЛИФО нужны те же данные, что и списание по ФИФО.
S>Ну, то есть всё строится на вашей внутренней уверенности. Простите, для промышленной разработки этого недостаточно.
Ну 1С то так и делает. Для примера все документы наследуются от базового класса. Все объекты имеют базовый набор полей итд, и методы . Все регистры тоже самое.
Да там иерархия на одно поколение но все же.

S>> Ну вот пример. Для того, что бы использовать функцию хэлпер, данные должны быть сгруппированы в некую структуру имеющие в том числе и табличные части. Это ничем не отличается от Интерфейса.
S>Это если удаётся выделить такой интерфейс. Не во всех системах типов можно описать в терминах интерфейсов требование иметь некоторый набор атрибутов, в том числе и "табличных".
S>Но если удаётся — то это замечательно: вам больше не нужно выбирать, от кого отнаследовать нужный вам класс. Хелпер работает с любым, кто предоставляет ему нужные данные.
Ну вот наконец то. С чем я с тобой полностью согласен. Но там где можно выявить родителя то почему такой подход должен быть ущербен?

S>>Для примера есть контракт который имеет 100 свойств. Мне проще создать объект у которого заполнить только 3 свойства, а остальные заполнить по умолчанию, вместо того, что бы городить интерфейс и реализовывать все 100 свойств.
S>Совершенно непонятно, зачем вам потребовались остальные 97 свойств в этом "контракте", если для успешной работы вполне хватает трёх. Похоже, что вы ошиблись при проектировании контракта, и теперь исправляете ошибку при помощи костылей.
В зависимости от кучи показателей требуется тот или иной алгоритм. И писать его лучше в одном месте.

S>>Ничего в типобезопасности я не потеряю. Для примера в NET прекрасно пользуются трансформаторы например IEnumerator IEnumerable.GetEnumerator() который в 99 процентов случаев создает класс оболочку.
S>Не понял, о каком трансформаторе вы говорите? Вы, кстати, в курсе, я надеюсь, что foreach — одно из немногих мест в C# 1.0, где применяется реальная утиная типизация?
Я говорю об преобразовании из одного типа объекта в другой. Например окружность в квадрать. Int в Double.

S>>Тогда я должен это прописать в методе хэлпере. Чем метод хэлпера отличается от классового метода?
S>Тем, что его можно применить не только к потомкам конкретного класса. Это улучшает cohesion и снижает coupling.
А кто мешает применить этот интерфейс и к классу? Заметь что в обычном классе обычно дублируются обычные методы и интерфейсные.
Только в классах потомках не нужно заново переопределять методы.

S>> Есть складские документы. У которых есть свойство склад и табличная часть товары одинаковая состав полей базоваго класса одинаков для всех. Вот и приходится для создания нового документа просто копировать документ только добавляя в него новые. Так что у всех будут поля А,Б,В. А вот другие поля могут быть различными даже при одинаковом названии.
S>А есть и другие документы, у которых нет свойства "склад". Тем не менее, это не мешает им иметь некоторые общие черты со складскими документами.
S>>И таких копи пастов в 1С пруд пруди.
S>Ну и что? С каких пор 1С стал образцом для подражания?
Ну вот ты то агитируешь за такой подход.

S>> Ну и многое решается на уровне виртуальных свойств.
S>Проблема, которую я обозначил, не решается на уровне виртуальных свойств.

Ты исходишь из того, что нет реального наследования. Я исхожу из того, что такая иерархия существует.

S>> Это не приделывание. Если ты моделируешь походку для абстрактного класса человек, то она будет так же применена для его наследников женщина и мужчина.
S>Если я идиот — да. А если нет — то походка будет моделироваться системой решений задач инверсной кинематики, а объект "человек" независимо от пола будет всего лишь описывать кинематическую схему. Никакого наследования женщины от человека у меня не будет, а будет конструирование через клонирование образцов, а также конструкторы "людей" по заданным параметрам — типа пол, рост, ширина бёдер и т.п.
Правильно. Но вот моделировать роды ты можешь только для женщины. Или ты будешь раздувать один объект всеми возможными вариантами с кучами ветвлений. Даже в тех же автоматах проще выделить отдельный класс со своим поведением, нежели городить кучу ветвлений. Специализация есть основное условие прогресса.

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

S>Вам промыли мозг, и вы пытаетесь увидеть иерархии там, где их нету, потому что думаете, что они должны быть. Теми элементами картины, которые не вписываются в иерархическую классификацию, вы стараетесь пренебрегать — иначе картина мира рассыпается.
Да не промыли мне мозги. Просто как раз я вынужден обходиться без ООП и мне его сильно не хватает.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Я уже писал, что для того что бы создать новый документ, я беру близкий к нему просто копирую и добавляю новые поля. Вместо того, что бы отнаследоваться и добавить новое поле.
S>А лишние поля вы что, при этом не удаляете?
А их нет. Либо имеют длину 0. Например в 1С существуют свойства код и наименование,Владелец но они могут быть не во всех справочниках. При этом при вызове будет вызвано исключение.
Как я говорил раньше это решается через вирткальные свойства.

S>Кстати, вы сейчас про экземпляр документа или про класс документа?
S>>Если я в базовом классе добавлю поле, то мне без наследования придется добавлять во все классы это поле. Как я это делаю в 1С 8 ке.
S>Зачем?
А куда мне деваться если понадобились новые алгоритмы записи в новые регистры, для которых нужны дополнительные свойства. Все течет все изменяется.

Здравствуйте, Serginio1, Вы писали:

S> Интерфейс это контракт. Я уже давно говорю об псевдоинтерфейсах для объектов с двойной диспетчиризацией.
Простите, я невнимательно слежу за вашими выступлениями.

S>Дисп интерфейс например это не является Интерфейсом но уберает одну степень диспетчеризациии и вводит типизацию. Так применяя псевдоинтерфейсы к таким объектам можно использовать интеллисенс и вывод типов.
Непонятно.

S>Кстати Воронков Василий в свое время делал обертку на рефлекшине для утинной типизации класса на C#.
А IT довёл идею до конца и в BLT есть решение для утиной типизации на основе Reflection.Emit.
Ну и в 4.0 у нас есть dynamic, с которым как бы всё стало частью платформы.

S>Интерфейс это контракт на уровне VMT, утинная типизация это тоже контракт но на уровне названий полей и методов. Зная контракт можно легко из утинной типизации сделать интерфейс и обратно.
Не всегда. В частности, арифметика невыразима в терминах интерфейсов, как и другие требования к статическим мемеберам.

S> Но это не значит, что треугольник, чем то отличается от базового класса имеющего массив точек для соединения. Это нужно для резки. А для раскроя проще пользоваться более простыми фигурами.
И тем не менее, никакой иерархии наследования тут не нужно.

S> Ну 1С то так и делает. Для примера все документы наследуются от базового класса. Все объекты имеют базовый набор полей итд, и методы . Все регистры тоже самое.
S>Да там иерархия на одно поколение но все же.
И это вполне оправдано в тех случаях, когда реально есть поведение, которое хочется получить от всех участников иерархии.

S> Ну вот наконец то. С чем я с тобой полностью согласен. Но там где можно выявить родителя то почему такой подход должен быть ущербен?
Потому, что то, что родителя можно выделить сейчас, не означает, что его можно будет столь же легко выделить завтра. А мы хотим построить модель, устойчивую к изменениям. В класс нужно вносить только те методы, которые нельзя оставить снаружи — эта эвристика гарантирует вам минимум зависимостей.

S>>Совершенно непонятно, зачем вам потребовались остальные 97 свойств в этом "контракте", если для успешной работы вполне хватает трёх. Похоже, что вы ошиблись при проектировании контракта, и теперь исправляете ошибку при помощи костылей.
S> В зависимости от кучи показателей требуется тот или иной алгоритм. И писать его лучше в одном месте.
Вы не ответили на вопрос.

S>>>Ничего в типобезопасности я не потеряю. Для примера в NET прекрасно пользуются трансформаторы например IEnumerator IEnumerable.GetEnumerator() который в 99 процентов случаев создает класс оболочку.
S>>Не понял, о каком трансформаторе вы говорите? Вы, кстати, в курсе, я надеюсь, что foreach — одно из немногих мест в C# 1.0, где применяется реальная утиная типизация?
S> Я говорю об преобразовании из одного типа объекта в другой. Например окружность в квадрать. Int в Double.
И какое отношение к преобразованию int в double имеет IEnumerator IEnumerable.GetEnumerator()?

S> А кто мешает применить этот интерфейс и к классу? Заметь что в обычном классе обычно дублируются обычные методы и интерфейсные.
Какой "этот интерфейс"?

S>>Ну и что? С каких пор 1С стал образцом для подражания?
S> Ну вот ты то агитируешь за такой подход.
За какой подход?

S> Ты исходишь из того, что нет реального наследования. Я исхожу из того, что такая иерархия существует.
Зачем исходить из заведомо неверных предположений?

S> Правильно. Но вот моделировать роды ты можешь только для женщины.
И по-прежнему не будет никакой иерархии наследования.

S> Ну ты даешь. Вся природа это куча потомков с одинаковыми наборами но разными по строению размерами.
Если вы дадите себе труд поискать примеры жизненных задач программирования, то внезапно окажется, что имеющиеся в "природе" иерахии моделируются через иерахии классов ООП плохо, а то и вовсе никак.

S> Да не промыли мне мозги. Просто как раз я вынужден обходиться без ООП и мне его сильно не хватает.
Промыли-промыли. Вам кажется, что вам не хватает ООП, а на самом деле вам не хватает в основном антипаттернов.
Настоящее ООП — оно вовсе не такое, как описано в учебниках из 90х.

Здравствуйте, Serginio1, Вы писали:
S> А их нет. Либо имеют длину 0. Например в 1С существуют свойства код и наименование,Владелец но они могут быть не во всех справочниках. При этом при вызове будет вызвано исключение.
S>Как я говорил раньше это решается через вирткальные свойства.
Как по мне, так это отвратительное решение. То есть вы даёте документу свойства, которых у него заведомо нет, и обруливаете это при помощи выброса исключения в рантайме. Зачем? Только ради того, чтобы уложить классы в прокрустово ложе иерархии наследования?

S>>>Если я в базовом классе добавлю поле, то мне без наследования придется добавлять во все классы это поле. Как я это делаю в 1С 8 ке.
S>>Зачем?
S> А куда мне деваться если понадобились новые алгоритмы записи в новые регистры, для которых нужны дополнительные свойства. Все течет все изменяется.
И как вы примените эти новые алгоритмы записи к существующим документам, в которых не было этих дополнительных свойств?

Здравствуйте, alex_public, Вы писали:

I>>С этого все и начиналось — "В качестве оптимизаций".

_>Да, да, оптимизации расхода памяти — это конечно ключевой момент в дискуссии о преимуществах использования наследования при проектирование архитектуры.

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

Здравствуйте, Sinclair, Вы писали:

S>>Кстати Воронков Василий в свое время делал обертку на рефлекшине для утинной типизации класса на C#.
S>А IT довёл идею до конца и в BLT есть решение для утиной типизации на основе Reflection.Emit.
S>Ну и в 4.0 у нас есть dynamic, с которым как бы всё стало частью платформы.
Угу при этом никакого интелиссенса и проверки типов.
Кстати у Василия тоже на эмите http://www.rsdn.ru/forum/src/3165397

S>> Но это не значит, что треугольник, чем то отличается от базового класса имеющего массив точек для соединения. Это нужно для резки. А для раскроя проще пользоваться более простыми фигурами.
S>И тем не менее, никакой иерархии наследования тут не нужно.

Почему? Треугольник как раз и является наследником фигуры с массивом точек. Разве не так?
S>> Ну 1С то так и делает. Для примера все документы наследуются от базового класса. Все объекты имеют базовый набор полей итд, и методы . Все регистры тоже самое.
S>>Да там иерархия на одно поколение но все же.
S>И это вполне оправдано в тех случаях, когда реально есть поведение, которое хочется получить от всех участников иерархии.

S>> Ну вот наконец то. С чем я с тобой полностью согласен. Но там где можно выявить родителя то почему такой подход должен быть ущербен?
S>Потому, что то, что родителя можно выделить сейчас, не означает, что его можно будет столь же легко выделить завтра. А мы хотим построить модель, устойчивую к изменениям. В класс нужно вносить только те методы, которые нельзя оставить снаружи — эта эвристика гарантирует вам минимум зависимостей.

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

S>>>>Ничего в типобезопасности я не потеряю. Для примера в NET прекрасно пользуются трансформаторы например IEnumerator IEnumerable.GetEnumerator() который в 99 процентов случаев создает класс оболочку.
S>>>Не понял, о каком трансформаторе вы говорите? Вы, кстати, в курсе, я надеюсь, что foreach — одно из немногих мест в C# 1.0, где применяется реальная утиная типизация?
S>> Я говорю об преобразовании из одного типа объекта в другой. Например окружность в квадрать. Int в Double.
S>И какое отношение к преобразованию int в double имеет IEnumerator IEnumerable.GetEnumerator()?
А тем что всето приведения к интерфейсу, можно этот интерфейс запросить через GetIntefaсe<T>()

S>> А кто мешает применить этот интерфейс и к классу? Заметь что в обычном классе обычно дублируются обычные методы и интерфейсные.
S>Какой "этот интерфейс"?
Универсальный Интерфейс который должны поддерживать все классы вне иерархии.

S>>>Ну и что? С каких пор 1С стал образцом для подражания?
S>> Ну вот ты то агитируешь за такой подход.
S>За какой подход?
За подход без наследования.

S>> Ты исходишь из того, что нет реального наследования. Я исхожу из того, что такая иерархия существует.
S>Зачем исходить из заведомо неверных предположений?
Но она существует. Если у тебя нет то я только сочувствую тебе.

S>> Правильно. Но вот моделировать роды ты можешь только для женщины.
S>И по-прежнему не будет никакой иерархии наследования.
Ну ты чего то автоматы пропустил. Я за автоматы на основе иерархии, ты за автоматы на уровне ветвлений.

S>> Да не промыли мне мозги. Просто как раз я вынужден обходиться без ООП и мне его сильно не хватает.
S>Промыли-промыли. Вам кажется, что вам не хватает ООП, а на самом деле вам не хватает в основном антипаттернов.
S>Настоящее ООП — оно вовсе не такое, как описано в учебниках из 90х.
Да при чем тут учебники. Поверь я прекрасно вижу где ООП пригодно, а где оно не нужно, и где натянуто и буду брать более оптимальный вариант.
Ну и в конце то концов Интерфейс это тоже ООП выросшее из полиморфизма. А без контрактов и не туда и не сюда.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>> А их нет. Либо имеют длину 0. Например в 1С существуют свойства код и наименование,Владелец но они могут быть не во всех справочниках. При этом при вызове будет вызвано исключение.
S>>Как я говорил раньше это решается через вирткальные свойства.
S>Как по мне, так это отвратительное решение. То есть вы даёте документу свойства, которых у него заведомо нет, и обруливаете это при помощи выброса исключения в рантайме. Зачем? Только ради того, чтобы уложить классы в прокрустово ложе иерархии наследования?
Это не прокрустово ложе, а вырождение. В той же природе у наследников могут вырождаться хвост, волосянной покров итд.

S>>>>Если я в базовом классе добавлю поле, то мне без наследования придется добавлять во все классы это поле. Как я это делаю в 1С 8 ке.
S>>>Зачем?
S>> А куда мне деваться если понадобились новые алгоритмы записи в новые регистры, для которых нужны дополнительные свойства. Все течет все изменяется.
S>И как вы примените эти новые алгоритмы записи к существующим документам, в которых не было этих дополнительных свойств?
Приходится либо полностью перепроводить по одному измененному регистру (в 8 ке это можно), либо оставлять по умолчанию. Либо начинать записывать с даты внесения этих реквизитов.
Вариантов куча.

Здравствуйте, Ikemefula, Вы писали:

I>

Нет и это очевидно любому кто учил геометрию. Эту разницу можно использовать для оптимизации.
I>Собтсвенно после такого ляпа можно и разговор заканчивать, но я нынче добр

Поздравляю вас с успешным завалом выпускного экзамена по геометрии за 9й класс.
Вот вам картинка про биссектрисы углов в прямоугольнике — медитируйте до просветления:

Здравствуйте, Sinclair, Вы писали:

I>>

Нет и это очевидно любому кто учил геометрию. Эту разницу можно использовать для оптимизации.
I>>Собтсвенно после такого ляпа можно и разговор заканчивать, но я нынче добр

S>Поздравляю вас с успешным завалом выпускного экзамена по геометрии за 9й класс.
S>Вот вам картинка про биссектрисы углов в прямоугольнике — медитируйте до просветления:
S>

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

Здравствуйте, Serginio1, Вы писали:

S> Почему? Треугольник как раз и является наследником фигуры с массивом точек. Разве не так?
Ещё раз намекну: это зависит от того, какой контракт вы хотите получить от фигуры и от треугольника.
Если в контракт фигуры входит (естественная для мутабельных объектов) операция "void insertPoint(Point newPoint, int position)", то треугольник отнаследовать от этой фигуры никак не получится.
Если фигура — immutable, то в её контракт такая операция входить не может.
Зато может входить операция типа int getArea(). Но её не имеет смысла делать полиморфной, поэтому наследование треугольника вовсе не нужно. Достаточно иметь метод типа

Shape CreateTriangle(Point a, Point b, Point c)

;
Наследование нужно там, где нужен полиморфизм и возможность подстановки. В геометрии таких задач нет.

S>>Вы не ответили на вопрос.
S> Не хватает трех, а эти три отличаются от дефолтных.
Вы по-прежнему не ответили на вопрос.

S>>И какое отношение к преобразованию int в double имеет IEnumerator IEnumerable.GetEnumerator()?
S> А тем что всето приведения к интерфейсу, можно этот интерфейс запросить через GetIntefaсe<T>()
Ну это совсем другое. Посмотрите внутрь GetEnumerator для интереса.

S>>Какой "этот интерфейс"?
S> Универсальный Интерфейс который должны поддерживать все классы вне иерархии.
Нет такого "универсального интерфейса".

S> За подход без наследования.
Нет, я за подход без лишнего наследования.

S> Но она существует. Если у тебя нет то я только сочувствую тебе.
Жду убедительного примера.

S> Ну ты чего то автоматы пропустил. Я за автоматы на основе иерархии, ты за автоматы на уровне ветвлений.
Я не понимаю, о каких автоматах вы говорите, и не понимаю, зачем вы приписываете мне мнения, которых я не разделяю.

S> Да при чем тут учебники. Поверь я прекрасно вижу где ООП пригодно, а где оно не нужно, и где натянуто и буду брать более оптимальный вариант.
Либо вы плохо объясняете свою точку зрения, либо вы всё же заблуждаетесь. Потому что по вашим суждениям я пока не вижу, что вы правильно понимаете суть и область применения ООП.

Здравствуйте, Serginio1, Вы писали:
S> Это не прокрустово ложе, а вырождение. В той же природе у наследников могут вырождаться хвост, волосянной покров итд.
Природа тут ни при чём, прекратите писать чушь.
Какой смысл в этом вырождении? Зачем вы хотите иметь в сигнатуре класса атрибут, которого на самом деле нету?
Чтобы отложить обнаружение ошибки до рантайма и увеличить расходы на отладку?
Вся идея статической типизации — отлавливать такие ошибки на этапе компиляции.

S> Приходится либо полностью перепроводить по одному измененному регистру (в 8 ке это можно), либо оставлять по умолчанию. Либо начинать записывать с даты внесения этих реквизитов.
S>Вариантов куча.
И во всех этих вариантах внешний хелпер получается уместнее.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Почему? Треугольник как раз и является наследником фигуры с массивом точек. Разве не так?
S>Ещё раз намекну: это зависит от того, какой контракт вы хотите получить от фигуры и от треугольника.
S>Если в контракт фигуры входит (естественная для мутабельных объектов) операция "void insertPoint(Point newPoint, int position)", то треугольник отнаследовать от этой фигуры никак не получится.
S>Если фигура — immutable, то в её контракт такая операция входить не может.
S>Зато может входить операция типа int getArea(). Но её не имеет смысла делать полиморфной, поэтому наследование треугольника вовсе не нужно. Достаточно иметь метод типа
S>

S>Shape CreateTriangle(Point a, Point b, Point c)
S>

;
S>Наследование нужно там, где нужен полиморфизм и возможность подстановки. В геометрии таких задач нет.

Почему?

Вот Например
class Фигура()
Point [] массивТочек;
public Фигура(int[] массивТочек)
public void Начертить();

end;

class треугольник:Фигура
public треугольник(Point a, Point b, Point c)
{
массивТочек=new Point[]{a,b,c}

}
void ПовернутьТреугольникНа90Градусов()
end

Метод Начертить будет один для всех. А вот метод ПовернутьТреугольникНа90Градусов только для треугольника.

S>>>Вы не ответили на вопрос.
S>> Не хватает трех, а эти три отличаются от дефолтных.
S>Вы по-прежнему не ответили на вопрос.
А какой ответ ты хочешь услышать? Для функциональности хэлпера я должен придоставить интерфейс со 100 свойствами.
У меня есть 2 подхода либо реализовывать этот интерфейс внутри класса, либо создать класс поддерживающий этот интерфейс и заполнить только часть его полей (значительно меньшую) оставив остальные по умолчанию.

S>>>И какое отношение к преобразованию int в double имеет IEnumerator IEnumerable.GetEnumerator()?
S>> А тем что всето приведения к интерфейсу, можно этот интерфейс запросить через GetIntefaсe<T>()
S>Ну это совсем другое. Посмотрите внутрь GetEnumerator для интереса.
Ну и например Энумераторы на основе поля в составе класса или куча yield, где генерятся классы обертки. Все то о чем я тебе и говорю.
Кстати а с чего это ты на Вы перешел. Может и мне на Вы при общении с тобой перейти.

S>>>Какой "этот интерфейс"?
S>> Универсальный Интерфейс который должны поддерживать все классы вне иерархии.
S>Нет такого "универсального интерфейса".
Стоп ты предлагаешь контракты не на уровне наследования а на уровне контракта ввиде Интерфейса.
Тот же самый интерфейс я могу реализовать в базовом классе, а в наследниках только перекрывать некоторые методы и свойства. В чем проблема?

S>> За подход без наследования.
S>Нет, я за подход без лишнего наследования.

Я тоже. Но где я говорил, что ООП это панацея. Я говорю лишь о том, что наследование явно существует. Просто не везде она многоуровневая. В большинстве двухуровневая.

S>> Но она существует. Если у тебя нет то я только сочувствую тебе.
S>Жду убедительного примера.
Да я уже тебе кучу примеров приводил. И с документами со справочниками и с автоматами итд.

S>> Ну ты чего то автоматы пропустил. Я за автоматы на основе иерархии, ты за автоматы на уровне ветвлений.
S>Я не понимаю, о каких автоматах вы говорите, и не понимаю, зачем вы приписываете мне мнения, которых я не разделяю.
Детеринированные конечные автоматы ДКА.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>> Это не прокрустово ложе, а вырождение. В той же природе у наследников могут вырождаться хвост, волосянной покров итд.
S>Природа тут ни при чём, прекратите писать чушь.
S>Какой смысл в этом вырождении? Зачем вы хотите иметь в сигнатуре класса атрибут, которого на самом деле нету?
S>Чтобы отложить обнаружение ошибки до рантайма и увеличить расходы на отладку?
S>Вся идея статической типизации — отлавливать такие ошибки на этапе компиляции.
А вот здесь проблема должна решаться через возможность удаления из видимости этого свойства. Перегружать (overload )через new можно, а удалять нельзя?

S>> Приходится либо полностью перепроводить по одному измененному регистру (в 8 ке это можно), либо оставлять по умолчанию. Либо начинать записывать с даты внесения этих реквизитов.
S>>Вариантов куча.
S>И во всех этих вариантах внешний хелпер получается уместнее.
А куда мне в этот хэлпер новое свойство то ввести?

Здравствуйте, Sinclair, Вы писали:

S>> Да при чем тут учебники. Поверь я прекрасно вижу где ООП пригодно, а где оно не нужно, и где натянуто и буду брать более оптимальный вариант.
S>Либо вы плохо объясняете свою точку зрения, либо вы всё же заблуждаетесь. Потому что по вашим суждениям я пока не вижу, что вы правильно понимаете суть и область применения ООП.
В реальной жизни многие классы имеют множественное наследование, поэтому главное выбрать основного предка и правильно спроектировать иерархию.
Кстати не понимаю почему в Net нет такого понятия как Implements, когда за реализацию интерфейса отвечает конкретное поле. А так приходится городить интерфейсные методы и свойства на этом поле.
Или применять подход как запрос интерфейса у объекта. И вот он появился первый предок у которого есть понятие тип, вид, И метод или интерфейс с методом ДайкаМнеНужныйИнтерфейс()

Затем появляются абстрактные справочник,Документ, регистры. Регистры сведений тоже имею иерархию периодические непериодические.
А вот дальше сложнее. Нужно выделить частоиспользуемы, а значит и более затратные в алгоритмах. Например списание, перемещение, реализация имеют одинаковое свойство как списание с регистров товара.
С другой стороны Поступление оприходование и то же перемещение имеют свойство оприходования товара. Но при этом у них должны быть поля табличной части и документа одинаковыми для отражения их в регистрах учета.
И вот здесь можно выделить базового родителя у которого есть такие поля а от него уже отнаследовать документы для поступления и списания. Гермофродита типа перемещение нужно отрабатывать через интерфейс который будут поддерживать и наследники от поступления. Так при введении учета номенклатуры в разрезе ДопХарактеристик мне при всего лишь придется добавить эту ДопХарактеристику в базовый класс и изменить алгоритмы проведения.
Толи в хэлпере через интерфейс или в базовом классе на который будет и натянут интерфейс в базовом классе. Минимум движений.
А сейчас реально забываешь куда нужно добавлять, хотя если бы 1С была типизирована, то изменение интерфейса должно былобы вызвать ошибки об отсутствии их реализации. Но опять же это не панацея, но таких вещей полно.

Здравствуйте, Serginio1, Вы писали:
S>>Наследование нужно там, где нужен полиморфизм и возможность подстановки. В геометрии таких задач нет.
S> Почему?
Потому, что задача так устроена.
S>Вот Например
S>class Фигура()
S>Point [] массивТочек;
S>public Фигура(int[] массивТочек)
S>public void Начертить();
S>end;
Это понятно.

S>class треугольник:Фигура
S>public треугольник(Point a, Point b, Point c)
S>{
S> массивТочек=new Point[]{a,b,c}

S>}
S>void ПовернутьТреугольникНа90Градусов()
S>end
Это — нет.

S> Метод Начертить будет один для всех. А вот метод ПовернутьТреугольникНа90Градусов только для треугольника.
Почему нельзя повернуть на 90 градусов любую фигуру?
И ещё раз повторюсь: наследовать имеет смысл тогда, когда есть полиморфное поведение.
В вашем примере его нету — метод Начертить неполиморфен.

S> А какой ответ ты хочешь услышать? Для функциональности хэлпера я должен придоставить интерфейс со 100 свойствами.
Ответ на вот этот вопрос: зачем хэлперу все 100 свойств, если 97 из них — "дефолтные", т.е. он может прекрасно обойтись без них.

S>У меня есть 2 подхода либо реализовывать этот интерфейс внутри класса, либо создать класс поддерживающий этот интерфейс и заполнить только часть его полей (значительно меньшую) оставив остальные по умолчанию.
Подходов значительно больше, но выбрать верный основываясь на ваших отрывочных фразах невозможно.

S>>Ну это совсем другое. Посмотрите внутрь GetEnumerator для интереса.
S> Ну и например Энумераторы на основе поля в составе класса или куча yield, где генерятся классы обертки. Все то о чем я тебе и говорю.
Я не понимаю, о чём вы говорите. Впервые слышу о енумераторе на основе поля, а также о генерации классов-обёрток над кучей yield.
И тем более не понимаю, какое отношение всё это имеет к трансформаторам из int в double.

S>Кстати а с чего это ты на Вы перешел. Может и мне на Вы при общении с тобой перейти.
Мне так проще.

S> Стоп ты предлагаешь контракты не на уровне наследования а на уровне контракта ввиде Интерфейса.
Нет. Я предлагаю не заставлять класс выполнять те обязанности, которые может выполнить кто-то другой на основе его публичного интерфейса. К примеру, совершенно бессмысленно заставлять класс Фигура реализовывать метод Начертить, т.к. всё, что нужно Начертателю — это набор векторных примитивов, из которых состоит фигура.

S>Тот же самый интерфейс я могу реализовать в базовом классе, а в наследниках только перекрывать некоторые методы и свойства. В чем проблема?
В том, что вы не понимаете разницы в модальностях глаголов. "Я могу сделать" и "мне стоит сделать" семантически различны. Совершенно не обязательно делать всё, что возможно. К примеру, без потери семантики можно отказаться от всех скаляров в программе, и заменить их массивами длины 1.
Наследование — очень жёсткая зависимость. Его надо применять не там, где можно, а там, где без него нельзя.

S> Да я уже тебе кучу примеров приводил. И с документами со справочниками и с автоматами итд.
Ну разве это примеры? Вы говорите одно слово, и ожидаете, что я прочту все ваши мысли, приведу их в порядок, и разложу по полочкам.
К сожалению, мои способности в этой области ограничены соотношением неопределённости.
Если вы считаете такие обрывки мыслей примерами, то я вам уже наприводил контрпримеров, с теми же справочниками.

S>>Я не понимаю, о каких автоматах вы говорите, и не понимаю, зачем вы приписываете мне мнения, которых я не разделяю.
S> Детеринированные конечные автоматы ДКА.
И с чего вы взяли, что я за ДКА на основе ветвлений?

	От:	alex_public
	Дата:	28.03.13 18:42
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	29.03.13 04:38
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	29.03.13 04:39
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	29.03.13 07:11
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	29.03.13 07:16
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	29.03.13 07:57
Оценка: