Здравствуйте, Павел Кузнецов, Вы писали:

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

Какие на фиг go_round? Если ты будешь описывать все возможные варианты движения, то ты модель никогда не создашь. Тут как-то нужно идти от приложения силы и подели мира воздействующего на него. Именно в мире будет этот нечто заставляющее делать шарик этот самый "go_round" при воздействии на шарик.

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

Здравствуйте, Сергей Губанов, Вы писали:

VD>>Ага. Вместо того чтобы сделать подсветку синтаксиса.

СГ>Нужна — сделай сам. Все в твоих руках. Система открытая.

Ты это ученикам будешь рассказывать?

Я же к этому венцу убогости и криворукости притрагиваться не намерен.

ЗЫ

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

Я вот думаю, что потому что не нужна... сама среда.

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

AVK>Так примеры я уже неоднократно приводил — эвенты, боксинг,

Ну, это замазывание дыр Явы. Так что это явный плюс.

AVK> двойственная сущность енумов и т.п.

Это еще что?

Соновцы не реализовали энумы под предлогом того, что они не объектно ориентированы. А ты я гляжу уже новый предлог под это дело подводишь.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Из приведенного рисунка видно следующее:

СГ>1) Вы зачем-то засунули в Log текст программы и пару контролов... Log — предназаначен для вывода сообщений.
СГ>2) Для того чтобы написать свою программу нужно создать новый документ.
СГ>3) Контролы, вообще-то, принято помещать на формы.

СГ>Вывод:
СГ> Почитайте хелп.

Неверный вывод. Верный будет такой: ВЛЕС ЭТО УБОЖЕСТВО! Ведь на нем даже проффесианальный программист не смог примитивный "здарова, мир!" раписать.

Скачай Питон или Руби. Запусти их консоль. Погляди что такое просто и удобно! Потом скачай C# Express погляди, что такое очень гибко, удобно и проффесионально!

Здравствуйте, Сергей Губанов, Вы писали:

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

M>>...невозможно работать.

СГ>Из приведенного рисунка видно следующее:

СГ>1) Вы зачем-то засунули в Log текст программы и пару контролов... Log — предназаначен для вывода сообщений.

Log вообще не должен позволять в нем хоть что-то писать. Лог вообще не должен что-либо делать, кроме как показывать диагностические сообщения. Это Log

СГ>2) Для того чтобы написать свою программу нужно создать новый документ.

Предположим. В этом случае мне не видно Log, ошибки все равни выводятся в тексте программы. А это неочевидно и неинтуитивно Если текст программы не вмещается в экран? А из-за идиотского расположения окон он не будет никогда, то мне что, весь текст программы сканировать на предмет наличия ошибок? А что мне с ошибками потом делать? Стирать их, или они не влияют на компиляцию? То, что они не влияют на компиляцию неочевидно, так как они торчат прямо посреди текста и нарушают восприятие программы

СГ>3) Контролы, вообще-то, принято помещать на формы.

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

А как создается новая форма? Controls -> New form? Что такое Link? Ладно, лезем в желп, жмем Empty. А дальше? Боже! Это — визуальная среда? В коммандной строке и то информативности больше.


Вердикт. Oberon Microssystems наткнулась на книжицу "MFC in 21 days" и сейчас показывает нам, чему они научились. Сам такие поделки еще в прошлом году создавал (это я о среде BlackBox). Не удивлюсь, если сериализация/десериализация у них стандартными средствами MFC выполнена. И вы не поверите, но на исходники BlackBox я даже смотреть не буду. Повторяю, такие поделки выполняются на коленке в течение ... ну ... двух-трех часов. Ну и, возможно, час планирования.

Здравствуйте, Сергей Губанов, Вы писали:

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

К>>Значит, ты мало трахался с системами контроля версий.

СГ>...В конце концов, модуль — маленький. 1-модуль : 1-программист. Несколько программистов в один и тот же модуль код никогда не пишут.

Знаете, в хорошей команде:

— несколько человек не пишут в один и тот же .cpp-файл
— несколько человек не пишут в один и тот же .pas-файл
— несколько человек не пишут в один и тот же .php-файл
— несколько человек не пишут в один и тот же .vb-файл
— несколько человек не пишут в один и тот же .asp-файл
(из тех языков, с которыми имел дело)

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

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, Сергей Губанов, Вы писали:

