Comments 41
Если имя выбрано неудачно и оно с искажениями отражает то, чем является модель
Вы словом "модель" неудачно назвали какую-то сущность (в широком смысле слова, похоже один класс) с которой оперируете. Модель — это совокупность сущностей, моделирующих предметную область. В вашем случае, в моделировании запуска виртуальной машины, похоже, модель заключается в команде/сервисе запуска с параметрами.
Согласен, тоже слово перегруженное ассоциациями. Но в ООП много способов применения классов и не для всех способов применения выбор имени класса может иметь такое существенное значение.
В терминах MVC модель — не класс, отражающий какое-нибудь важное понятие или предмет из предметной области, а либо (строго) класс или классы, скрывающий (адаптер, прокси и т. п.) совокупность классов, отражающих понятия или предмет из предметной области, либо (чаще применяется) сама эта совокупность. Выражение "класс модели" нужно понимать чаще всего не как "класс, реализующий модель", а как "класс, принадлежащий модели, реализующий часть модели".
А то что авторы некоторых фреймворков/библиотек выбирают (обычно при реализации ORM паттерна ActiveRecord) Model для имени базового класса, от которого должны наследоваться персистентные сущности модели — как раз пример неудачного именования, вводящего в заблуждение использующих этот класс :)
Ну и модель в rails уже достаточно многие используют без привязки именно к ActiveRecord, а именно как четко выделенную группу классов, которые моделируют предметную область, оторванную от представления для пользователя или для API.
Я учился на книжках Гради Буча и т.п. древностях, и у меня сложилось представление об ООП принципиально отличающееся от того, что под ООП понимают сейчас. Мне кажется, мир перевернулся… Для меня объекты (сиречь классы) — это отражение сущностей РЕАЛЬНОГО мира в ВИРТУАЛЬНУЮ область. Иными словами для меня выглядит логичной классификация вроде: РЫБЫ-ПТИЦЫ-ЖИВОТНЫЕ, РЫБЫ: КАРАСЬ, ПТИЦЫ: УТКА; ПТИЦЫ: УТКА: ЛЕТАТЬ, ПТИЦЫ: УТКА: ПЛАВАТЬ, РЫБЫ: КАРАСЬ: ПЛАВАТЬ, РЫБЫ: ЛЕТУЧАЯ_РЫБА: ЛЕТАТЬ и т.п.
Но читая хабр я убеждаюсь, что сейчас принято строить ОО-модели совсем иначе — от ДЕЙСТВИЯ или от ЦЕЛИ (например). То есть вполне допустимой считается объектная модель типа ЛЕТАЛКИ-ХОДИЛКИ-ПЛАВАЛКИ, ЛЕТАЛКИ: УТКА, ЛЕТАЛКИ: ЛЕТУЧАЯ_РЫБА, ХОДИЛКИ: ВОЛК, ХОДИЛКИ: УТКА…
Я понимаю, что виртуальный мир программирования не обязан подчиняться закономерностям реального мира, но ведь и тем и другим заправляет человек, а уж ему-то изначально ближе классическая структуризация объектов реального мира! Все-таки видовая классификация устроена иначе… Класс бытовых приборов включает в себя телевизор и депилятор, и классификация их по иным признакам (напр., развлекательные приборы или средства удаления волос) по определению вторична, когда ее ставят на первое место — это выворачивание реальности наизнанку…
Соответственно, проблема именования порождается именно из когнитивного диссонанса между реальностью и виртуальностью. Если подвести второе под гребенку первого — проблема именования исчезнет: главное — это существительное, глаголы обозначают действия существительного над другими объектами, прилагательные — это свойства существительных…
Откуда пошло это массовое увлечение переиначивание привычного в непривычное? Неужели так легче жить программисту, находясь между реальным и выдуманным и занимаясь сшиванием одного с другим белыми нитками странных интерфейсов?!
Реальный мир состоит из, грубо говоря, объектов и процессов их взаимодействия. ООП (в мэйнстрим реализациях) в качестве реализаций процессов по умолчанию предлагает методы объектов (с возможными параметрами, в том числе в виде объектов), но всё многообразие отношений реального мира сложно свести к действиям, совершаемых объектами, к чёткой картине "существительное-глагол", поэтому вводят объекты, имитирующие процессы без явных действий какого-то субъекта… Кажется это вы имеете в виду.
Но примеры вы приводите не об этом :), а о способе построения иерархий объектов. Так вот, при моделировании реального мира в целях решения конкретных задач иерархия строится так, чтобы максимально отражать важные для решаемой задачи отношения, а не какие-то "естественные". Для задачи, например, выбора снаряжения для ловли животных, абсолютно не важно, что утка и летучая мышь принадлежат к далеко отстоящим друг от друга ветвям в общепринятой биологической таксономии, важно что они могут летать, а акулы и дельфины плавать, что для ловли летающих животных нам нужна, например, сеть, выстреливаемая в воздух конкретно по цели, а для плавающих — выставляемая в воде заранее. Причём если мы соберемся ловить квадрокоптеры, которые вообще животными не являются, то выстреливаемая сеть тоже пойдёт, а против торпед — выставляемая. Для подобных задач нам важно летает цель в воздухе или плавает в воде, а насколько цели родственны в биологической таксономии нам не важно. Куда логичнее разделить объекты "цель" на "леталка", "плавалка" и т. д., чем объединять уток и страусов, летучих мышей и дельфинов, квадрокоптеры и торпеды в какие-то "естественные" иерархии, а потом по слабозначащим для этих иерархий признакам выбирать что нам делать.
Моделирование реального (или воображаемого, например в играх) мира заключается в выкидывании ненужных для решаемой задачи свойств объектов (в широком смысле слова) и отношений между ними и в акцентировании на важных. В рамках ООП это заключается в построении объектов, иерархий наследования и полиморфных свойств в порядке важном для задачи. Утка.лети(), ЛетучаяМышь.лети(), Квадрокоптер.лети(), АбстрактнаяЛеталка.лети(), Рыба.плыви(), Дельфин.плыви(), Торпеда.плыви(). АбстрактнаяПлавалка.плыви(). Какая нам разница, что летучая мышь очень дальний родственник утки, а квадрокоптер вообще не животное, а что утка может плавать нас вообще не интересует?
Куда логичнее разделить объекты «цель» на «леталка», «плавалка» и т. д., чем объединять уток и страусов, летучих мышей и дельфинов, квадрокоптеры и торпеды в какие-то «естественные» иерархии, а потом по слабозначащим для этих иерархий признакам выбирать что нам делать.Почему же «по слабозначащим»? Выбор будет идти по тем «умениям», которые реализует класс.
То есть — да, всё, что вы сказали правда — но обусловлена она ограничениями языков программирования.
Причём тут языки программирования? Меня, как разработчика системы защиты какой-то локации или объекта от вторжения, мало интересует, что дельфины и летучие мыши — животные и достаточно близкие родственники, а квадрокоптеры и торпеды — механизмы с электродвигателями. Для меня всё это цели, делящиеся на цели воздушные и цели подводные. Если для системы и имеет значение, является цель живым животным или искусственным механизмом, то это следующий уровень иерархии. Среда в которой придётся противодействовать вторжению имеет большее значение, чем философские категории.
Среда в которой придётся противодействовать вторжению имеет большее значение, чем философские категории.Пока вы пишите узкоспециализированную программу — да. Но для узкоспециализированной и, соответственно, небольшой программы все эти иерархии классов и разводить зачастую не нужно.
А вот в большой программе — часто оказывается что один компонент хочет работать с квадрокоптерами как с летучими мышами (потому что их нужно ловить), а другой — хочет обьединять их с торпедами (потому как обоим нужны аккумуляторы).
В наиболее распространённых языках в этом месте как раз и появляются все эти фасилитаторы.
Моделирование реального (или воображаемого, например в играх) мира заключается в выкидывании ненужных для решаемой задачи свойств объектов (в широком смысле слова) и отношений между ними и в акцентировании на важных. В рамках ООП это заключается в построении объектов, иерархий наследования и полиморфных свойств в порядке важном для задачи
Куда логичнее разделить объекты «цель» на «леталка», «плавалка» и т. д., чем объединять уток
Причём тут языки программирования? Меня, как разработчика системы защиты какой-то локации или объекта от вторжения, мало интересует, что дельфины и летучие мыши — животные
А вот в большой программе — часто оказывается что один компонент хочет работать с квадрокоптерами как с летучими мышами
Вы не заметили, что в вашем споре вы соглашаетесь и не соглашаетесь одновременно, то есть фактически ваш спор ни о чём?
Проведя параллель, я бы сказал что вы обсуждаете вкусы и пристрастия, о которых, как известно — не спорят. Я же не соглашусь с вами обоими, особенно вот в этой части:
иерархий наследования и полиморфных свойств в порядке важном для задачи
Надеюсь меня не заминусуют, но есть огромная разница между наследованием, которое строго иерархиично и предназначено исключительно для переиспользования кода и задачам классификации, то бишь выделения нужных и общих признаков и работы с объектами на их основе, а именно — «важном для задачи». Так вот, классификация не может иметь порядка, это фильтр, где несколько признаков равнозначны и параллельны, а не наследуются друг от друга. Соответственно одними и теми же признаками могут обладать совершенно разные и чуждые друг другу объекты. Фактически, у нас есть интерфейсы для классификации и иерархия для переиспользования кода. Если код для летучей мыши можно использовать для создания кода для квадракоптера — наследуйтесь не задумываясь. Если некоторые свойства торпеды и рыбы позволяют нам абстрагироваться и работать с ними как с объектом одного типа — объединяем их в рамках классификации интерфейсом и работаем когбуд-то бы с одноим объектом, но именно в рамках конкретного использования, а не вообще.
Если же следовать вашим рамкам, где классификация должна иметь иерархию, то вы придёте к тому, что с добавлением новых объектов, всё должно быть переписано, потому что новый признак стал главнее (собственно, ваш пустой спор о том, какие признаки главнее. да ещё и в какой ситуации) и теперь он должен быть корневым, о каком переиспользовании кода может тогда идти речь?
Классификация не должна, а может иметь иерархию. Но в целом, в переписывании по мере уточнения требований нет ничего страшного, это нормальный процесс.
А спор не о том, какие признаки главнее, а том, нужно ли определять какие главнее в рамках задачи и "плясать" от них или нужно брать готовые "ественные" квалификации и втискивать в неё задачу.
Нет никаких проблем с тем, что бы определить важные признаки, если известна конкретная задача.
Надо контролировать доступ в помещение: (дверь и окно и угол открытия), пробитие предметами (дверь и стена и их прочность), классификация всегда идёт под задачу, никакая иерархия не нужна, наследовать никакую дверь от стены тоже не надо. Более того, признаки, одних задач никак не должны влиять на признаки других, поэтому я и указал, что такие классификации параллельны.
Есть проблемы с тем, что бы определить важные признаки, если нет никакой задачи, а эти признаки, как элемент классификции рассматривать именно на будущее в плане наследования, что является в корне не верно, как я уже написал.
Когда процессы и отношения только зарождаются — готовых моделей нет и их нужно придумывать. Один из первых подходов — использовать физические объекты и процессы, но сразу же упрощать, убирать все неважное, оставлять только минимально необходимое.
Собственно, никто не мешает вам иметь как одно, так и другое (и их одновременно), в зависимости от того, что вам в конкретной задаче удобнее.
Это кажется только с точки зрения научной биологической таксономии :) С точки зрения утиной типизации Леталки вполне имеют право на жизнь даже как полноценные классы.
С точки зрения палеонтолога (и космолога, кстати) — таксономия современных существ есть срез длящегося миллиарды лет процесса.
Чтобы это ощутить, понять этих учёных — достаточно увидеть изменения, например, сравнив современных китов и их первопредка. Объекты эволюции существуют внутри процесса.
Если мы моделируем процесс эволюции, то научная биологическая таксономия станет, скорее всего, основой иерархии модели. Если мы моделируем процесс защиты какого-то объекта от вторжения, то для нас определяющими свойствами будет среда (воздух, вода, поверхность земли, поверхность воды) в которой осуществляется вторжение, а не космологические категории.
Думать надо. В случае RPG навскидку проще получится, если основной классификацией будет по возможностям персонажа, а эволюционное дерево — дополнительной, связанной с основной, например, композицией.
Вообще то я хотел сказать кое что попроще — что объекты существуют в некоем процессе или потоке событий и имеют поведение. Это может быть и простейшим течением времени и логическими связями и чем то ещё.
Но вот выделение объектов только на основании поведения и приводит к появлению леталок вместо уток.
Ага, имеем кучу методов, висящих в одном пространстве имен. Появляется мысль, не сгруппировать ли их каким-то образом. Ага, вводим понятие "модуль", распихиваем методы по модулям. Теперь метод принадлежит модулю, и вызывается аналогично методу объекта "[module].[method]" с точностью до разделителя. С той только разницей, что модуль у нас один, и получается как бы синглтон. Ага, появляются вопросы, как нам в этом синглтоне чего-нибудь поменять, как переиспользовать код, не копипастя лишнего, как подменить реализацию, например, для работы с другой БД. Получается то же самое, только с другой стороны.
Теперь метод принадлежит модулю, и вызывается аналогично методу объекта "[module].[method]" с точностью до разделителя.Это ещё зачем? Методы, «работающие» с объектами разных классов не могут перепутаться просто потому что у них аргументы разных типов, однако.
Пространства имён — да, возможны, но это уж для очень монструозных проектов. И они вообще ничего общего ни с методами, ни с объектами на имеют.
Ага, появляются вопросы, как нам в этом синглтоне чего-нибудь поменять, как переиспользовать код, не копипастя лишнего, как подменить реализацию, например, для работы с другой БД.Это, я извиняюсь, называется Java головного мозга. Откуда синглтон? Почему, зачем? Не хотите смотреть как это сделано в LISP'е — посмотрите как перегрузка операторов, функций и пространства имён реализованы в C++. Вот конкретно это место там реализовано почти хорошо — единственная проблема, что всё происходит во время компиляции. Если бы те же алгоритмы применялись в рантайме к реальным, динамическим типам — был бы практически CLOS.
Недаром говорят, что тот, кто не понимает LISPа обречён изобрести его кривую копию. C++ к этому уже близок, Java тоже туда же двигается потихоньку…
Это ещё зачем? Методы, «работающие» с объектами разных классов не могут перепутаться просто потому что у них аргументы разных типов, однако.
Затем, чтобы можно было использовать функции с одним названием и одинаковыми типами аргументов, но с разной реализацией.
actionEdit(string id)
query(string sql)Или вот нашел я баг в сторонних исходниках, как мне переопределить функцию, чтобы она по-другому работала в моем коде и как было в чужом? Все равно без группировки функций в какие-то подмножества не обойтись, надо хотя бы разделять на локальное и глобальное пространство.
Откуда синглтон? Почему, зачем? Не хотите смотреть как это сделано в LISP'е
Смотрел я, как это сделано в LISP'е. Похоже на паттерн-матчинг в Erlang'е. Язык тут ни при чем. Модуль с набором функций — это фактически аналог глобального синглтона. Как и статический класс. Мы можем использовать только один экземпляр этого модуля.
Сравните:
use math;
y = math.sin(x);
global math = Math::getInstance();
y = math.sin(x);Затем, чтобы можно было использовать функции с одним названием и одинаковыми типами аргументов, но с разной реализацией.Но… зачем?
actionEdit(string id)Первого примера я в принципе не понял (какой-то фасилитатор потерялся?), а второй будет
query(string sql)
query(mysqlink database, string sql)Откуда тут путаница возьмётся? Пусть их хоть 100 будет — но они работают с разными обьектами!
query(htmldom domtree, string xpath)
...
Все равно без группировки функций в какие-то подмножества не обойтись, надо хотя бы разделять на локальное и глобальное пространство.Это другое — это пакеты. Чтобы скрыть локальные и глобальные обьекты и функции.
Смотрел я, как это сделано в LISP'е. Похоже на паттерн-матчинг в Erlang'е. Язык тут ни при чем.Язык формирует мышление. Тот факт, что функции в большинстве языков принадлежат обьектов вызвало кардинальную Java'у головного мозга у большинства разработчиков. В большинстве действий участвуют два (а иногда и более) обьекта — почему оно должно принадлежать одному из них?
Причём ладно бы только у «быстрых» языков, где это эффективностью реализации определяется. Так ведь всякие тормозные ruby и python'ы — туда же.
Но… зачем?
Я привел примеры ниже в том комменте. Есть много причин, когда нужна другая обработка тех же аргументов. Для оптимизации или тестирования например.
Первого примера я в принципе не понял (какой-то фасилитатор потерялся?)
Это обработчик запроса на редактирование сущности. В контроллере действий с заказами и в контроллере действий с пользователями есть метод actionEdit(), который принимает строковый id объекта, который передается в get-параметре. Но я уже понял, что вы предлагаете создавать специальный объект, чтобы вызвать нужный метод. Вместо того, чтобы прямо поместить этот метод в объект.
query(mysqlink database, string sql)
И в чем тогда профит, если нам всегда надо таскать объект определенного типа?
query(mysqlink database, string sql)
query(postgresqlink database, string sql)
а еще
open(mysqlink database)
close(mysqlink database)
open(postgresqlink database)
close(postgresqlink database)
И тому подобная куча копипасты. А потом мы обнаружили ошибку и решили исправить mysqlink на mysql_link, и пришлось поменять в 2 раза больше строк, чем нужно. А если мы еще и пропустили где-то… Не критично, просто зачем? Если можно сгруппировать связанные методы в класс. Результат ведь будет тот же самый, только первый аргумент с другой стороны от названия функции. Тем более что мультиметоды и в классах могут работать.
Это другое — это пакеты. Чтобы скрыть локальные и глобальные обьекты и функции.
Модули, пакеты, не суть. Суть в том, что появляется группировка связанных методов.
В большинстве действий участвуют два (а иногда и более) обьекта — почему оно должно принадлежать одному из них?
Потому что это отражает способ мышления в реальности. Мы знаем, что дверь может открываться и закрываться. Это не значит, что дверь сама решила что-то сделать, это значит, что мы относим действие открыть и закрыть к возможным действиям с дверью. Так же как и свойство "открыта" после их выполнения.
Но я уже понял, что вы предлагаете создавать специальный объект, чтобы вызвать нужный метод.Java головного мозга. Поздняя стадия.
Методы не должны принадлежать обьектам. Они их связывают. Оптимизация сделанная десятки лет назад настолько вьелась вам в мозг, что вы даже представить не можете, что метод может не быть частью обьекта!
Мы знаем, что дверь может открываться и закрываться.Не может она сама по себе открываться и закрываться! Её кто-то открывает и закрывает. Это может быть человек или (если дверь автоматическая) специальный механизм.
Потому что это отражает способ мышления в реальности.Серьёзно? Спросите у непрограммиста: «во фразе „Вася открыл дверь“ слово „открыл“ принадлежит Васе или двери?» Он на вас как на идиота посмотрит.
Результат ведь будет тот же самый, только первый аргумент с другой стороны от названия функции.Результат не будет тот же самый. Потому что имея методы как отдельные сущности с ними можно и работать как с отдельными сущностями.
Можно сделать что-то примерно следующее (примерный псевдокод):
isolated_processing(class storage, class text):И вы сможете туда передать и mysqlink и html_parser, и строки и какие-нибудь бинарные заранее подготовленные запросы.
open(storage)
query(storage, text)
close(storage)
Копи-паста — это не тут. Копи-паста — это вам в Java. Где из-за необходимости обрабатывать разные обьекты по разному вы эти свои «сгруппированные методы» вынуждены дублировать десятки и сотни раз.
Какое уж тут «переиспользование кода»…
Но я уже понял, что вы предлагаете создавать специальный объект, чтобы вызвать нужный метод.
Java головного мозга. Поздняя стадия.
Методы не должны принадлежать обьектам. Они их связывают. Оптимизация сделанная десятки лет назад настолько вьелась вам в мозг, что вы даже представить не можете, что метод может не быть частью обьекта!
Воздержитесь, пожалуйста, от подобных диагнозов. Я вроде вас не оскорблял.
У меня нигде не написано, что они обязательно "должны" принадлежать объектам. С процедурным программированием я знаком, да и с функциональным тоже. И если вы не заметили, в моих примерах есть только один объект Math::getInstance().
Тем не менее, вы все равно, предлагаете создавать специальный объект определенного типа, чтобы вызвать нужный метод из нескольких actionEdit. Принципиально это ничем не отличается от обычного объектного подхода.
Ниже я отвечал на вашу фразу "должно принадлежать", и сказал, что это не принадлежность к реальному объекту как таковая, а отражение модели в мышлении человека. У самой двери нет состояния "открыта" или "закрыта", есть только положение в пространстве. Это мы определяем ее состояние по положению относительно других объектов. С методами аналогично.
Далее. Я говорил не о том, что везде нужны объекты, а о том, что нужна какая-то группировка функций. И вот группировать их по возможности применения к объекту определенного типа бывает довольно удобно. А если в языке так сделать нельзя, все равно появляются модули или пакеты, которые можно рассматривать как объект. Я не спорю с тем, что мультиметоды это полезная штука.
Не может она сама по себе открываться и закрываться! Её кто-то открывает и закрывает. Это может быть человек или (если дверь автоматическая) специальный механизм.
Она не сама открывается и закрывается. Это мы относим к ней такое действие.
Серьёзно? Спросите у непрограммиста: «во фразе „Вася открыл дверь“ слово „открыл“ принадлежит Васе или двери?» Он на вас как на идиота посмотрит.
Серьезно. Спросите у непрограммиста: «во фразе „Вася открыл дверь“ слово „открыл“ относится к действиям с Васей или с дверью?». А заодно спросите, встречал ли он фразу "Дверь неожиданно открылась".
И вы сможете туда передать и mysqlink и html_parser, и строки и какие-нибудь бинарные заранее подготовленные запросы.
Ну и чем это отличается от такого варианта:
isolated_processing(storage, text):
storage.open()
storage.query(text)
storage.close()И там и там надо делать реализацию метода open, которая будет работать с объектом конкретно этого типа. А еще надо смотреть, а все ли у меня действия с нужными типами определены, а нет ли конфликтов с каким-нибудь "open(string url)" или "open(string filename)". Кстати, что должно означать действие "открыть строку"?
Копи-паста — это вам в Java. Где из-за необходимости обрабатывать разные обьекты по разному вы эти свои «сгруппированные методы» вынуждены дублировать десятки и сотни раз.
Не знаю, как там в Java. "У меня" в PHP трейты есть. А если туда перегрузку функций завезут, будет еще лучше.
И там и там надо делать реализацию метода open, которая будет работать с объектом конкретно этого типа. А еще надо смотреть, а все ли у меня действия с нужными типами определены, а нет ли конфликтов с каким-нибудь «open(string url)» или «open(string filename)».Вообще-то подобными проверками должен заниматься компилятор. И так, как вы сказали, будет в Google Go или в G++ 2.95 (с его сигнатурами). В большинстве же языков вам этого сделать не удастся если разработчики классов storage заранее об этом не позаботятся.
Вы зря к синтаксиса прицепились — дело ведь действительно не в нём. Вопрос прост: должны мы уметь описывать все классы, в которые логически попадает объект — или нет.
Так вот в CLOS/GOOPS/Google Go эта классификация — не «зашивается» в классы! Она может быть расширена потом! Что и делает все споры типа показанных выше гораздо менее острыми. Вам не нужно всё переделывать с одной таксономии на другую при изменении требований, так как этих таксономий может быть много — они друг другу никак не мешают и, главное, создавать новые таксономии можно после создания класса. Это — принципиальное отличие. Всё остальное, действительно, «рюшечки»…
Засовывая же всё на свете в объекты вы порождаете лютый копи-паст на всех уровнях — и даже этого не замечаете.
Кстати, что должно означать действие «открыть строку»?Вы это странное действие придумали — вы и решайте что оно значит…
не удастся если разработчики классов storage заранее об этом не позаботятсяЕсли не позаботились, может он там и не нужен? Если у меня есть сторонний класс Url, то метод open(Url url) должен быть не в Url, а в другом классе WebBrowser.
создавать новые таксономии можно после создания классаНовая таксономия — новое название, которое имеет семантику и должно быть отражено в коде. В виде собственно названия, а не безымянного набора дополнительных методов. Впрочем, не буду отрицать, у классов в текущем виде тоже свои недостатки есть.
Засовывая же всё на свете в объекты вы порождаете лютый копи-пастНе больше, чем засовывая в модули или пакеты. Пакет — это такой же объект, содержащий методы. Другое дело, что иногда лучше поместить метод open не в класс Дверь, а в класс МетодыРаботыСДверью.
Вы это странное действие придумали — вы и решайте что оно значитЭто вы писали, потому и вопрос:
Можно сделать что-то примерно следующее (примерный псевдокод):
isolated_processing(class storage, class text): open(storage)
И вы сможете туда передать и mysqlink и html_parser, и строки
В виде собственно названия, а не безымянного набора дополнительных методов.Зачем?
Впрочем если уж есть желание что-то обязательно называть, то это можно сделать: в CLOS/GOOPS можно просто добавить в список предков класса новый на лету, в Google Go — собрать методы в интерфейс.
Если у меня есть сторонний класс Url, то метод open(Url url) должен быть не в Url, а в другом классе WebBrowser.А что будет есть разработчики WebBrowser и Url — это разные люди? Генераторы фасилитаторов?
И вы сможете туда передать и mysqlink и html_parser, и строкиХабр опять съел слово. «Тестовые строки». В unit-тестах. open/close — ничего делать не будет, query — будет на равенство сравнивать.
Хотя, может быть, тут уже стоит создать тестовый класс DummyStorage…
Вроде как большинство мэйнстрим ООП языков позволяют совмещать объекты с принадлежащими ими методами с классическими функциями и процедурами. А в меньшинстве эмулировать их через вырожденные объекты без состояния, пускай синтаксически и несколько многословно — по паре строчек (не считая скобок) вместо одной.
Вроде как большинство мэйнстрим ООП языков позволяют совмещать объекты с принадлежащими ими методами с классическими функциями и процедурами.Классические функции не имеют отношения к ООП вообще.
ООП — это у нас что? Инкапсуляция, наследование, полиморфизм. Так вот с последним — как раз и возникает беда из-за отсутствия в языках мультиметодов.
Возьмите классические геометрические фигуры, с которых обычно начинают «рассказ про ООП». Вот это вот:
draw(DirectXContext, circle)Концептуально — должно быть одним мультиметодом. А на практике — это невозможно.
draw(PostScriptContext, circle)
draw(DirectXContext, rectangle)
draw(PostScriptContext, rectangle)
Главное — даже не то, что вам приходится создавать drawInDirectXContext и drawInPostScriptContext! Главное — что вы не можете добавить drawInVulcanContext без порождения новых сущностей!
Потому и порождается куча вспомогательных обьектов и прочего, чтобы с этим бороться.
Вот и всё. Ограничения Smalltalk'а очень сильно продвинули ООП в сторону громоздкости и неестественности.
Из распространённых языков, пожалуй только Go делает это «в правильном ключе». Но даже у него это не так элегантно сделано как в оригинале.
Откуда пошло это массовое увлечение переиначивание привычного в непривычное?От Smalltalk'а. Далее Objective C, C++, Java и прочее. Отказ от «сложного» подхода типа CLOS/GOOPS примело нас в королевство существительных.
Имена или семантика классов в программировании