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

SV.>Здравствуйте, gandjustas, Вы писали:

G>>А причем тут список в ТЗ? Ты же говорил про объекты реального мира. Список, который указан в ТЗ, ничему в реальном пире не соотвествует.

SV.>Ну что, опять самоцитироваться? Я уже написал, какому объекту реального мира сответствует список.

Нет, ты придумал этот объект. Список не является результатом моделирования.

SV.>>>Допустим, вы-таки написали класс Device. За это время на базе прибора А был построен прибор Б. То есть, буквально — взяли прибор А и допаяли к нему дополнительный аппаратный модуль, например, динамик. От этого он не утратил ни лампочки, ни возможность управлять ими, но приобрел какое-то дополнительное свойство, в нашем случае — издавать звуки. Соответственно, от класса Device наследуется DeviceExt, с добавленным методом Beep() (который посылает в порт строку make bebeep). В результате выбрать тип устройства можно ровно один раз — инстанцируя фабрикой тот или иной класс. Ошибки выбора будут собраны все в одном месте. В дальнейшем ваш пользователь НЕ МОЖЕТ попросить прибор без гудка погудеть. Кроме того, глядя на этот код:

SV.>>>

SV.>>>DeviceExt : Device
SV.>>>{
SV.>>>    Beep { Device.Send ("make bebeep") }
SV.>>>}
SV.>>>

SV.>>>ваш пользователь понимает, что API поддерживает два типа приборов. Эта информация зашита в сам API и не требует отдельной документации.

G>>Прекрасный пример.

G>>Теперь представим что у нас появился другой прибор, который умеет гудеть и не умеет зажигать лампочки. При этом у нас фактически разные UI отвечают за лампочки и за гудки. То есть один фактически получать на вход ILightDevice, а другой ISoundDevice, но сами интерфейсы при этом не связаны между собой.

SV.>Если у нас появился другой прибор, значит поменялся окружающий мир. И наша ООП-модель ему больше не соответствует. Разумеется, не надо пытаться натягивать ее до конца, а надо взять и отрефакторить ОМ в очередной версии. Рефакторинг, конечно, сведется к тому, что ILightDevice и ISoundDevice будут разнесены и не связаны между собой.

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

Кстати выделенное — бред. Мир не меняется, меняется набор наших знаний о нем.

SV.>Но даже при этом сохранится смысл наследования реализаций (а о нем мы спорим, как о самом спорном приеме ООП, не так ли?), поскольку оба прибор по-прежнему имеют датапорт и умеют принимать в него строки (то есть, имеют объект класса Port и метод Send(string) к нему).

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

Имеет смысл наследование реализации без наследования интерфейса. В большинстве ОО-языков наследование реализации без наследования интерфейса невозможны, а вот mixins и typeclasses позволяют полностью разделить реализацию и интерфейсы.


SV.>Самое приятное, что увидев новый API, пользователь сразу поймет, что теперь одни приборы могут светить, а другие гудеть, а некоторые (может быть) и то, и другое. Без документации.
ILightDevice, ISoundDevice изначально решают проблему без наследований, необходимости рефакторингов итп.


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

SV.>Я не "привязывался" в том смысле, что код написан один раз и навека. Привязка в моем понимании значит, что при изменении прототипов ООП модель, как привязанная, должна меняться вслед за ними.

Так ты понял вообще что твоя привязка создала работу, которую можно было и не делать при другом способе проектирования?
Вот в этом и заключается вся жопа ООП, вернее ООАД.

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

SV.>Здравствуйте, gandjustas, Вы писали:

G>>Ты рассматриваешь проектирование классов не знаю какие задачи на них возлагаются. так нельзя делать, ничего хорошего их этого не выйдет.
G>>А правильные задачи класса можно получить декомпозиции общей задачи.
G>>Это и называется проектирование "сверху вниз", которое многие адепты ООП как раз и не любят, потому что в итоге оно не дает нам модели объектов реального мира.