К>>>Значит, ты мало трахался с системами контроля версий.

СГ>>Я неоднократно указывал на то что обероны, еще со времен Модулы, являются модульными языками. Но тут, видимо, никто не понимает что это такое. Вот и Вы тоже туда же. Не понимаете в чем состоит преимущество модульности... С модулями не возникает проблем контроля версий. Новому модулю дается новое имя (так же как с COM-интерфейсами). В конце концов, модуль — маленький. 1-модуль : 1-программист. Несколько программистов в один и тот же модуль код никогда не пишут.

ЗХ>Не, ну я так больше не могу!
ЗХ>Отладчик — порочно; контроль версий — порочно; подсветку синтаксиса — сделай сам...

ЗХ>И эти люди...
ЗХ>Я фигею, дорогая редакция...

(с) я здесь

Автор: Mamut
Дата: 31.10.04

Вердикт. Oberon Microssystems наткнулась на книжицу "MFC in 21 days" и сейчас показывает нам, чему они научились. Сам такие поделки еще в прошлом году создавал (это я о среде BlackBox). Не удивлюсь, если сериализация/десериализация у них стандартными средствами MFC выполнена. И вы не поверите, но на исходники BlackBox я даже смотреть не буду. Повторяю, такие поделки выполняются на коленке в течение ... ну ... двух-трех часов. Ну и, возможно, час планирования.

также Re[19]: Обновление (73 KB)

Автор: Mamut
Дата: 29.10.04

. Добавлю, что в Турбо С/ Турбо Паскале подсветка и контекстно-зависимая справка уже присутствовали.

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


M>Вердикт. Oberon Microssystems наткнулась на книжицу "MFC in 21 days" и сейчас показывает нам, чему они научились. Сам такие поделки еще в прошлом году создавал (это я о среде BlackBox). Не удивлюсь, если сериализация/десериализация у них стандартными средствами MFC выполнена. И вы не поверите, но на исходники BlackBox я даже смотреть не буду. Повторяю, такие поделки выполняются на коленке в течение ... ну ... двух-трех часов. Ну и, возможно, час планирования.

Да ты чё? Они там нибусь весь rtf-редактор вручную забубенили.

Ну, т.е. ответить нечего?

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

VD>Совсем согласен. Но все же когда язык или среда подталкивают все же лучше. Не все же программисты супер-ассы. Да и ассы в запарке лажу гонят.

Влад, сколько можно говорить — асс это задница.

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

AVK>>>Лучше бы тебе его не видеть
ЗХ>>Теперь точно буду смотреть... Заинтригован.
WH>Когда найдешь что почитать и чем компилять(под виндой) мне скажи, а то меня тоже давно его препроцессером интригуют.
А и пожалуйста!
Тута: http://home.nycap.rr.com/pflass/pli.htm
Вся возможная инфа и компиляторы.

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

AVK>Влад, сколько можно говорить — асс это задница.

Это если по англицки.

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

AVK>>Влад, сколько можно говорить — асс это задница.

VD>Это если по англицки.

А в русском вобще такого слова нет.

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

AVK>А в русском вобще такого слова нет.

Думаеш кто-то не понял? А в русском много каких слов нет.

VladD2:

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

> Нет, Паша, именно это ты и предлагаешь.

Ерунда. Разговор был о наличии конкретной функции sort() в интерфейсе конкретного класса Array. К тому же, если посмотреть на историю ветки, то можно увидеть, что я ничего не предлагал. Напротив, это ты перешел к навязыванию такого расположения функции sort(), в то время, как в примере, который я привел (по совершенно другому поводу), функция sort() находится не в классе Array, а в отдельном "классе", имитирующем namespace, java.util.Arrays.

> И именно это звучит очень смешно. В попытках обосновать дизайн СТЛ ты готов весь ООП вверх ногами перевернуть.

Где именно я "переворачиваю весь ООП вверх ногами"? То, что тебе оно знакомо в перевернутом виде, вовсе не означает, что это и есть правильная картина.

> <... эмоции и переходы к обсуждению взглядов оппонента вместо аргументации обсуждаемого вопроса поскипаны ...>

Так и запишем: по существу тебе сказать особенно нечего.

VladD2:

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

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

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

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

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

