Re[23]: Обновление
От: Кодт Россия  
Дата: 01.11.04 17:39
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

S>В общем, я зверств-то не хуже Вирта могу попридумывать.


Примерно так народ с перфокартами трахался.
Только там был ещё один пункт, о котором ты забыл: write-only memory. То есть ты, как дурак, топчешь клавиатуру перфоратора, а он тебе показывает лишь номер текущей позиции. Сбился? Отмена, и всю строку заново. Как пароль со звёздочками (до 72 штук). Вот только если ты облажался с паролем, тебе сразу скажут. А перфоратор — он тупой. Пробивает перфокарту, ты берёшь эту колоду и идёшь к машине. Пуск... Авотхрен.
В больших ВЦ, помимо этого, существовал пространственно-временной лаг между программистом и машиной — девочки-наборщицы. Там время перекомпиляции (иногда по вине девочки) занимало до суток — пока очередь подойдёт.

(Мне в детстве удалось поиграть у отца на работе — Fortran-4 на ЕС-1035. Вещ. С непривычки по полколоды шло сразу в макулатуру. Потом наловчился).
Перекуём баги на фичи!
Re[23]: Обновление
От: Mamut Швеция http://dmitriid.com
Дата: 01.11.04 17:48
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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


M>>Опять же, повторюсь: Почему среды разработки Турбо Паскаль/Турбо С лучше Блэкбокса
Автор: Mamut
Дата: 01.11.04

S>Не, ты не понял. Основной принцип Вирта — "Тяжело в учении, легко в бою".



S>...Я, кстати, не понимаю, почему это он не поставил ограничение на частоту компиляции. Нефиг! Ведь это стимулирует написание кода кое-как — фигня, компилятор поправит.

Я бы, кстати, ввел бы Очень бы научило думать

S>В общем, я зверств-то не хуже Вирта могу попридумывать.


Бррр... Не надо
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


dmitriid.comGitHubLinkedIn
Re[27]: Мэйнстрим vs. Самосовершенствование :)))
От: prVovik Россия  
Дата: 01.11.04 17:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


V>>Влад, а как ты вообще относишься к обобщенному программировнию?

VD>Отлично.
А как тогда это соотносится с фразой:

Сортировка — это метод. Имея возможность применять его к более широкому ряду объектов мы нарушаем принцип инкапсуляции.

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

VD>Как тебе скзать. К нему лично я не как не отношусь. Но к выдранным из контекста фразам я всегда отношусь плохо.

Что из какого контекста я выдрал?

VD>К абстрактным рассуждения общ эффективности я тоже отношусь крайне скептически. Рассуждения о том, что "добавление четырех элементов не будет примитивной, так как она вполне эффективно реализуется через операцию добавления" явно натянуто. Добавление нескольких элементов обычно можно реализовать намного эффективнее если иметь доступ к закрытым членам.

Ты это читал: Re[27]: Мэйнстрим vs. Самосовершенствование
Автор: prVovik
Дата: 01.11.04
?
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[24]: Обновление
От: prVovik Россия  
Дата: 01.11.04 18:05
Оценка: :)
Здравствуйте, Кодт, Вы писали:

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


S>>В общем, я зверств-то не хуже Вирта могу попридумывать.


К>Примерно так народ с перфокартами трахался.

К>Только там был ещё один пункт, о котором ты забыл: write-only memory. То есть ты, как дурак, топчешь клавиатуру перфоратора, а он тебе показывает лишь номер текущей позиции. Сбился? Отмена, и всю строку заново. Как пароль со звёздочками (до 72 штук). Вот только если ты облажался с паролем, тебе сразу скажут. А перфоратор — он тупой. Пробивает перфокарту, ты берёшь эту колоду и идёшь к машине. Пуск... Авотхрен.
К>В больших ВЦ, помимо этого, существовал пространственно-временной лаг между программистом и машиной — девочки-наборщицы. Там время перекомпиляции (иногда по вине девочки) занимало до суток — пока очередь подойдёт.

К>(Мне в детстве удалось поиграть у отца на работе — Fortran-4 на ЕС-1035. Вещ. С непривычки по полколоды шло сразу в макулатуру. Потом наловчился).


Да... Похоже, не одного Вирта настольгия мучает
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[27]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 01.11.04 18:55
Оценка: 43 (3) +1
VladD2:

> ПК> Ерунда. Разговор был о наличии конкретной функции sort() в интерфейсе конкретного класса Array.


> И что в этом есть проблемы?


Да, конечно. Они уже были перечислены. Кратко: размещение вспомогательных функций в виде членов класса требует последующих модификаций класса при добавлении очередных вспомогательных функций.

> ПК> Напротив, это ты перешел к навязыванию такого расположения функции sort(),

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

INTP_mihoshi сказал
Автор: INTP_mihoshi
Дата: 27.10.04
:

VD>И кстати, что тебе не нравится в Шарпе с точки зрения ООП?

То же, что и в Яве, то, что в нем объектом приходится делать даже то, что объектом не является.

(как мы уже выяснили
Автор: INTP_mihoshi
Дата: 28.10.04
, он немного неточно выразился, и имел в виду не объекты, а классы)

Sinclair (http://rsdn.ru/forum/?mid=870335):
Автор: Sinclair
Дата: 27.10.04

Во как интересно. Например, что?


Т.к. я испытываю тот же дискомфорт, что и INTP_mihoshi, я привел
Автор: Павел Кузнецов
Дата: 28.10.04
конкретный пример такого "класса", который классом быть не должен, а должен был быть namespace:

Например, я не вполне понимаю, зачем обобщенные алгоритмы типа сортировки делать методами классов Вот пример такого, с позволения сказать, класса: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Arrays.html — ни состояния, ни поведения, ни инвариантов


На что ты бросился в бой
Автор: VladD2
Дата: 29.10.04
, причем, споря совершенно о другом:

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


Как видишь, это замечание совершенно не в тему, т.к. в примере, который я привел (java.util.Arrays) ничего при нажатии на точку не выскочит. Единственная претензия, которая была у меня к приведенному примеру — использование "класса" не по делу, там где по всему видно, что должен был быть namespace, о чем я и написал
Автор: Павел Кузнецов
Дата: 29.10.04
. О помещении sort() в класс Array, как ты это подразумевал в своем сообщении, я только сказал, что это вопрос спорный, и привел основание против таких действий: нарушение некоторых из принципов ООП.

Далее ты начал начал говорить о том, что вынесение sort() за пределы класса Array нарушает инкапсуляцию и т.п. И хотя это уже просто чистой воды ерунда, я все-таки продолжил с тобой разговор. Сейчас вижу, что совершенно зря, т.к. мы говорим на разных языках. Буду рад обнаружить, что я не прав, и ты способен продолжать дискуссию в нормальном тоне.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[28]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.04 19:16
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Конкретная реализация тут не при чем. Подглава книги называется Измерение качества абстракции. И по словам Буча, одним из критериев качества интерфейса является его примитивность. Контейнер Set был приведен для примера, чтобы пояснить понятие "примитивность". Кстати, на счет производительности он пишет дальше:


Примитивность и примитивизм разные вещи. Все хорошо в меру.

Класс предназначенный для манипуляции с данными должен обладать нужными для этого методами. Иначе получишь примитивизм.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.04 19:16
Оценка: -2
Здравствуйте, prVovik, Вы писали:

V>Вот для контейнеров, сортировка которых действительно требует доступа к внутренней структуре ее, конечно, надо делать внутренним методом.

V>Для всего остального подойдет внешний обобщенный алгоритм сортировки типа std::sort()

А для всех остальных он просто не нужен. Он реально нужен именно в классе вроде вектора.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 01.11.04 19:29
Оценка: 33 (4) +3
VladD2:

> ПК> Я правильно понял, что ты утверждаешь, что Open-Closed Principle не имеет отношения к ОО дизайну? Если ты о чем-то другом, пожалуйста, сформулируй свою мысль яснее.


> Он не имеет отношения к базовым концепциям ООП и приплетается тобой не к месту. Андестенд?


Чего же здесь непонятного? Понятно, что ты даже в www.google.com посмотреть не сходил, прежде чем утверждать подобные вещи.

>>> Более того. В твоем видение она даже становится вредной, так как отрицает базовые концепции вроде инкапсуляции.


> ПК>Это каким же образом? Как именно вынесение sort() за пределы Array нарушает инкапсуляцию?


> Я тебе это уже объяснял. Сортировка — это метод. Имея возможность применять его к более широкому ряду объектов мы нарушаем принцип инкапсуляции.


Как ты себе представляешь нарушение инкапсуляции в данном случае? Если интерфейс класса позволяет передать его в sort(), инкапсуляция не будет нарушена, т.к. и без sort() пользователь может сам проделать эквивалентные действия. Если же предполагается, что эти действия нарушат инварианты класса, то это просто означает, что у данного класса интерфейс составлен неверно, т.к. он не должен позволять нарушать инварианты. В любом случае наличие "внешней" функции sort() инкапсуляцию класса не нарушает.

> ПК>Давай-ка ты подтвердишь это утверждение хоть какими-то ссылками на классику ООП.


> Давай-ка ты пойдеш лесом. А? Я тебе не нанимался искать ссылки по всему Интернету.


Ок. Так и запишем: свое утверждение о нарушении базовых положений ООП в результате вынесения sort() за пределы класса Array Влад доказывать отказался.

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


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

> ПК> Нет, этого "требования инкапсуляции" не говорят. Впрочем, подозреваю, что ты просто можешь очень неточно выражать свои мысли. Чтобы была хоть какая-то ясность, насколько применимы "требования инкапсуляции" в твоей трактовке к классическим образцам дизайна, прокомментируй свое высказывание, процитированное выше, на некоторых из наиболее характерных в этом отношении design patterns: Command, State, Strategy, Visitor, Builder.


> Не, ну, нужно вообще потерять чувство реальности, чтобы просить в качестве коментария написать небольшую книгу (ну, страниц так на 400).


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

А так... Ты привел свое правило размещения методов в классе:

Если функция изменяет состояние объекта и при этом не воздействует на другие объекты, то эта функция является методом этого объекта. Ну, или должна была им являться.

При этом поминая нарушение инкапсуляции в противном случае. Так как принятие твоих высказываний в буквальном виде означает согласие с твоей полной некомпетенцией относительно трактовки нарушений инкапсуляции, я решил этого не делать, а добиться от тебя более подробной и точной формулировки. Соответственно, приведя стандартные паттерны, основанные на вынесении модификации за пределы модифицируемого класса. Если ты полагаешь, что в них инкапсуляция не нарушается, просто так и скажи. Но тогда твое утверждение, процитированное выше, никак с сохранением инкапсуляции, вопреки твоим ранним высказываниям, не связано. Все дела

> ПК> Как же так получается, что (потенциальная) модификация объекта специально выносится за его пределы? Неужели все эти паттерны тоже нарушают инкапсуляцию?

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

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

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

>
> Если убрать общие слова, то единственной проблемой этого примера является отсуствие инкапсуляции. О чем и шла речь.

Пока что ты так и не показал, как же именно нарушается инкапсуляция в случае вынесения функции sort() за пределы класса Array. От того, что ты утверждаешь, что это так, истинным это утверждение не становится.

>>> Внешние функции той же сортировки — это как раз такое нарушение.

>
> ПК> В случае сортировки никакие инварианты класса Array не нарушаются.
>
> Агащасблин. Сортировка очередей и потоков — это нормально? Не нужно пытаться уйти от обсуждения вопросвов инкапсуляции к черте чему.

Все зависит от определений. В любом случае, если очереди нельзя сортировать, то они не будут предоставлять интерфейс, нужный функции sort(). Если они уже предоставляют такой интерфейс, то наличие "внешней" функции sort() никак на ситуацию не влияет, т.к. пользователь уже волен это делать своими действиями.

> Согласен. Только к делу это не относится. Бывают случаи когда класс в силу не зависимых причин обладает интерфейсом пригодным для применения того или иного метода. Так что случяйное применение можно избежать только строгим подходом к инкапсуляции.


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

> Стремление к супер универсальности и выносе всего в глобальные методы как раз и приводит к подобным причинам.


К подобным последствиям приводит неверное наследование, нарушающее принцип LSP. Если наследование не отражает отношения "is-a", то никакие припарки в виде запретов внешних функций не помогут, т.к. инварианты с тем же успехом могут быть нарушены через интерфейс базового класса.

> А уж напичкивание классов типа вектора несвойственными ему методами вроде pop и т.е. просто провацирует к применению классов не по назначению.


Каким образом метод pop() нарушает инкапсуляцию класса vector? И чем, с твоей точки зрения данный метод отличается от Add() или аналогичного?

> ПК>Раздувание интерфейсов классов без необходимости противоречит грамотному проектированию.


> Словоблудие.


Очень странно, что с такого словоблудия начинаются большая часть более-менее объемных книжек по ООП

> Ты можешь хоть на ушах ходить, но пользоваться дотнетными коллекциями проще, удобнее и безопаснее.


Удобнее пользоваться чем какими коллекциями? Напоминаю, что речь шла о массивах в Java.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[29]: Мэйнстрим vs. Самосовершенствование :)))
От: prVovik Россия  
Дата: 01.11.04 20:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Примитивность и примитивизм разные вещи. Все хорошо в меру.