SV.>Вот это пропустил. А зря. Как говорил наш преподаватель математики, ЧТД. Человек, которому попадет в руки ваш код, должен будет разбираться с особенностями вашей индивидуальной "декомпозиции общей задачи", вашего понимания общей задачи, и со всеми вашими тараканами. Человек, которому попадет в руки ООП-код с моделью, будет одновременно изучать и предметную область. Если он знает предметную область, то на понимание кода ему вообще не понадобятся усилия.

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


Кроме того domain-driven design получается слишком сложным. То есть не-domain-driven код проще писать, читать и понимать (это и адепты ddd признают и не рекомендуют ddd для простых проектов), чем dd код.

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

SV.>Сама "сомнительность" наследования реализации — следствие тех самых overhype и втыкания во все дыры. Сомнительным может быть конкретное применение, но не прием. Почему? Потому, что наследование реализации — объективное явление (вне нашего сознания и интерпретаций). И если оно наблюдается в моделируемом куске жизни, повторение его в модели (а любой софт это модель) делает ее полезнее.

Проблема не в наследовании реализации как таковом, а в том, что оно неразрывно и неотделимо связано с наследованием контракта.

AVK>Проблема не в наследовании реализации как таковом, а в том, что оно неразрывно и неотделимо связано с наследованием контракта.

почему это утверждение верное?

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

G>Далеко не во всех вообще возможна утиная типизация. но если взять типовой язык где она возможна (js) и сравнить с типовым языком со статической типизацией (java) то многое не получится в них выразить.

С чего ты взял, что утиная типизация противоречит статической? Утиная типизация это просто вшитый в язык для простейших случаев паттерн адаптер.
Собственно, в хорошо знакомом тебе шарпе утиная типизация кое где присутствует. Например, при создании делегата для конкретного метода.

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

AVK>>Проблема не в наследовании реализации как таковом, а в том, что оно неразрывно и неотделимо связано с наследованием контракта.

DG>почему это утверждение верное?

Не понял вопроса

AVK>>>Проблема не в наследовании реализации как таковом, а в том, что оно неразрывно и неотделимо связано с наследованием контракта.

DG>>почему это утверждение верное?

AVK>Не понял вопроса

на основе какой логической цепочки следует, что наследование реализации неотделимо связано с наследованием контракта?

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

AVK>>Не понял вопроса

DG>на основе какой логической цепочки следует, что наследование реализации неотделимо связано с наследованием контракта?

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

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

VE>>Гэбриел не в курсе про существование GPS что ли?
U>Разработчик GPS с тобой не согласен:
U>http://bourabai.kz/hatch/clocks_rus.htm
Ну так и Лисперы вот говорят, что это они всё придумали и могут переписать все программы мира за 10 минут.

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

U>>Разработчик GPS с тобой не согласен:
U>>http://bourabai.kz/hatch/clocks_rus.htm
VE>Почему ни одна ссылка на странице невалидна? Можно поподробнее про это?
Обычный фрик, не обращай внимания.

AVK>Это следует не на основе логической цепочки, а на основе того, что мы наблюдаем в большинстве мейнстримовых ООП языков.

без логической цепочки — это лишь проблемы этих мейнстрим-языков, а не проблема принципа "наследование реализации"

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

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

G>>Далеко не во всех вообще возможна утиная типизация. но если взять типовой язык где она возможна (js) и сравнить с типовым языком со статической типизацией (java) то многое не получится в них выразить.

AVK>С чего ты взял, что утиная типизация противоречит статической? Утиная типизация это просто вшитый в язык для простейших случаев паттерн адаптер.
А с чего ты это взял? Выделенное смотри.

AVK>Собственно, в хорошо знакомом тебе шарпе утиная типизация кое где присутствует. Например, при создании делегата для конкретного метода.
Она там в первую очередь присутствует в query comprehensions, в foreach и async, а еще в C# есть dynamic и библиотека Clay

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

