А для меня — жесткая связь.
Неразрывная по времени исполнения и по интерфейсу.
Никто не вклинится между ними, потому что теперь посчитает себя важнее в этих случаях из-за изменившихся требований (как фаервол вклинивается в общение сервера-клиента, например).
Т.е логика запрятана в самом факте вызова И поменять ее нельзя снаружи. В сообщениях запрятанную логику можно снаружи переопределить в некоторых рамках.
> Мне кажется, или второе понятие шире?
Не стоит забывать что главное во втором определении «внимание наблюдателя».
А оно очень быстро меняется в run-time ;)
Например, берем объект Арбуз — вроде как объект? Берем нож и режем им арбуз. Теперь у нас сколько объектов? :) И процесс нарезания это метод какого объекта, а главное с какими параметрами? :)
И все это вообще никак не ложится в программирование. Потому что там нет «существующих в реальной действительности» объектов. Мы можем все скопировать 10 раз. Это другой мир. Яблоко не скопируешь. Документ скопируешь, но для реального мира — это будут 2 разных объекта на разных листах бумаги.
ps. А еще ООП есть прототипное и динамическое (JS), в котором нет понятия «класс» и типы могут меняться в реально времени (например, в зависимости от ввода пользователя). И менять интерфейсы и объекты в нем можно вообще на лету без перезапуска системы!
Вот вот — самому вручную передавать свой this. Язык в этом никак не помогает.
Причем контекст исполнения (стек исполнения) остается какой? Мы из О1.м1 вызываем О2.м2 из которого снова О1.м3 при этом все еще остаемся внутри не завершенного первого метода О1.м1.
Сравните с сообщением — отправили и вышли из метода не дожидаясь результата.
А что тогда?
«интеллектуальные агенты»?
Это когда кусок кода решает «мне нужны сейчас фото» и копируется на сервер где они хранятся и там исполняется. А потом с этими результатами копируется на сервер где хранится почта и продолжает обработку.
Ну я грубо :)
При таких задачах речь идет уже о распределенной среде и тут как бы ООП уже непричем…
А это смотря как объекты между собой общаются.
Грубо лезут в кишки — т.е вызывают чужие методы.
Или без жестких связей посылают сообщения «а у меня тут такое случилось… кнопку нажали» — и все кто хотел — добавился Listener-ами к этому.
Т.е вопрос вычисления «кто главный, кто принимает решения, где бизнес-логика», а не ООП как такового.
Это всего лишь пример.
Вот оконный менеджер не знает что у вас за приложение — броузер, архиватор или 3D игра, но при этом он знает как свернуть окно, как закрыть приложение, как показать его название и иконку в списке задач. Но ведь приложения разные!
А почему так? Да потому что приложения пишутся под менеджер окон, а не наоборот!
Так и с печами — если печи разные, то их специально будут делать одинаковыми в управлении, потому что мы такое ТЗ делаем.
Минусы как-то описывались в «как программисты строят дома».
Примерно — один начал строить этажи, второй шахту лифта. Но тут оказалось что высота и к-во дверей лифта не совпадает с высотой этажей. А про лестницу и дверь вообще забыли. И надо переделывать.
Т.е хорошо на первом этапе — каждый свою подзадачу успешно сделал. А потом вдруг находятся зависимости, про которые не подумали и тут получается уже не так все радостно.
Т.е это «подумать и спроектировать заранее, вместо сразу реализовывать подзадачи» напрямую не относится к ООП.
Не совсем.
Для задачи — «реализуйте 5 разных печей и параллельно обучите 5 Иванов, при этом каждую печь проектируют отдельные люди» — нет.
И для задачи «ты пока реализуй 2 печи, а потом ты уволишься, а придет кто-то новый и ему нужно будет еще 3 сделать» — тоже.
Что-то мне кажется что это "… если… мы правильно.." отмазка фанатов парадигмы :)
Надо думать о другом — какой из доступных на сегодня вариантов что дает.
А точнее — какой из вариантов построения систем больше всего облегчит изменения ее.
Даже если нас попросят из носорога сделать бабочку :)
Руководству нужны «фичи» и оно не думает о будущем. Проблемы решаются по мере поступления :)
Это не техническая проблема. Это проблема взаимодействия разработчиков.
Называйте классы в виде Class324324 и меняйте 324324 на другой автозаменой каждый день. Это техническое «решение», которое же не решит реальную проблему :))
Разница есть.
Мы взбираемся по пирамиде абстракций.
Чем выше — тем меньше шансов что фундамент (модель) окажется не правильной.
Потому надо не про DSL говорить, а сравнивать DSL и ООП. И тут шансы у DSL выше.
Хоть это все еще и не идеал :)
Да просто выкинуть один язык/базу/технологию и сменить все на другие — уже большой плюс.
ps. а когда не устраивает фундамент — мы строим новый дом и переезжаем :)
Т.е не решена пока (вроде?) проблема миграции данных из модели в модель.
Статью прочтите (хоть бегло).
Там как раз и расхваливают DSL за то что изменения в модели можно вносить часто и безболезненно.
Т.е оно само меняет все взаимосвязанные части.
Вот только остается вопрос что делать с существующими реальными данными… но там это тоже упоминается.
Вот вы говорите «совсем надежно». Это значит кто-то нарушает договоренности зафиксированные, скажем, в документации? В рамках команды им можно просто по голове за такое дать :))
Другое дело если у вас нет влияния на разработчиков использующих вашу часть системы…
ps. и это нам показывает что ООП не достаточно. Т.е уровня protected свойств не хватает уже. Нужны proctected объекты в рамках… модулей?!
pps. а исходники у вас открыты для всех? Если нет — в конструкторе принимайте параметр — пароль. И без пароля чужих не допускать! :-D
ООП позволяет свои личные абстракции делать частью языка (и соответственно проверять на уровне компилятора), а DSL позволяет оставить в языке только свои личные абстракции, убрав базовые (которые из ООП не выбросишь).
А если к вам приходит разработчик угольной печи и говорит «не — не получится, кто-то ж должен уголь насыпать в печь — это ж не газ и не электричество». Вы ему сможете смело ответить — А это все потому что вы не правильно абстракции выбрали! :)
Неразрывная по времени исполнения и по интерфейсу.
Никто не вклинится между ними, потому что теперь посчитает себя важнее в этих случаях из-за изменившихся требований (как фаервол вклинивается в общение сервера-клиента, например).
Т.е логика запрятана в самом факте вызова И поменять ее нельзя снаружи. В сообщениях запрятанную логику можно снаружи переопределить в некоторых рамках.
Не стоит забывать что главное во втором определении «внимание наблюдателя».
А оно очень быстро меняется в run-time ;)
Например, берем объект Арбуз — вроде как объект? Берем нож и режем им арбуз. Теперь у нас сколько объектов? :) И процесс нарезания это метод какого объекта, а главное с какими параметрами? :)
И все это вообще никак не ложится в программирование. Потому что там нет «существующих в реальной действительности» объектов. Мы можем все скопировать 10 раз. Это другой мир. Яблоко не скопируешь. Документ скопируешь, но для реального мира — это будут 2 разных объекта на разных листах бумаги.
ps. А еще ООП есть прототипное и динамическое (JS), в котором нет понятия «класс» и типы могут меняться в реально времени (например, в зависимости от ввода пользователя). И менять интерфейсы и объекты в нем можно вообще на лету без перезапуска системы!
А ООП этого не может сделать.
Т.е получаем новый язык, но чистый — только то что нам нужно. Собственно потому этот L и DS :)
Причем контекст исполнения (стек исполнения) остается какой? Мы из О1.м1 вызываем О2.м2 из которого снова О1.м3 при этом все еще остаемся внутри не завершенного первого метода О1.м1.
Сравните с сообщением — отправили и вышли из метода не дожидаясь результата.
«интеллектуальные агенты»?
Это когда кусок кода решает «мне нужны сейчас фото» и копируется на сервер где они хранятся и там исполняется. А потом с этими результатами копируется на сервер где хранится почта и продолжает обработку.
Ну я грубо :)
При таких задачах речь идет уже о распределенной среде и тут как бы ООП уже непричем…
Грубо лезут в кишки — т.е вызывают чужие методы.
Или без жестких связей посылают сообщения «а у меня тут такое случилось… кнопку нажали» — и все кто хотел — добавился Listener-ами к этому.
Т.е вопрос вычисления «кто главный, кто принимает решения, где бизнес-логика», а не ООП как такового.
Вот оконный менеджер не знает что у вас за приложение — броузер, архиватор или 3D игра, но при этом он знает как свернуть окно, как закрыть приложение, как показать его название и иконку в списке задач. Но ведь приложения разные!
А почему так? Да потому что приложения пишутся под менеджер окон, а не наоборот!
Так и с печами — если печи разные, то их специально будут делать одинаковыми в управлении, потому что мы такое ТЗ делаем.
Примерно — один начал строить этажи, второй шахту лифта. Но тут оказалось что высота и к-во дверей лифта не совпадает с высотой этажей. А про лестницу и дверь вообще забыли. И надо переделывать.
Т.е хорошо на первом этапе — каждый свою подзадачу успешно сделал. А потом вдруг находятся зависимости, про которые не подумали и тут получается уже не так все радостно.
Т.е это «подумать и спроектировать заранее, вместо сразу реализовывать подзадачи» напрямую не относится к ООП.
Для задачи — «реализуйте 5 разных печей и параллельно обучите 5 Иванов, при этом каждую печь проектируют отдельные люди» — нет.
И для задачи «ты пока реализуй 2 печи, а потом ты уволишься, а придет кто-то новый и ему нужно будет еще 3 сделать» — тоже.
Надо думать о другом — какой из доступных на сегодня вариантов что дает.
А точнее — какой из вариантов построения систем больше всего облегчит изменения ее.
Даже если нас попросят из носорога сделать бабочку :)
Это не техническая проблема. Это проблема взаимодействия разработчиков.
Называйте классы в виде Class324324 и меняйте 324324 на другой автозаменой каждый день. Это техническое «решение», которое же не решит реальную проблему :))
Мы взбираемся по пирамиде абстракций.
Чем выше — тем меньше шансов что фундамент (модель) окажется не правильной.
Потому надо не про DSL говорить, а сравнивать DSL и ООП. И тут шансы у DSL выше.
Хоть это все еще и не идеал :)
Да просто выкинуть один язык/базу/технологию и сменить все на другие — уже большой плюс.
ps. а когда не устраивает фундамент — мы строим новый дом и переезжаем :)
Т.е не решена пока (вроде?) проблема миграции данных из модели в модель.
Там как раз и расхваливают DSL за то что изменения в модели можно вносить часто и безболезненно.
Т.е оно само меняет все взаимосвязанные части.
Вот только остается вопрос что делать с существующими реальными данными… но там это тоже упоминается.
Другое дело если у вас нет влияния на разработчиков использующих вашу часть системы…
ps. и это нам показывает что ООП не достаточно. Т.е уровня protected свойств не хватает уже. Нужны proctected объекты в рамках… модулей?!
pps. а исходники у вас открыты для всех? Если нет — в конструкторе принимайте параметр — пароль. И без пароля чужих не допускать! :-D
DSL рулит.
msdn.microsoft.com/ru-ru/library/aa302173.aspx
(понравилось в начале описание процесса упрощения разработки с помощью введения абстракций).
ООП позволяет свои личные абстракции делать частью языка (и соответственно проверять на уровне компилятора), а DSL позволяет оставить в языке только свои личные абстракции, убрав базовые (которые из ООП не выбросишь).
Тут только объект вызывает второй объект. И второй даже не догадывается кто его вызвал.
А с сообщениями — не факт что на твое сообщение кто-то ответит вообще. А если ответит — то он значит должен знать кому отвечает.