VD>Класс предназначенный для манипуляции с данными должен обладать нужными для этого методами. Иначе получишь примитивизм.

Ну никто же не говорит, что не делать полезные методы вообще. Просто не следует помещать непримитивные методы в ИНТЕРФЕЙС класса. Лучше их сделать в виде отдельных утилит класса. В принцепе, подобные утилиты можно помещать в класс в виде его статических методов, но тут надо внимательно следить, чтобы эти методы использовали только открытую часть интерфейса, а о закрытой и думать не смели. Но у размещения утилит внутри класса в виде статических методов есть еще один недостаток (помимо доступа к закрытой части интерфейса), а именно то, что часто для таких утилит сложно определить, к какому классу они относятся. Например, если на вход подаются несколько объектов разных классов и эта утилита что-то делает с совокупностью полученных объектов, то куда ее можно отнести?
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[26]: Мэйнстрим vs. Самосовершенствование :)))
От: Undying Россия  
Дата: 01.11.04 20:57
Оценка: 36 (1)
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>+1. Я только хотел подчеркнуть, что, с моей точки зрения, общим подходом должно быть принятие подобных решений в частном порядке. И иногда, учитывая все за и против, прибегать к более сложным паттернам, а не просто ограничиваться наследованием и "ужирнением" интерфейсов (interface bloat), "пытаясь писать в ОО-стиле".


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

