Свойства и их абстракции.

[Xaositect]

kolas в сообщении #386755 писал(а):

Но круг все контракты эллипса реализует правильно, и никаких новых контрактов не создает, так что правило подстановки работает корректно.

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

worm2 в сообщении #386100 писал(а):

Ну, и до кучи ещё ссылочку кину:
Из Marshall Cline's C++ FAQ про правильное проектирование наследования.

Там, кстати, правильная мысль высказана: наследование - это не subtyping, точнее, не любое включение типов может (и должно) реализовываться с помощью наследования.

[Joker_vD]

Xaositect в сообщении #386762 писал(а):

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

Умей мы скрывать публичные поля, это можно было бы обойти (скрыли ширину/высоты, объявили радиус), но тогда мгновенно нарушается принцип подстановки.

Xaositect в сообщении #386762 писал(а):

точнее, не любое включение типов может (и должно) реализовываться с помощью наследования.

Собственно говоря, забавная вещь наблюдается: можно (например) объявить TManager как наследник TEmployee. Значений типа TManager будет (в общем случае) больше, чем значений типа TEmployee, поэтому включение $\mathrm{TManager} \subseteq \mathrm{TEmployee}$ явно невозможно.

[Xaositect]

Joker_vD в сообщении #386766 писал(а):

Xaositect в сообщении #386762 писал(а):

точнее, не любое включение типов может (и должно) реализовываться с помощью наследования.

Собственно говоря, забавная вещь наблюдается: можно (например) объявить TManager как наследник TEmployee. Значений типа TManager будет (в общем случае) больше, чем значений типа TEmployee, поэтому включение $\mathrm{TManager} \subseteq \mathrm{TEmployee}$ явно невозможно.

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

[Munin]

kolas в сообщении #386755 писал(а):

Что значит нарушить контракт, реализовать его неправильно? Но круг все контракты эллипса реализует правильно

И этот человек ставит мне минусы :-) http://ru.wikipedia.org/wiki/Контрактное_программирование

[kolas]

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

Xaositect в сообщении #386762 писал(а):

Потому что если разрешить менять другие, то рано или поздно начнется жесть.

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

[Munin]

kolas в сообщении #386859 писал(а):

Поздравляю, мы успешно превратили тему во флейм

Она изначально была бредом.

kolas в сообщении #386859 писал(а):

ООП это инструмент, он не гарантирует правильного результата, все зависит от полноты информации, которую мы хотим формализовать с помощью ооп, и от прямизны рук.

Прежде всего от прямизны головы, но до осознания этой истины вы ещё не доросли, похоже.

kolas в сообщении #386859 писал(а):

Пожалуйста, кому не нравится ооп, предлагайте альтернативу.

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

kolas в сообщении #386859 писал(а):

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

Это нарушение принципа подстановки.

kolas в сообщении #386859 писал(а):

Правда это совсем не кошерный подход, т.к. будут сеттеры пустышки

"Сеттер-пустышка" - это тоже нарушение контракта.

kolas в сообщении #386859 писал(а):

Лучше сразу сделать правильные контракты

Во, начинается какое-то шевеление в голове. К сожалению, от этого до правильных выводов - ещё как до Луны.

kolas в сообщении #386859 писал(а):

По моему, мы начинаем топтаться на месте.

Вы это начали, ещё когда эту тему завели. Я вам с самого начала сказал: не высасывайте глупости из пальца, а осваивайте матчасть. Когда поумнеете, многие глупости сами отпадут.

[Joker_vD]

Xaositect в сообщении #386767 писал(а):

TEmployee - супертип, и его значения включают в том числе значения TManager.

А они не включают Возможных значений TManager тупо больше чем всевозможных значений собственно TEmployee.

kolas в сообщении #386859 писал(а):

Пожалуйста, кому не нравится ооп, предлагайте альтернативу.

Хаскеллевский подход с type class'ами плюс прикрутить идею из упомянутой мной статьи Дарвена. Мнэ?

[Xaositect]

Joker_vD в сообщении #387081 писал(а):

А они не включают Возможных значений TManager тупо больше чем всевозможных значений собственно TEmployee.

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

[Joker_vD]

Xaositect в сообщении #387093 писал(а):

Любое значение TManager можно рассматривать как значение TEmployee

Ну, можно и $\{\, (a, 0) \mid a \in \mathbb N \,\}$ рассматривать как $\mathbb N$, но это не значит, что эти два множества равны — они вообще не пересекаются.

[kolas]

Munin в сообщении #386966 писал(а):

Она изначально была бредом.

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

Хочу привести пример декоратора:

расширение вселенной -> красное смещение от расстояния -> доплеровский эффект
расширение вселенной <>-> вселенная

вселенная -> красное смещение от расстояния

Чтобы просто понять эту запись, нужно читать "->" как "реализует", а знак агрегирования "<>->" в данном случае как "эффект над". Приведенная выше запись полностью соответствует паттерну "декоратор" из ооп, он используется, чтобы расширить класс не вмешиваясь в его внутреннюю реализацию.

[arseniiv]

(Оффтоп)

kolas в сообщении #387272 писал(а):

расширение вселенной

kolas в сообщении #387272 писал(а):

чтобы расширить класс

Из-за неосторожности у вас получилась нежелательная игра слов.

Хотя я паттерны ещё мало знаю, но мне кажется, что вы как-то неправильно используете декоратор.

[kolas]

arseniiv в сообщении #387307 писал(а):

Хотя я паттерны ещё мало знаю, но мне кажется, что вы как-то неправильно используете декоратор.

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

[Munin]

kolas в сообщении #387272 писал(а):

Я же ясно объяснил, не нравится тема, держитесь в стороне

А я вам ясно объяснил, что на этом форуме не такие порядки.

kolas в сообщении #387272 писал(а):

Приведенная выше запись полностью соответствует паттерну "декоратор" из ооп

А также детской ошибке по физике.

kolas в сообщении #387312 писал(а):

Почему же, декоратор как раз добавляет свойства объекту не затрагивая его исходных свойств

А реально факт расширения Вселенной существенно меняет её модельные свойства. Так что вы сели в очередную лужу.

[kolas]

Munin в сообщении #387362 писал(а):

А реально факт расширения Вселенной существенно меняет её модельные свойства. Так что вы сели в очередную лужу.

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

расширение вселенной -> красное смещение от расстояния -> доплеровский эффект
расширение вселенной <>-> вселенная

вселенная -> красное смещение от расстояния

Это означает, что нет прямого наследования вселенной контракта ее расширения, а есть только наблюдаемое красное смещение от расстояния. Расширение вселенной это декоратор наблюдаемого - вселенная -> красное смещение от расстояния, формально это будет вернее чем вселенная -> расширение вселенной.

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

[Munin]

kolas в сообщении #387370 писал(а):

Вы настолько увлечены мыслями, что я здесь затеваю преступление

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

kolas в сообщении #387370 писал(а):

Это означает, что нет прямого наследования вселенной контракта ее расширения, а есть только наблюдаемое красное смещение от расстояния. Расширение вселенной это декоратор наблюдаемого - вселенная -> красное смещение от расстояния, формально это будет вернее чем вселенная -> расширение вселенной.

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