Давай-ка ты подтвердишь это утверждение хоть какими-то ссылками на классику ООП. А то как-то не очень понятно, кому же эта функция должна...

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

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

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

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

> int AddMinutes(int time, int minutes)
> {
>     return time + minutes * 60;
> }
>

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

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

В случае сортировки никакие инварианты класса Array не нарушаются.

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

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

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

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

> Собственно в отличии от твоего заявления мое подтверждается теорией и практикой ООП.

И теория, и практика ООП отлично подтверждают вред раздувания интерфейсов. Более того, даже название этому явлению придумали: "жирные" интерфейсы, interface bloat. Плюс сформулировали определенные критерии качества ОО дизайна, направленные на минимизацию обязанностей, и, как следствие, интерфейсов классов: Open Closed Principle (косвенно), Single Responsibility Principle, Interface Segregation Principle и т.д.

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

Лозунги, лозунги...

> ПК>Например, представим, что у нас есть скелет простенькой иерархии "библиотечных" контейнеров (псевдокод):
> ПК>

> ПК>interface Sequence<T>
> ПК>{
> ПК>   class Pos;
>
> ПК>   uint size();
> ПК>   bool is_empty();
>
> ПК>   Pos begin();
> ПК>   Pos end();
> ПК>   Pos next(Pos);
>
> ПК>   Pos insert(Pos, T);
> ПК>   void remove(Pos);
> ПК>   void clear();
> ПК>};
>
> ПК>interface RandomAccessibleSequence<T> : Sequence<T>
> ПК>{
> ПК>   T operator[](int index);
> ПК>   Pos pos_by_index(int index);
> ПК>};
>
> ПК>class List<T> : Sequence<T>
> ПК>{
> ПК>};
>
> ПК>class Array<T> : RandomAccessibleSequence<T>
> ПК>{
> ПК>};
> ПК>

>
> ПК>Итак, мы хотим иметь возможность эти контейнеры сортировать. Допустим, мы решили добавить метод sort() в интерфейс Sequence<>.
>
> Не ожидал от тебя столько детский ошибок в таком простом варианте.

Зато я ожидал различных эпитетов меня и моих действий

> В описанной выше иерархии имеется класс RandomAccessibleSequence — это подразумевает, что ее предок не должен иметь средств прямого доступа к последовательности, а значит методы:
>

> Pos next(Pos);
> Pos insert(Pos, T);
> void remove(Pos);
>

> не имеют права находиться в этом классе.

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

> Более того. Под большим вопросом находится целесообразность размещения в последовательности методов:
>

> uint size();
> bool is_empty();
> Pos begin();
> Pos end();
>

> так как они, например, не дают работать с последовательностями читаемыми по сети.

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

> В общем, реализуют идиому последовательности с последовательным чтением грязно. Стало быть, довольно странно будет и применение к ней сортировки. <...> для классической последовательности с последовательным чтением метод сортировки вообще является нонсенсом.

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

> Правильным дизайном <...>

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

> Однако даже в таком виде это шедевр ОО-дизайна по сравнению с СТЛ которую ты тут защищаешь.

Повторю: речь шла о библиотеке языка Java, и о том, где в ней находится функция сортировки массивов. Никакого отношения к STL это не имеет.

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

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

> ПК> Кроме того, есть ли уверенность, что для всех "последовательностей" существуют эффективные методы их сортировки с сохранением порядка "одинаковых" с точки зрения упорядочивания элементов?
>
> [i]Паша, наделав таких детских ошибок в проектировании иерархии классов, ты задаешься столь не детскими вопросами. Может они не спроста сделаны? [/q]

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

> Более того еще большой вопрос нужно ли вводить метод сортировки в последовательность не обеспечивающую прямой доступ.

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

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

Поэтому существует такая вещь, как Design by contract, подобные трюки запрещающая, а также давным давно сформулирован Open-Closed Principle, который уже упоминался. Судя по всему ты так и не удосужился с ним ознакомиться. А гласит он, что в частности классы по возможности следует проектировать так, чтобы в дальнейшем их не модифицировать, а только расширять поведение, пользуясь их интерфейсом, наследованием и добавлением новых сущностей, с данными классами взаимодействующими.

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

> максимум что мы получим — это варнинг (в Шарпе и ничего в C++), который успешно уберем за пару минут.

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