ПК>В качестве одного из предусловий я упомянул, что код, использующий классы, разработчиками напрямую не контролируется. Соответственно, к изменению семантики некоторой функции в библиотечном классе я отношусь крайне настороженно, представляя последствия замены использования в методе Array.sort() функции stable_sort() (сохраняющей порядок "одинаковых" элементов) на более быструю (в некоторых случаях) quick_sort()... В этих условиях, имхо, изменение семантики как раз совершенно недопустимо.


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

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


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

ПК> Естественно, если все было спроектировано на совесть, дублирования аналогичных вызовов Array.sort быть не должно, т.к. доступ к некоторому Array должен контролироваться одним классом, и, соответственно, в данном классе, представляющем абстракцию уровня кода приложения, изменять семантику подобных методов вполне допустимо. Воздействие таких изменений, в отличие от правки общих компонент, ограничены и предсказуемы, т.к. соответствующая сортировка привязана к контексту, и ожидания от нее хорошо известны.


Вот это не понял, можно пояснить мысль примером.

ПК>Ну, со своей стороны могу также точно заверить тебя, что пользоваться обобщенными алгоритмами, не привязанными к конкретным коллекциям, не менее удобно. В некотором роде, при последовательном развитии этого подхода, это становится даже ближе к функциональному программированию, так модному нынче на РСДН


Когда вызовов этих внешних функций всего несколько, то да пользоваться ими нормально, а вот когда они используются на каждом углу, то код загромождается весьма прилично.

ПК>Ага. А теперь представляем ситуацию, что часть ArrayList'ов мы получаем в "готовом" виде, из библиотечных функций, а часть, своих оберток, создаем сами... Боюсь, в результате, работать по-разному с по-сути одинаковыми контейнерами будет не очень удобно. Впрочем, здесь каждый сам для себя выбирает...


Не понял в чем проблема и зачем с ними по разному работать? Естественно у обертки есть конструктор принимающий ArrayList, соответственно преобразование в обертку производится одной строчкой: new Wrapper(arrayList).

ПК>Я придерживаюсь концепции, рекомендующей по умолчанию помещать методы в класс, являющий субъектом, а не объектом действия, предоставляя в объекте достаточный для реализации намерений субъекта интерфейс. В частности, возвращаясь к твоему примеру, мы говорим: "(Мы) толкнем шарик с силой F" (скорее, даже: "Передать шарику импульс P") Но это уже софистика, т.к. в том, что у шарика неизбежно будет какой-то метод, принимающий воздействие, ты, естественно, прав.