DG>без логической цепочки — это лишь проблемы этих мейнстрим-языков, а не проблема принципа "наследование реализации"

Верно. Именно это я и пытался сказать — проблема не в принципе.

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

U>

U>Но объяснение Гофмана не может быть принято. Это противоречит поведению часов GPS. Различие в солнечном гравитационном потенциале для GPS синхронизируемых в точке, ближайшей к Солнцу и дальней от Солнца ( различие в расстоянии приблизительно в четыре раза превосходит земного диаметр) кажется, не оказывает никакого влияния на часы GPS.

U>Т.е. объяснение Гофмана противоречит наблюдаемым фактам.
Чего-то я не очень понимаю эту фразу. Спутники GPS движутся по круговым орбитам (ещё и геосинхронных при этом), так что для них достаточно константного смещения часов. Эффект от градиента солнечного гравитационного поля в случае с GPS пренебрежимо мал.

Далее, автор банально лжёт:

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

Это не так, что элементарно можно посчитать — гравитационное красное смещение от перемещения по вертикали с лихвой компенсирует возросшую линейную скорость, при всех разумных параметрах. В классическом эксперименте с часами на самолётах — часы шли _быстрее_, а не медленнее часов на Земле.

Тут опять ерунда — спутники GPS летают по круговым орбитам, их эксцентриситет — всего несколько километров (из-за того, что барицентр системы Земля-Луна находится не в центре Земли).

Второе взаимодействие гравитационного потенциала и скорости в показаниях часов происходит из-за эксцентричности орбит GPS. В перигее, более низкий гравитационный потенциал приводит к тому, что часы GPS идут медленнее, чем номинально. Также в перигее, спутники перемещаются быстрее чем в среднем и это также заставляет часы GPS работать медленнее — точно с той же суммой. Так что кажется, что энергия – вот что заставляет часы идти с другим темпом. Возрастающая гравитационная потенциальная энергия заставляет часы работать быстрее. Возрастающая кинетическая энергия (скорость) заставляет часы работать медленнее.

Далее:

Ну и в чем же проблема часов? Проблема проявляется, вопреки ожиданиям, с часами на Земле, которые как кажется, не подвержены влиянию солнечного гравитационного потенциала. Почему так? Для часов, приязанных к Земле, проблема была описана как проблема "полдень-полночь". В полдень часы ближе к Солнцу на диаметр Земли, нежели часы в полночь. Таким образом, ожидается, что в полдень часы должны идти медленнее, чем в полночь из-за солнечного гравитационного потенциала, однако это не наблюдается.

Не ожидается, что прекрасно показал Гоффман. До этого момента всё, в принципе, более-менее правильно, в лучших традициях Геббельса.

А вот теперь момент лжи!

...
Это верно, что часы, которые облетают Солнце за год по радиусу земного полдня должны иметь тот же ход, что часы, которые облетают Солнце за год по радиусу земной полночи, то есть потенциальное гравитационное различие должно компенсироваться скоростным различием. Но объяснение Гофмана не может быть принято. Это противоречит поведению часов GPS. Различие в солнечном гравитационном потенциале для GPS синхронизируемых в точке, ближайшей к Солнцу и дальней от Солнца ( различие в расстоянии приблизительно в четыре раза превосходит земного диаметр) кажется, не оказывает никакого влияния на часы GPS.

Градиент грав. поля между уровнем моря и высотой 22000 км.:
g0=(mass of earth)/(radius of Earth)^2*G = 9.79982305 m/s^2
g1=(mass of earth)/(radius of Earth + 22000km)^2*G = 0.495033116m/s^2
Т.е. g0-g1=9.30478993m/s^2

Теперь то же самое для Солнечного гравитационного поля:
g0=(1.98892*10^30kg)/(1 astronomical unit — 22000km)^2*G = 0.00593218395 m / s2
g1=(1.98892*10^30kg)/(1 astronomical unit + 22000km)^2*G = 0.00592869541 m / s2
Т.е. g1-g0=-3.48854*10^-6 Разница между эффектами в семь порядков! Неудивительно, что эффекта не наблюдается.