> Реализовав подобные методы как статические ты так же можешь нарваться на перекрытие.

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

> ПК>Выход простой: тем или иным образом вынести эти "утилиты" за пределы самих классов. <...>

> Вывод неверный. Думаю, мои комментарии это хорошо продемонстрировали.

Твои комментарии если что и продемонстрировали, то совсем не это.

> При создании методов нужно соблюдать принципы: инкапсуляции, полиморфизма

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Я неоднократно указывал на то что обероны, еще со времен Модулы, являются модульными языками. Но тут, видимо, никто не понимает что это такое. Вот и Вы тоже туда же. Не понимаете в чем состоит преимущество модульности... С модулями не возникает проблем контроля версий. Новому модулю дается новое имя (так же как с COM-интерфейсами). В конце концов, модуль — маленький. 1-модуль : 1-программист. Несколько программистов в один и тот же модуль код никогда не пишут.

Круто.... Меня эти откровения так втыкают

Здравствуйте, Сергей Губанов, Вы писали:

К>>Значит, ты мало трахался с системами контроля версий.

СГ>Я неоднократно указывал на то что обероны, еще со времен Модулы, являются модульными языками. Но тут, видимо, никто не понимает что это такое. Вот и Вы тоже туда же. Не понимаете в чем состоит преимущество модульности... С модулями не возникает проблем контроля версий. Новому модулю дается новое имя (так же как с COM-интерфейсами). В конце концов, модуль — маленький. 1-модуль : 1-программист. Несколько программистов в один и тот же модуль код никогда не пишут.

"Remember: one shot, one body!"

Во-первых, такой подход называется "выкрасил и выбросил". Даже самые маленькие файлы нуждаются в контроле версий. Если ты думаешь иначе — значит, действительно, не имел практики сопровождения проектов.

Потом, вот захотел ты вместо модуля A пользоваться его обновлением.
1)Пришлось переименовать его на B.
2)Значит, всюду, где это требуется (наверное, не всюду-всюду-всюду, а только в отдельных модулях) поправил import A на import B.
3)Прекрасно! Модули маленькие, поэтому количество таких поправок будет преизрядным. Ты это всё в голове будешь держать? Нет? — значит, берём систему контроля версий... Чтобы через два дня не забыть, где что расковырял.
4)Далее всплывает один очень неприятный момент. Пусть в этом изменённом модуле был класс C. Его полностью квалифицированное имя — это A.C, но благодаря директиве import мы вводим алиас C в пространства имён тех модулей, где это было прописано. И вот в одном модуле (D) мы написали import B, а в другом (E) забыли и оставили import A.
Теперь алиасу C соответствуют B.C и A.C. Если модули D и E что-то экспортируют друг другу с использованием класса C, то программа внезапно перестаёт компилироваться.

Вот ты и получил library hell. Он не так страшен, как DLL hell, когда программы начинают валиться на ровном месте. Просто не компилируются.

Но посмотри, как это сделано в .Net — система нумерации версий приводит, в общем-то, к тому же самому, но полностью подконтрольно, во-первых, и гораздо менее трудоёмко, во-вторых.

А твои мысли про COM — тут даже комментировать нечего.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>VladD2:

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

>> Нет, Паша, именно это ты и предлагаешь.

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

И что в этом есть проблемы? Первым делом для доказательства кривости этого решения ты полез обсуждать базовые интерфейсы (видимо причислил Array к ним). А потом согласился почти со всеми утверждениями аппонентов.

ПК> К тому же, если посмотреть на историю ветки, то можно увидеть, что я ничего не предлагал.

Да, да... конечно. Ты с таким умным видом гуру ОО-проектирования вещал детям о грамотном дизайне.

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

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

ПК>Где именно я "переворачиваю весь ООП вверх ногами"?

Да во всех начальных поставх.

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

Ну, это дешевый наезд. Даже реагировать не хочется.

ПК>Так и запишем: по существу тебе сказать особенно нечего.

Гы-гы. Чья бы корова мычала.

Здравствуйте, Павел Кузнецов, Вы писали:

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

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

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

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

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

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

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

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

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

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

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

ПК>Этот примерчик совсем в другую сторону,

Гы-гы. В ту, в ту.

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

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

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

ПК>В случае сортировки никакие инварианты класса Array не нарушаются.

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

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

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

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

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


ЗЫ

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