Но "Мы" опять же объект, а не функция.

ПК>P.S. Кстати, хорошую аналогию ты подобрал. Представим, что нам часто приходится катать шарик по кругу. С моей точки зрения функция go_round интерфейсу шарика не принадлежит, являясь наглядным примером вспомогательного алгоритма, который стоит реализовать через "основной" интерфейс "шарика" (accept_impulse etc.).


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

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

ПК>А гласит он, что в частности классы по возможности следует проектировать так, чтобы в дальнейшем их не модифицировать, а только расширять поведение, пользуясь их интерфейсом, наследованием и добавлением новых сущностей, с данными классами взаимодействующими.


Т.е. рефакторинг ты не используешь? Т.к. рефакторинг как раз означает модифицирование кода с целью уменьшения имеющихся хаков (в частности "лишних" наследований) к минимуму.
... << RSDN@Home 1.1.2 stable >>
Re[26]: Мэйнстрим vs. Самосовершенствование :)))
От: Undying Россия  
Дата: 01.11.04 21:34
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Я вполне могу, и уже это делал: инкапсуляция нарушается, если интерфейс класса позволяет нарушать его инварианты. Вопреки твоим утверждениям положение функции сортировки вовне класса к таким последствиям не приводит.


Внешняя функция сортировки нарушает инкапсуляцию коллекции, т.к. ее использование означает явное указание метода сортировки.
... << RSDN@Home 1.1.2 stable >>
Re[27]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 01.11.04 22:03
Оценка:
Undying:

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


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

> ПК> к изменению семантики некоторой функции в библиотечном классе я отношусь крайне настороженно, представляя последствия замены использования в методе Array.sort() функции stable_sort() (сохраняющей порядок "одинаковых" элементов) на более быструю (в некоторых случаях) quick_sort()... В этих условиях, имхо, изменение семантики как раз совершенно недопустимо.

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

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

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


Предложенная ранее альтернатива (изменить семантику метода класса) мне не кажется более удачной.

> ПК> Естественно, если все было спроектировано на совесть, дублирования аналогичных вызовов Array.sort быть не должно, т.к. доступ к некоторому Array должен контролироваться одним классом <...>

>
> Вот это не понял, можно пояснить мысль примером.

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

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

array.sort();

sort(array);

Не вижу сколько-нибудь заметной разницы в объеме написанного кода

> Не понял в чем проблема и зачем с ними по разному работать? Естественно у обертки есть конструктор принимающий ArrayList, соответственно преобразование в обертку производится одной строчкой: new Wrapper(arrayList).


Ок, я почему-то представил себе ситуацию, когда для получения Wrapper нужно скопировать в него содержимое ArrayList.

> ПК> "(Мы) толкнем шарик с силой F" (скорее, даже: "Передать шарику импульс P") Но это уже софистика, т.к. в том, что у шарика неизбежно будет какой-то метод, принимающий воздействие, ты, естественно, прав.


> Но "Мы" опять же объект, а не функция.


"Мы" — да, "толкнем" — нет: если всем подряд приходится "толкать шарик", вовсе не факт, что хорошим решением является наследование их всех от какого-то общего класса только для того, чтобы выполнять какое-то действие с внешним объектом.

> ПК> P.S. Кстати, хорошую аналогию ты подобрал. Представим, что нам часто приходится катать шарик по кругу. С моей точки зрения функция go_round интерфейсу шарика не принадлежит, являясь наглядным примером вспомогательного алгоритма, который стоит реализовать через "основной" интерфейс "шарика" (accept_impulse etc.).

>
> Во-первых, ты свел идею к абсурду (т.е. предложил любую функцию пихать в интерфейс)

Дык, я как раз пытаюсь добиться внятного ответа, где же по мнению тех, кто помещает sort() в Array лежит та граница... Влад выдвинул критерий модификации объекта, согласно которому подобные функции должны будут включаться в интерфейс шарика.

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


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

> Т.е. рефакторинг ты не используешь? Т.к. рефакторинг как раз означает модифицирование кода с целью уменьшения имеющихся хаков (в частности "лишних" наследований) к минимуму.