Но даже если предположить, что эта разница обнаружима (а она обнаружима) — то ЭТО ТОЖЕ НЕ ПРОБЛЕМА! Так как на земные часы в момент синхронизации тоже влияет гравитационное поле Солнца, так что все расхождения (почти) полностью будут компенсированы. В строгом согласии с принципами ОТО.

S_S>>Вобщем, Гофман согласен, Хатч не согласен.
U>С точки зрения науки совершенно не важно с чем согласны или нет Гофман и Хатч, важно то, что объяснение предлагаемое Гофманом противоречит фактам, а, значит, является неверным.
Каких фактов? Факт один — часы на спутниках идут быстрее. Причём в строгом соответствии с ОТО.

Кстати, насчёт Гоффмана — вот эта статья из Physical Review: http://prola.aps.org/pdf/PR/v121/i1/p337_1 ( http://prola.aps.org/abstract/PR/v121/i1/p337_1 — её abstract).

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

SV.>>Сама "сомнительность" наследования реализации — следствие тех самых overhype и втыкания во все дыры. Сомнительным может быть конкретное применение, но не прием. Почему? Потому, что наследование реализации — объективное явление (вне нашего сознания и интерпретаций). И если оно наблюдается в моделируемом куске жизни, повторение его в модели (а любой софт это модель) делает ее полезнее.

AVK>Проблема не в наследовании реализации как таковом, а в том, что оно неразрывно и неотделимо связано с наследованием контракта.

Что такое контракт? В строгом смысле мейнстримные языки Contract programming вообще не поддерживают, а в бытовом смысле надо уточнять. Что будет контрактом в шарпе?

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

SV.>>Ну что, опять самоцитироваться? Я уже написал, какому объекту реального мира сответствует список.
G>Нет, ты придумал этот объект. Список не является результатом моделирования.

Как по-вашему работали отделы статистики до изобретения компьютеров?

SV.>>Если у нас появился другой прибор, значит поменялся окружающий мир. И наша ООП-модель ему больше не соответствует. Разумеется, не надо пытаться натягивать ее до конца, а надо взять и отрефакторить ОМ в очередной версии. Рефакторинг, конечно, сведется к тому, что ILightDevice и ISoundDevice будут разнесены и не связаны между собой.

G>А зачем что-то делать, а потом рефакторить, если можно заранее избежать проблем? Ведь способ с двумя интерфейсами решает все проблемы, про которые ты тут рассказываешь, а наследование эти проблемы создает.

Затем, что мой пример — из жизни, а ваш — из области фантастики. Зная, однако, что некоторые клиенты/менеджеры рождены, чтоб сказку сделать былью, я не стал отнекиваться, а написал, что должен делать хороший ООПер в такой ОЧЕНЬ маловероятной ситуации.

Избегать заранее проблем и портить при этом хороший код не надо.

G>Кстати выделенное — бред. Мир не меняется, меняется набор наших знаний о нем.

Мы его меняем.

SV.>>Но даже при этом сохранится смысл наследования реализаций (а о нем мы спорим, как о самом спорном приеме ООП, не так ли?), поскольку оба прибор по-прежнему имеют датапорт и умеют принимать в него строки (то есть, имеют объект класса Port и метод Send(string) к нему).

G>А зачем тогда класс прибора нужен вообще? Создаются объекты, которые получают на вход Port (вернее IPort) и отправляют команды.

Затем, чтобы ваш пользователь мог включать и выключать лампочки и бикать спикером, не создавая объекта Port и не отдавая его на вход. Этим занимается фабрика, как я и написал. Возлюбите своего пользователя, дабы он не возлюбил вас через саппорт.

G>Ну и все. Связь с "реальным миром" (который фактически набор знаний) мы потеряли, от этого программа стала более устойчивой к изменениям этого "реального мира".

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

