Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, 0x7be, Вы писали:
SV.>>>Просто потому, что мы мыслим объектами. 0>>А это точно правда?
SV.>Это называется "понятийное мышление". В норме человек к 5 годам им овладевает в степени, достаточной для повседневного применения. У кого-то оно развито сильнее, и ему можно доверить проектирование. У кого-то слабее, и он может разве что воспользоваться результатами чужого труда по декомпозиции. Но когда совсем никак — это патология. Тот же функциональный подход с такими отклонениями не осилить, потому, что он требует еще большей изощренности.
Большая изощренность в функциональном подходе нужна как раз в том, что бы после ООП перестать мыслить объектами и понятиями и начать мыслить данными и их трансформациями.
A>вот и работает ФП только для задач типа символьного дифференцирования, A>а чтобы что-то из реальной жизни описать, или быстро md5 посчитать — это нет, тут только С#/джава или C/C++
У нас вот, 100 человек функционально все описывают. Что мы делаем не так?
Здравствуйте, grosborn, Вы писали:
>> А нужно оно только для того, чтобы сделать код чуточку понятнее любому нубу на проекте (в том числе, клиентам библиотек/фреймворков/сервисов). Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.
G>С какого перепугу наследование стало ближе к предметной области, чем к примеру копипастинг? Если бы интерфейсы можно было бы произвольно комбинировать и декомбинировать, это было бы ближе, но наследование и подгонка предметной области под наследование это клиника.
Если оно там (в предметной области) присутствовало изначально, значит ближе. Если изначально присутствовал копипакостинг, значит, ближе он.
Хотя ситуация вымышлена, пример самый настоящий:
// Any protocol supports plain text.interface IMessenger
{
void SendMessage(string text);
}
// No protocols support file transport only. If there is one, the contract is not valid anymore.interface IFileSender : IMessenger
{
void SendFile(File file);
}
class SkypeMessenger : IFileSender; // It's easy to support both text and file sending via Skype.class SmsMessenger : IMessenger; // ...But not via SMS.class MyApp : Application
{
...
void SurpriseAdminInChief(IFileSender messenger)
{
messenger.SendFile(_dumpFile);
messenger.SendText(_criticalErrorMessage); // We are absolutely sure we can send text if we can send files.
}
void SurpriseApprenticeAdmin(IMessenger messenger)
{
messenger.SendText(_warningMessage);
}
...
}
Что он отражает? Он отражает наши представления о мессенджерах. Допустим, это плохие, негодные представления. Мессенджеры так себя не ведут. Ладно, но вы же ВСЁ ПОНЯЛИ, что было в голове у архитектора? В этом и суть.
Мой (воображаемый) собеседник предложил использовать вот такую штуку, исключающую необходимость в наследовании:
void SurpriseAdminInChief<T>(T messenger) where T : IFileSender, IMessenger
И предсказуемо сломался на простом вопросе: как построить плагинную архитектуру, когда одни реализуют обертки над SMS-гейтами и скайпами, другие их используют, а ты должен написать базовое приложение, которые не допустит конфликтов. Что если первый плагин вернет реализацию ТОЛЬКО IFileSender, а второму подавай оба? Ах, еще раз писать where T? Ну, это и будет поддержка ОБЪЕКТИВНОГО (не объектного) наследования, выполненная самым кривым и неочевидным способом. Да, можно, конечно, и так, но ЗАЧЕМ?
Или возьмите текстовый процессор. Вы можете вставить картинку, корзинку, картонку и векторную фигуру, и пользователь ОЖИДАЕТ увидеть в ее свойствах точное положение на странице (если это верстальщик) или, хотя бы, ОЖИДАЕТ, что и то, и другое можно подхватить мышкой и потаскать. И то, и другое в юзерском сознании — варианты абстрактного Таскабельного Объекта. И надо быть извращенцем, чтобы не абстрагировать эту категорию, не выделить ее и не обособить.
Автор простую мысль — заставь дурака богу молиться — размазывает по пяти страницам.
Лично мне Ява никогда не нравилась как раз поэтому: будучи формально весьма объектно-ориентированным языком, она утратила дух ОО напрочь. Когда нам нужен предикат или обработчик события, нормальный человек обычно пропускает их абстрагирование и переходит к сути. Нет, это, конечно же, объекты, имеющие общие свойства, мы должны иметь возможность посмотреть на них под таким углом, например, когда мы занимаемся сугубо административной деятельностью, типа раздачи указаний и их ведения в органайзере. Но такой взгляд нам нужен нечасто. Ява, которая заставляет помнить об этом ВСЕГДА, меня дико напрягает. Посмотрите на C# с его лямбдами.
Так вот, когда ООП применяют не по делу, это говорит о том, что его плохо понимают. Почему я и сказал, что нет в Яве духа ООП.
Да, самое главное. Надо помнить, что эволюция идет постепенно. Может быть, через пару лет и в Яве будет все в порядке с обработчиками и предикатами. А вот если они упрутся, и по идеологическим причинам не станут их вводить, тогда и скажем — заставь дурака...
> Хотя ситуация вымышлена, пример самый настоящий: > >
>
> > Что он отражает? Он отражает наши представления о мессенджерах. Допустим, это плохие, негодные представления. Мессенджеры так себя не ведут. Ладно, но вы же ВСЁ ПОНЯЛИ, что было в голове у архитектора? В этом и суть.
Я понял только что пример гхмс...
Интерфейс должен описывать отсылку сообщения, а сообщение может поддерживать разные форматы. Вот там наследование, но не интерфейсов. А наследование интерфейсов вроде бы тут вообще нигде не нужно и только усложняет код.
Здравствуйте, Artifact, Вы писали:
A>Наверное в своей первой же программе вы сразу стали использовать ООП, точнее одну из его реализаций, ведь то как реализовано ООП может отличаться в разных языках (Вопрос для самоконтроля: сколько разных реализаций ООП Вы можете назвать?). То есть я подозреваю, что именно от того, что Вы сразу начали использовать ООП, Вы и считаете, что это хорошо и правильно, а вовсе не потому, что ООП действительно объективно такое хорошее.
Моя первая программа решала квадратные уравнения и работала на МК-52. Сначала требовалось ввести коэффициенты при членах, потом она выводила дискриминант и корни (или гогу). По замыслу создателя, она должна была облегчать школьные будни, но пока пять километров в гору школу зимой... сами понимаете, ППЗУ не было рассчитано на сибирские морозы. Каждый раз с утра приходилось набивать листинг заново, пока не затрахало. Основана программа была на перемещениях значений из одних ячеек памяти в другие. Такой там был подход. Если только склероз меня не подводит.
То, о чем вы говорите, называется "утиный эффект", и я с ним стараюсь бороться. Как раз, ООП мне дался после продолжительного боя. Я рассказывал как-то эту историю.
Здравствуйте, SV., Вы писали:
SV.>Это называется "понятийное мышление". В норме человек к 5 годам им овладевает в степени, достаточной для повседневного применения. У кого-то оно развито сильнее, и ему можно доверить проектирование. У кого-то слабее, и он может разве что воспользоваться результатами чужого труда по декомпозиции. Но когда совсем никак — это патология. Тот же функциональный подход с такими отклонениями не осилить, потому, что он требует еще большей изощренности.
У меня складывается впечатление, что мантру о том что "ООП естественно для человека, потому что мы мыслим объектами" многие заучили ещё в университетах, не пытаясь осмыслить её критически.
Вот упомянул понятийное мышление — а ты уверен, что понятия тождественны классам ООП (и какой, кстати, разновидности его)?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, SV., Вы писали:
SV.>>Это называется "понятийное мышление". В норме человек к 5 годам им овладевает в степени, достаточной для повседневного применения. У кого-то оно развито сильнее, и ему можно доверить проектирование. У кого-то слабее, и он может разве что воспользоваться результатами чужого труда по декомпозиции. Но когда совсем никак — это патология. Тот же функциональный подход с такими отклонениями не осилить, потому, что он требует еще большей изощренности. 0>У меня складывается впечатление, что мантру о том что "ООП естественно для человека, потому что мы мыслим объектами" многие заучили ещё в университетах, не пытаясь осмыслить её критически.
0>Вот упомянул понятийное мышление — а ты уверен, что понятия тождественны классам ООП (и какой, кстати, разновидности его)?
Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.
Здравствуйте, Abyx, Вы писали:
A>императивный язык, A>мутабельные данные, которые надо менять по определенным алгоритмам, которые использует несколько частей программы.
Ты описываешь некое решение, а надо бы начать с задачи.
A>попытка применить чистые функции выродится в вызовы A>data1, data2, data3 = some_pure_fn(data1, data2, data3) A>итого мы получим кучу мелких чистых функций и другую кучу не-чистых функций
И? "Куча мелких чистых функций" — это однозначно хуже, чем "стопка крупных грязных классов"?
A>попытка применить процедурный подход сведется к использованию абстрактного типа данных, т.е. ООП.
Поскольку
Разве "ADT" == "OOP"?
Зачем тогда выдумывать новый термин "ООП"?
A>пример из реальной жизни — файлы, сокеты и другие источники/приемники данных
Здравствуйте, Mamut, Вы писали:
A>>вот и работает ФП только для задач типа символьного дифференцирования, A>>а чтобы что-то из реальной жизни описать, или быстро md5 посчитать — это нет, тут только С#/джава или C/C++
M>У нас вот, 100 человек функционально все описывают. Что мы делаем не так?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Steamus, Вы писали:
S>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.
IT>Понятие?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Steamus, Вы писали:
S>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия. 0>"Нечто"
0>А теперь объясни, что именно ты пытался доказать этим вопросом?
Лишь то, что мозг всегда классифицирует окружающий мир, дабы упростить его отображение, отбросив несущественные детали. Просто для части людей это тяжело даётся. Обычно их называют лириками/художниками. Они склонны мыслить наблюдаемыми или осязаемыми образами, а не абстракциями. Им действительно сложно отбросить малозначащую шелуху, абстрагироваться от деталей и скацентироваться на главном.
Здравствуйте, Steamus, Вы писали:
S>Лишь то, что мозг всегда классифицирует окружающий мир, дабы упростить его отображение, отбросив несущественные детали. Просто для части людей это тяжело даётся. Обычно их называют лириками/художниками. Они склонны мыслить наблюдаемыми или осязаемыми образами, а не абстракциями. Им действительно сложно отбросить малозначащую шелуху, абстрагироваться от деталей и скацентироваться на главном.
Все это круто и я с этим не спорю.
Сомнения вызывает гомоморфизм описанного с ООП, особливо с тем ООП, которое мы наблюдаем в нынешнем мэйнстриме.
Здравствуйте, Mamut, Вы писали:
M>>>У нас вот, 100 человек функционально все описывают. Что мы делаем не так?
A>>а кто-то на асме код пишет, и что?
M>И то. Что твое заявление о неприспособленности ФП для реальной жизни, мягко говоря, смешно.
Смешно моделировать действительность функциональным языком. Хотя, скорее грустно.
По ссылке — как раз яркий пример, что мы не мыслим объектами 
Если нам не помогут, то мы тоже никого не пощадим.