Рефакторинг я очень люблю и уважаю. Но для "внутренних" проектов, где весь код находится под контролем разработчиков. И с определенными ограничениями. Для библиотек же, "торчащих" наружу, я больше люблю и уважаю обратную совместимость.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[27]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 01.11.04 22:33
Оценка:
Undying:

> ПК> инкапсуляция нарушается, если интерфейс класса позволяет нарушать его инварианты. Вопреки твоим утверждениям положение функции сортировки вовне класса к таким последствиям не приводит.


> Внешняя функция сортировки нарушает инкапсуляцию коллекции, т.к. ее использование означает явное указание метода сортировки.


Не обязательно:
class Collection1;
class Collection2;

void sort(Collection1&);
void sort(Collection2&);
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[28]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.04 23:16
Оценка:
Здравствуйте, prVovik, Вы писали:

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


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


V>>>Влад, а как ты вообще относишься к обобщенному программировнию?

VD>>Отлично.
V>А как тогда это соотносится с фразой:

Сортировка — это метод. Имея возможность применять его к более широкому ряду объектов мы нарушаем принцип инкапсуляции.

V>Получается, что обобщенной программирование в целом противоречит инкапсуляции? Ведь обобщенный алгоритм можно применить к широкому ряду объектов.

Все получается отлично если отделять мух от катлет. В данном случае интерфейс от реализации. Да и класс тоже может быть обобщенным. А стало быть и метод в нем.

VD>>Как тебе скзать. К нему лично я не как не отношусь. Но к выдранным из контекста фразам я всегда отношусь плохо.

V>Что из какого контекста я выдрал?

Цитату из контекста в котором она была сказана.

VD>>К абстрактным рассуждения общ эффективности я тоже отношусь крайне скептически. Рассуждения о том, что "добавление четырех элементов не будет примитивной, так как она вполне эффективно реализуется через операцию добавления" явно натянуто. Добавление нескольких элементов обычно можно реализовать намного эффективнее если иметь доступ к закрытым членам.

V>Ты это читал: Re[27]: Мэйнстрим vs. Самосовершенствование
Автор: prVovik
Дата: 01.11.04
?


Теперь да. Это как раз и доказывает, что цитата была вырвана из контекста. С данной оговоркой фраза уже становится менее натянутой.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.04 23:16
Оценка: -1
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Да, конечно. Они уже были перечислены. Кратко: размещение вспомогательных функций в виде членов класса требует последующих модификаций класса при добавлении очередных вспомогательных функций.


Это не проблема. К тому же не у всех классов предпологаются наследники.

>> ПК> Напротив, это ты перешел к навязыванию такого расположения функции sort(),

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

ПК>INTP_mihoshi сказал
Автор: INTP_mihoshi
Дата: 27.10.04
:

ПК>

VD>>И кстати, что тебе не нравится в Шарпе с точки зрения ООП?

ПК>То же, что и в Яве, то, что в нем объектом приходится делать даже то, что объектом не является.

ПК>(как мы уже выяснили
Автор: INTP_mihoshi
Дата: 28.10.04
, он немного неточно выразился, и имел в виду не объекты, а классы)