G>Модель предметной области — тоже результат некоторой индивидуальной умственной деятельности и обладает теми же свойствами.

Обладает, но в меньшей мере. Знаете, как говорят — дураки спорят о крайностях, а умные — о мере?

G>Нету однозначного рецепта получения правильной модели предметной области в вакууме. Даже эванса почитай — он пишет про множество адаптаций и рефакторингов относительно изначальной картины.

Нету. Но давайте не будем уподобляться дуракам из цитаты выше.

G>Кроме того domain-driven design получается слишком сложным. То есть не-domain-driven код проще писать, читать и понимать (это и адепты ddd признают и не рекомендуют ddd для простых проектов), чем dd код.

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

SV.>Здравствуйте, gandjustas, Вы писали:

SV.>>>Ну что, опять самоцитироваться? Я уже написал, какому объекту реального мира сответствует список.
G>>Нет, ты придумал этот объект. Список не является результатом моделирования.

SV.>Как по-вашему работали отделы статистики до изобретения компьютеров?
Это тут причем? Ты опять выдумываешь модель для того кода, который изначально не был моделью чего-то.

SV.>>>Если у нас появился другой прибор, значит поменялся окружающий мир. И наша ООП-модель ему больше не соответствует. Разумеется, не надо пытаться натягивать ее до конца, а надо взять и отрефакторить ОМ в очередной версии. Рефакторинг, конечно, сведется к тому, что ILightDevice и ISoundDevice будут разнесены и не связаны между собой.

G>>А зачем что-то делать, а потом рефакторить, если можно заранее избежать проблем? Ведь способ с двумя интерфейсами решает все проблемы, про которые ты тут рассказываешь, а наследование эти проблемы создает.

SV.>Затем, что мой пример — из жизни, а ваш — из области фантастики.

У меня в каждом проекте таких примеров немеряно.

SV.>Зная, однако, что некоторые клиенты/менеджеры рождены, чтоб сказку сделать былью, я не стал отнекиваться, а написал, что должен делать хороший ООПер в такой ОЧЕНЬ маловероятной ситуации.
Да, действительно есть тенденция говорить что неудобные ситуации маловероятны. А по факту наоборот.
Расширение спектра различных устройств случается гораздо чаще, чем апгрейд какого-то одного устройства.

SV.>>>Но даже при этом сохранится смысл наследования реализаций (а о нем мы спорим, как о самом спорном приеме ООП, не так ли?), поскольку оба прибор по-прежнему имеют датапорт и умеют принимать в него строки (то есть, имеют объект класса Port и метод Send(string) к нему).

G>>А зачем тогда класс прибора нужен вообще? Создаются объекты, которые получают на вход Port (вернее IPort) и отправляют команды.

SV.>Затем, чтобы ваш пользователь мог включать и выключать лампочки и бикать спикером, не создавая объекта Port и не отдавая его на вход. Этим занимается фабрика, как я и написал. Возлюбите своего пользователя, дабы он не возлюбил вас через саппорт.
А причем тут пользователь? Он вообще в кнопочки на экране тыкает. Ему нет разницы какого класса объекты создаются.

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

SV.>Здравствуйте, gandjustas, Вы писали:

G>>Модель предметной области — тоже результат некоторой индивидуальной умственной деятельности и обладает теми же свойствами.

SV.>Обладает, но в меньшей мере.
Докажи. Вряд ли у тебя получится, потому что эта мера и зависит от конкретного человека.

SV.>Знаете, как говорят — дураки спорят о крайностях, а умные — о мере?
Знаю, но это к теме разговора не имеет отношения.

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

SV.>Что такое контракт?

Набор формальных правил, ограничивающих внешнее взаимодействие с объектом.

SV.> В строгом смысле мейнстримные языки Contract programming вообще не поддерживают

Программирование по контракту это совсем другое.

SV.>, а в бытовом смысле надо уточнять. Что будет контрактом в шарпе?

Публичный интерфейс класса или интерфейс. В классе два контракта — публичный и для потомков.