ПК>Sinclair (http://rsdn.ru/forum/?mid=870335):
Автор: Sinclair
Дата: 27.10.04

ПК>

ПК>Во как интересно. Например, что?


ПК>Т.к. я испытываю тот же дискомфорт, что и INTP_mihoshi, я привел
Автор: Павел Кузнецов
Дата: 28.10.04
конкретный пример такого "класса", который классом быть не должен, а должен был быть namespace:

ПК>

ПК>Например, я не вполне понимаю, зачем обобщенные алгоритмы типа сортировки делать методами классов Вот пример такого, с позволения сказать, класса: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Arrays.html — ни состояния, ни поведения, ни инвариантов


ПК>На что ты бросился в бой
Автор: VladD2
Дата: 29.10.04
, причем, споря совершенно о другом:

ПК>

ПК>если все методы (пусть и статические) помещать в класс к которому они относятся, то любой дурак нажав точку в IDE получит их список.


ПК>Как видишь, это замечание совершенно не в тему, т.к. в примере, который я привел (java.util.Arrays) ничего при нажатии на точку не выскочит. Единственная претензия, которая была у меня к приведенному примеру — использование "класса" не по делу, там где по всему видно, что должен был быть namespace, о чем я и написал
Автор: Павел Кузнецов
Дата: 29.10.04
. О помещении sort() в класс Array, как ты это подразумевал в своем сообщении, я только сказал, что это вопрос спорный, и привел основание против таких действий: нарушение некоторых из принципов ООП.


ПК>Далее ты начал начал говорить о том, что вынесение sort() за пределы класса Array нарушает инкапсуляцию и т.п. И хотя это уже просто чистой воды ерунда, я все-таки продолжил с тобой разговор. Сейчас вижу, что совершенно зря, т.к. мы говорим на разных языках. Буду рад обнаружить, что я не прав, и ты способен продолжать дискуссию в нормальном тоне.


Специльно не поскипал твою тираду. Так где из всех этих метс я перешел к навазыванию "такого расположения функции sort"? Зачем столько слов? Может быть просто признать тот факт, что это ты пыташся выдать свое мнение за единстванно верное и тем самым навязать его, а я все го лишь говорю, что считаю иначе?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Обновление
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.04 23:16
Оценка: +1
Здравствуйте, prVovik, Вы писали:

V>Еще хуже то, что раскрашивать это надо вручную. Имхо, это не применимо.


Я думаю, что под расскарской имелось в виду выделение отдельных частей кода с целей акцентировать на них внимание. Мы часто применяем такой прием в статьях на сайте. В принципе это действительно удобно. Но подсветки синтаксиса это не заменяет и не отменяет.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Обновление
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.04 23:16
Оценка:
Здравствуйте, Кодт, Вы писали:

Ну, тогда оберон в пролете, а детей и правда нужно учить программировать на ассемблере (как завещал Серджинио1) .
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 01.11.04 23:45
Оценка: +1
VladD2:

> ПК>На что ты бросился в бой
Автор: VladD2
Дата: 29.10.04
, причем, споря совершенно о другом:

> ПК>

> ПК>если все методы (пусть и статические) помещать в класс к которому они относятся, то любой дурак нажав точку в IDE получит их список.
> ПК>

> ПК>Как видишь, это замечание совершенно не в тему <...> Далее ты начал начал говорить о том, что вынесение sort() за пределы класса Array нарушает инкапсуляцию и т.п. <...>

> Специльно не поскипал твою тираду. Так где из всех этих метс я перешел к навазыванию "такого расположения функции sort"?


В последнем процитированном сообщении, и далее по ветке. При этом постоянно поминая инкапсуляцию:

По теории ООП все методы объекта желательно помещать в его класс. Ну, а как они там внутри реализованы... дык на то есть инкапсуляция.

и обвиняя оппонента в "детских ошибках".

> Может быть просто признать тот факт, что это ты пыташся выдать свое мнение за единстванно верное и тем самым навязать его, а я все го лишь говорю, что считаю иначе?


Какое именно мое мнение? Ты опять пропустил, что началось все с того, что ты зачем-то приплел в разговор размещение sort() и т.п. "в классе, к которому они относятся", хотя речь шла совершенно о другом. Как я мог навязывать кому-то свое мнение, если я до твоего высказывания даже не упоминал?
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[30]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.11.04 01:37
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Ну никто же не говорит, что не делать полезные методы вообще.


Кое-кто кто все же говорит.

V>Например, если на вход подаются несколько объектов разных классов и эта утилита что-то делает с совокупностью полученных объектов, то куда ее можно отнести?


Скорее всего тут проблемы в понимании приципов ООП. Мыслить от "утилиты"/"сотелиты" вообще вредно. Сделай декомпозицию на уровне классов и скорее всего окажется, что функция является методом некоторого другого класса.

В общем, в борьбе за чистоту вы викидываете с грязной водой и купаемое в ней детя.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.11.04 01:37
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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


У пользователя не будет даже желания изобретать ненужный метод. А вот совершенно случайно его применить можно легко.

ПК>Ок. Так и запишем: свое утверждение о нарушении базовых положений ООП в результате вынесения sort() за пределы класса Array Влад доказывать отказался.


Да пиши что хочешь. Можеш даже пойти в гугль поискать там подтверждение своим выводам.

ПК>Дык, я ж тебе привел названия классических критериев. Тебе достаточно просто погуглить по этим названиям.


Мне то зачем? Ты что-то хочешь доказать. Вот и гугли.
Мне вообще очень не наравится монера посылать других что-то искать. Тебе надо ты и ищи.

ПК>Причем здесь книга?


При том что описанные вопросы тянут именно на нее.

ПК> Для того, чтобы указать, что то или иное изменение интерфейса нарушает инкапсуляцию, достаточно продемонстрировать один пример, как пользуясь данным методом можно будет нарушить инварианты класса.


Ну, продемонстрируй.

ПК>А так... Ты привел свое правило размещения методов в классе:

ПК>

ПК>Если функция изменяет состояние объекта и при этом не воздействует на другие объекты, то эта функция является методом этого объекта. Ну, или должна была им являться.

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

Или тем что ты хочешь выдать чужие слова за некомпетентность.

ПК> я решил этого не делать, а добиться от тебя более подробной и точной формулировки. Соответственно, приведя стандартные паттерны, основанные на вынесении модификации за пределы модифицируемого класса. Если ты полагаешь, что в них инкапсуляция не нарушается, просто так и скажи. Но тогда твое утверждение, процитированное выше, никак с сохранением инкапсуляции, вопреки твоим ранним высказываниям, не связано. Все дела


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

ПК>Я вполне могу, и уже это делал: инкапсуляция нарушается, если интерфейс класса позволяет нарушать его инварианты.


С чего бы это? И вообще, что ты понимашь под "позволяет нарушать его инварианты"?

ПК> Вопреки твоим утверждениям положение функции сортировки вовне класса к таким последствиям не приводит.


Так к какм проблемам приводит то, что класс ArrayList или List<T> содержит методы сортировки? Ну, только без философии. Ты из жизни хоть один пример приведи.

ПК>Пока что ты так и не показал, как же именно нарушается инкапсуляция в случае вынесения функции sort() за пределы класса Array. От того, что ты утверждаешь, что это так, истинным это утверждение не становится.


Я тебе уже показал. Но ты так мирно отфильтровал.

>> Агащасблин. Сортировка очередей и потоков — это нормально? Не нужно пытаться уйти от обсуждения вопросвов инкапсуляции к черте чему.


ПК>Все зависит от определений. В любом случае, если очереди нельзя сортировать, то они не будут предоставлять интерфейс, нужный функции sort(). Если они уже предоставляют такой интерфейс, то наличие "внешней" функции sort() никак на ситуацию не влияет, т.к. пользователь уже волен это делать своими действиями.


"Волен" и "сделает" разные вещи. Убирая привязку метода ты провоцерущь на случайное использование и вынуждаешь расширять интерфейс класса чтобы обеспечить нужные возможности из вне.

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


В приципе разумно. Но тем не менее жалание минимизировть интерфейс приводит именно к нарушениям инкапсуляции. Многие операции просто эффективнее делать членами класса. Хотя бы по причине доступности функций работы с той же памятью. Извне ArrayList/List я просто не могу заниматься передвижкой блоков памяти в базовом массиве. И я или буду вынужден расширять интерфейс низкоуровневыми операцииями или все же вводить функции вроде AddRange в интерфейс класса. Ну, или наплевать на произодительность и добавлять элементы по одному двигая память при каждом добавлении.

ПК>К подобным последствиям приводит неверное наследование, нарушающее принцип LSP. Если наследование не отражает отношения "is-a", то никакие припарки в виде запретов внешних функций не помогут, т.к. инварианты с тем же успехом могут быть нарушены через интерфейс базового класса.


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

>> А уж напичкивание классов типа вектора несвойственными ему методами вроде pop и т.е. просто провацирует к применению классов не по назначению.


ПК>Каким образом метод pop() нарушает инкапсуляцию класса vector? И чем, с твоей точки зрения данный метод отличается от Add() или аналогичного?


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

ПК>Очень странно, что с такого словоблудия начинаются большая часть более-менее объемных книжек по ООП


Объем еще не является гарантией качества. Как раз талантливые изложения обычно довольно кратки.

>> Ты можешь хоть на ушах ходить, но пользоваться дотнетными коллекциями проще, удобнее и безопаснее.


ПК>Удобнее пользоваться чем какими коллекциями? Напоминаю, что речь шла о массивах в Java.


Чем СТЛ, например. А что ты докопался до статических методов в Яве я вообще не понял. Видимо ты по началу не въехал в то что они статические, а потом уже Остапа понесло.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.