maXmoпро кирпич, имхо подразумевалось следующее: если строишь дом из кирпичей, то их можно ложить друг на друга, а можно по спирали (в этом случае всё развалится),
Отнюдь. Недалено от меня есть весь из себя закругленный в завитках кирпичный дом.

maXmo а если ты строишь панельный дом, вероятность напортачить снижается.
Отнюдь :))

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

maXmoкстати, интересная штука с протектедом. Вот, скажем, определяем мы метод протектедом. Другой прогер берёт, наследует наш класс и зеркалит протектед методы с свои паблик. Просто тупо зеркалит. И смысл тогда в протектеде?
Все нормально. Тот, другой прог принимает ответственное решение. Он отвечает за то, что этот метод входит в интерфейс его класса, безопасен итп. Вполне возможно, для его потомка - более узкого класса - это нормально и правильно, в то время как для широкого базового - недопустимо. Возможно, он не просто публикует, а снабжает дополнительными проверками. Итп. Это уже его зона ответственности; в том числе если через этот метод сломают работу его объекта, бить будут именно его.

maXmo softwarerесли через этот метод сломают работу его объекта, бить будут именно его.это тоже часть идеологии ооп?
Именно. ООП - прямое развитие концепции модульного программирования, где собственно и была выдвинута мысль об отделении интерфейса от реализации и в том числе об ответственности каждого за свой модуль (и свободе выбирать/менять его реализацию) при сохранении заранее спроектированного интерфейса взаимодействия.

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

maXmoприходится постоянно много всего помнить и много за чем следить
Не хотелось бы соглашаться.

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

Если подход не обеспечивает - неизбежно (имхо) будет выстроено "перманентно разваливающееся приложение". Цитируя одного из экс-коллег - "За последний год мы ни разу не смогли сделать серьезное изменение, ничего при этом не сломав". Я помню несколько случаев, когда приходилось тратить кучу времени на отлов очень неочевидных проблем, возникавших на стыке нескольких "и так сойдет" решений.

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

Аналогия со строительством тут получается достаточно условной, но: если Ваша задача - сложить избу-пятистенку (прямоугольник со внутренней стеной), то спроектировать ее строительство из кирпича будет легче, нежели из бревен.

NotGonnaGetUsМежду строительством домика и складыванием кубиков программистами есть существенная разница. Каменщик не может сложить из 5 кирпичей блок и дальше использовать только его, а программист может.
Если программист так поступит, и это окажется уместным - он именно что "найдет удачный стройматериал", как я и предлагаю.

Мало того, каменщик тоже может. Один из вариантов такого блока и называется панелью ;)

NotGonnaGetUsПоэтому черезмерное дробление не представляет фатальной проблемы.
Фатальной - нет. Но представьте себе, что каждый дом нужно начинать со сборки кирпича из крошек, и только потом этот кирпич можно будет использовать....

Не думаю, что Вам понравится такая технология. Полагаю, Вам сразу захочется собрать кирпич один раз и использовать его во всех проектах.

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

NotGonnaGetUsт.к. приёмы принятые в различных коммунити различаются.
Я не думаю, что "правильность" определяется "принятым в данном коммьюнити". Максимум, что этим определяется - "читаемость" кода; это не единственный критерий качества.

NotGonnaGetUsИнтерфейс включает в себя пред и пост условия методов, инварианты класса, ограничения на возможные значения параметров методов и полей класса.
И методы проверяют эти условия-ограничения, выкидывая исключения. Все корректно.

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

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

NotGonnaGetUsЕсли программист начинает делать с компонентом что-то, что не описывается в интерфейсе, он использует компонент _неправильно_.
Сценарий использования не входит в интерфейс хорошего кубика. Хотя, разумеется, полезна информация вида "если хотите получить А, не забудьте в какой-то момент сделать Б".

NotGonnaGetUs softwarerИ хотя Вы можете полагать, что из него правильно складывать дома, на самом деле его ничуть не хуже можно использовать как гнет для квашенья капусты.
Отрицаю Такой Подход.
Значит, остается мало тем для разговора.

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

NotGonnaGetUsРазарботка "простого" кода и "универсального" требует существенно разного вклада труда и времени.
Нет. Разработка универсального кода требует более высокого уровня разработчика при мало отличающихся затратах времени.

NotGonnaGetUsинтерфейс таблицы это все её поля + констрейнты на эти поля.

Сокрытие данных и построение эффективных sql запросов вступают друг с другом в конфликт. Так?
Давайте посмотрим аналогию этого в традиционном ООП.

Допустим, у Вас есть интерфейс "контейнер" и два варианта его реализации; один с O(n) добавлением и O(log n) поиском, другой O(1)/O(n) соответственно. Есть некий код, использующий контейнер. В зависимости от специфики его операций Вы выбираете ту или другую реализацию. И где здесь нарушение инкапсуляции?

NotGonnaGetUs softwarerНу, это всего лишь дружественность, которую, с моей точки зрения, стоило бы выбросить и из дельфы, и из явы, и из плюсов.
Т.е. это было плохое желание и видимость должны быть только public и private?
Ээ... я, кажется, просил выбросить дружественность, а не protected.

NotGonnaGetUsКак обычно, искалось решение минимизирующее наведённые ошибки и время на реализацию.

Я согласен, "идеалогически верный паттерновый вариант" более качественное решение, но вопрос был не в этом.

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

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

NotGonnaGetUsЯ, в свою очередь, не понимю зачем ограничиваться только этим вариантом.
Потому что это как минимум будет другой паттерн. И я его не то чтобы понимаю.

NotGonnaGetUsСуть паттерна - использовать для выбора "алгоритма" полиморфизм
Безусловно. Полиморфизм - то есть виртуальные методы - это открытая часть объекта, интерфейс. Или мы о виртуальных приватных методах? :)

NotGonnaGetUsвместо условных операторов. C какими данными будет работать алгоритм, закрытыми или открытыми, уже не важно.
Как раз важно. Если алгоритм пытается работать с закрытыми данными - значит, в нем не удастся обойтись без условного оператора типа "если класс X, то берем его закрытое данное Y, иначе Z".

Почему: потому что реализация может быть изменена. Даже если в далеком потомке Xn есть данное Y - не факт, что оно используется; возможно, что оно тупо унаследовано, а реализация давно опирается на Yn. То есть алгоритм, паттерн "Стратегия" теряет свою универсальность, теряет возможность работать с произвольным подставляемым потомком.

NotGonnaGetUsСтратегия это метод превращённый в объект.
Допустим. Хотя это несколько отдает в философию.

NotGonnaGetUsТак же как метод - часть класса, так же и стратегия - часть класса.
Нет, не так же. Стратегия - это обобщенный алгоритм, метод - максимум конкретная реализация обобщенного алгоритма.

Давайте снова посмотрим на стратегию "Сортировка". Ее можно применить очень много к чему; это не есть, допустим, "часть класса ResultSet" или "часть класса DefaultListModel".

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

NotGonnaGetUsЯ использовал слова "один правильный класс" для обозначения этой связности, не более того.
Хм. С этой точки зрения любая программа является "одним правильным классом".

NotGonnaGetUsПрограммист может создавать материалы под себя и использовать без повторного процесса сборки.
И? Вы повторили ровно то же, что я сказал в том, на что Вы отвечаете. Не понял, что из этого следует.

NotGonnaGetUsЕсли в комментарии к методу написано "проверь ограничения прежде чем меня дёргать", то метод НИЧЕГО НИКОМУ не должен.
Даже если в комментарии ничего не написано, метод тоже НИЧЕГО НИКОМУ НЕ ДОЛЖЕН.

Вопрос ровно в одном - хороший ли это метод, класс итп. И тут существует простая аналогия: с "Вашей" точки зрения в документации к программе можно написать "не надо нажимать кнопку X в ситуации Y" - и если пользователь таки нажмет ее, программа НИЧЕГО НИКОМУ НЕ ДОЛЖНА.

Я согласен с тем, что такая постановка вопроса в принципе имеет право на существование. Но она - неудобна. И я (да и не только я) полагаю, что ХОРОШАЯ программа ДОЛЖНА обрабатывать ошибки и в целом создавать пользователю максимально простой и удобный контекст работы.

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

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

NotGonnaGetUsНу и хрен с этими параметрами, если код будет работать,
Безусловно. Просто это уже не класс в его нормальном смысле. Это частный случай сомнительной разумности.

NotGonnaGetUs softwarer
Сценарий использования не входит в интерфейс хорошего кубика.
В интерфейс входит всё, что не обходимо для корректной работы с компонентом. Интерфейс может быть _не удобным_, но это уже абсолютно другая тема для разговора: "как сделать интерфейс удобным".
Вы случайно не обратили внимания на слово "хорошего"?

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

NotGonnaGetUs softwarerДавайте посмотрим аналогию этого в традиционном ООП.
Я разве просил привести аналогию?
Я предлагаю Вам ее посмотреть. Этого мало?

NotGonnaGetUsНу объясните же мне, глупому, что такое дружественность?
"Черный ход", благодаря которому можно получить доступ к закрытой информации неродственного класса. В C++ можно явно объявить классы дружественными, после чего они получают возможность лазить друг другу в приват. В дельфе для этого нужно описать классы в одном файле, в яве - в одном пакете.

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

NotGonnaGetUs softwarer
Иначе говоря, Вы ставите в упрек ппп то, что в нем нельзя "очень хорошо" сделать "не очень хорошее решение". Согласитесь, это выглядит почти комплиментом в его адрес :)

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

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

Только не надо предлагать всё засунуть в один пакет.
ППП тут совершенно не при чем. Я не понимаю, нафига может потребоваться описанная конструкция, но если нужна - это претензия к отсутствию в языке понятия "приватного пакета". Да, нет такого. По мне - так и хорошо, что нет. Но в любом случае "классовые" ппп тут ни к селу, ни к городу.

NotGonnaGetUsЕрунда. Где этот условный оператор в примере выше?
Там же, где работа с чужими скрытыми данными.

NotGonnaGetUs softwarerТо есть алгоритм, паттерн "Стратегия" теряет свою универсальность, теряет возможность работать с произвольным подставляемым потомком.

C чего ради деталь реализации должнать обладать мистической универсальностью, простирающейся за границы реализации?
Хм. "На предыдущем допросе" (с) Вы сказали, что суть этого паттерна - в использовании полиморфизма для выбора реализации.

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

NotGonnaGetUsТак же как метод - часть класса, так же и стратегия - часть класса.

Обобщённый алгоритм - это template method. Никто не мешает скрестить Strategy и Template method, для того чтобы осуществлять выбор конкретного template method'a не условными операторами, а за счёт полиморфизма, но почему это должно быть единственным способом использовать паттерн strategy?
Хм. Чтобы сократить объем: даже если это "не единственный" метод, первое процитированное здесь утверждение - на которое я отвечал - уже не верно. Поскольку существует контрпример.

NotGonnaGetUs softwarer
"Связаны" вовсе не обязательно значит "лазают друг другу в приват".

"Связаны" вовсе не обязательно значит "не лазают друг другу в приват".
Безусловно. "Не лазают друг к другу в приват" - означает "нормально спроектированные классы", не более того.

NotGonnaGetUsПаттерны ООП, в частности strategy, command, visitor, composite приводят к сильному связыванию, но им это не ставится в вину, т.к. они решают технические задачи, которые не возможно решить стандартными средствами, не ударившись в жёсткий copy-past.
Пока что это как минимум бездоказательное утверждение.

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

NotGonnaGetUs"один правильный класс" это набор таких сильно связаных классов.
OK, терминология принимается.

NotGonnaGetUsЭ... В таком случае, вы повторили ровно тоже, что я сказал, перед тем как вы сказали то, на что я отвечаю :)
Не совсем, если не совсем не. Вы сказали:

Между строительством домика и складыванием кубиков программистами есть существенная разница. Каменщик не может сложить из 5 кирпичей блок и дальше использовать только его, а программист может.

Я возразил: сказал, что разницы нет, и панель - как раз такой вот "заранее сложенный каменщиком кубик", который он использует. Вы по сути проигнорировали это возражение, снова сказав "молдавские строители оценили бы, что программист может использовать свои материалы". Я выделил из этого "программист может использовать" и указал, что это не содержит новой мысли :) Спор о том, использует ли новые материалы каменщик, предлагаю не развивать как сильно оффтопичный и ненужный.

NotGonnaGetUsНе удобна не постановка вопроса, а интерфейс компонента.
Постановка вопроса - "хороший кубик". Поставлена она, если мне не изменяет память, мной. В "мой хороший кубик" "хороший интерфейс" входит, и является одним из двух-трех важнейших факторов.

NotGonnaGetUsА что такое класс в нормальном смысле?
Я думал, что класс это то, что начинется со слов "class Name {" :)
Со слов "class Name {" может начинаться любая хрень К примеру,


NotGonnaGetUs softwarerВы случайно не обратили внимания на слово "хорошего"?
Это слово отражает объективную характеристику класса или субъективную?
Если субъективную, к каковым относится и удобство, то не вижу смысла обращать на него внимание.
Хм. Я не очень понимаю, зачем Вам разговаривать со мной, если Вы при этом предпочитаете не обращать внимания на мой слова.

В этом случае я бы предпочел, чтобы Вы адресовали свои монологи в пространство, не отвлечая меня.

NotGonnaGetUsКак раз это лирика + отдельная тема.
Безусловно. И поэтому я предлагаю не тратить на "плохие интерфейсы" время.

NotGonnaGetUsПосмотрел. Инкапсуляция не нарушается.

Позволю себе вставить в это месте последнюю версию Вашего ответа.

NotGonnaGetUsСитуация, когда разработчик выбирает между, скажем, ArrayList и LinkedList не содержит в себе ничего противозаконного. "Противозаконное" начинается, когда выбрав подходящий для себя вараинт, он делает каст в List и дальше обращается с коллекцией через этот интерфейс. Противозанонность заключена в том, что он сам должен контролировать, что в переменной типа List не окажется лист не того вида.
Я скорее не согласен с такой постановкой вопроса. Соображение резонно, но в определенном контексте - если предположить, что некоторое решение, например ArrayList, заведомо лучше и является единственным возможным вариантом. Есть другой контекст, когда выбор реализации диктуется не нами, а тем, кто пользуется нашим решением - скажем, тот же класс "сортировщик" должен работать через List, в то время как пользователь нашего класса - выбирать реализацию исходя из своих данных и своих задач.

Если помните, мы пришли к этому примеру от БД. Что у нас есть в случае БД?

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

Что из этого следует: из этого следует, что в какой-то момент может потребоваться (для решения вновь поставленной задачи) изменить реализацию данных, например сделать из обычной таблицы партиционированную. И если от этого изменения "накроются" все другие методы, работающие с этой таблицей.... Что Вы там говорили про сильно связанные программы? Именно тот случай. И альтернативы "использованию List" в данном случае имхо нет.

NotGonnaGetUsВ java файлы из одного пакета не будут лазить друг другу в приват.
Да. Но тем не менее, это практически та же дружественность, со всеми ее минусами. Если угодно, можно считать "чуть менее страшная".

NotGonnaGetUsЯ выявил желание определить компонент класса доступным _только_ в нём и его наследниках и оказалось, что это не возможно.
Вы сослались на дружественность, что звучит фактически как приговор: моё желание плохой дизайн.
Ровно наоборот, и это явно указано. Я сказал, что с моей точки зрения концепцию дружественности следует выкинуть к чертям собачьим. В дельфе и в яве я вообще не знаю ни одного примера правильного желания, в котором нужна дружественность; это костыль для скрепления плохого проектирования. В плюсах есть один пример хорошего желания, который язык не дает реализовать иначе, чем дружественностью. Имхо, из этого следует "выкинуть дружественность, реализацию желания сделать возможной другим способом".

Названное Вами желание с моей точки зрения разумно и правильно.

NotGonnaGetUsНет. Мне нравится вариант предложенный Мейером и реализованный в Eiffel.
Видимости связанной с пакетами не существует. Компонент может быть видим всем, никому или наследникам кого-то
Не знаю Eiffel, но в сказанном наши вкусы полностью совпадают.

NotGonnaGetUs(при этом наследник может отказаться от наследства и никто не сможет его после этого прикастить к предку).
Смысла вот этого я не понимаю. Есть подозрение, что такое желание есть следствие желания применить наследование как замену включению. Впрочем, это отдельная и наверное не столь важная тема.

NotGonnaGetUsКак только появляется модификатор видимости связанный с пакетом (т.е. protected и default в java), пакет становится одним из действующих лиц в борьбе за обеспечение инкапсуляции.
Хм. Я не хочу комментировать эту фразу - имхо она не очень относится к сказанному мной. Просто еще раз, аккуратнее сформулирую:

С моей точки зрения, приведенный Вами пример (если предположить, что такой дизайн зачем-то нужен - я смысла в этом не вижу) никак не относится к модификаторам видимости членов класса (то, о чем идет речь в топике). На самом деле он требует введения в язык модификатора видимости пакета [то есть что-то типа protected package] либо доработки модификаторов видимости класса в целом. .

NotGonnaGetUsЯ уже упоминал о видимых, но не публикуемых компонентах. В любой библиотеке найдутся "недокументированные возможности", все те детали реализации, что неудаётся скрыть, используя стандартные механизмы. Примером могут служить пакеты sun.*/com.* в jdk.
Я уже достаточно отошел от java, чтобы не суметь поддержать дискуссию о конкретных решениях в ее библиотеке. Могу сказать так: мне ни разу в жизни не приходилось делать такие вот "вынужденно открытые" решения. Каждый раз, когда я натыкался на чье-либо желание такого решения, оказывалось, что причина его кроется в недостаточной продуманности, плохом дизайне предыдущих решений. Исходя из этого я склонен и неизвестные мне "неудается скрыть" предполагать относящимися к этой категории.

NotGonnaGetUsРабота с чужими данными в вызовах методов yyy и zzz.
Где? Они, я так надеюсь, работают со своими собственными данными каждый. То, что эти данные - чужие для того megaMethod, который метод, имхо по барабану всем, включая его самого.

NotGonnaGetUs(В примере оказались пропущены extends MegaMethod и не обзначен тот факт, что эти классы обхявлены внутри класса-контекста, хотя полагаю это и так понятно)
Хм. И с чьими все-таки закрытыми данными они работают? Контекста? А зачем им это?

NotGonnaGetUsУ полиморфизма нет смысла. Полиморфизм это природное явление
Протестую. Полиморфизм придумали люди, для решения вполне определенных задач. Говорить "сделано ради полиморфизма" и при этом отбрасывать эти задачи.... можно, конечно. И тогда становится неудивительной претензия "имеющиеся механизмы не подходят". Это все равно, что жаловаться "лыжи не катят", стоя на лестнице.

NotGonnaGetUsЭто утверждение использовалось в том же контексте, в котором использовались слова "один правильный класс". С этой метафорой вы согласились, какие проблемы вызывает эта?
Я привел пример. Сортировка - точно не является частью конкретного класса. Либо мы считаем ее размазанной по куче самых разных классов, либо - что имхо правильнее - считаем ее отдельной сущностью, применимой к разным классам.

NotGonnaGetUsВ чём его бездоказательность?
В отсутствии доказательств :) Сделано сомнительное утверждение, скорее несколько утверждений, и они не обоснованы. По ходу предыдущей дискуссии попытка дать пример такого обоснования... пока не очень успешна, во всяком случае единственный пример был опровергнут.

NotGonnaGetUsДопустим у вас стратегия с десятью методами и 256 вызовами этих методов.
Отказавшись от данного паттерна вы получите 256 строчек подобного вида
if () {...} else if () {...} ... ,
Хм. Знаете, "страшные if-ы" по моим ощущениям давно стали некоторой страшилкой, которую повторяют на все лады, не особо думая о смысле.

Я готов показать, что даже при использовании Fortran IV (который, назовем так, небогат языковыми возможностями, и в том числе не содержит классов) эту задачу можно решить без подобных case-ов. И?

Да, в принципе можно считать любую реализацию "без if-ов" более или менее изуродованным вариантом этого паттерна. Мало того, это часто правильно; к сожалению, очень часто молодые программисты не понимают, что видят перед собой очередную перелицовку проверенных, выведенных из давнего опыта подходов, и считают их революцией, которая спасет мир (и которая позволяет писать как угодно плохо - главное, чтобы звучали слова Strategy, Visitor и прочие).

Однако, эта философия имхо не относится к случаю обоснования либо необоснования конкретного утверждения.


NotGonnaGetUsК чему приводит такое дублирование всем известно. Это объективный недочёт
Хм. Он настолько же объективен, насколько объективен "хороший интерфейс". Однако, тот Вы ранее назвали субъективным.

NotGonnaGetUsТаким образом, с фактом ограниченности ппп и тем, что это не фатальная проблема согласны мы оба (хоть и по разным причинам).
Это не совсем та формулировка, которая меня устраивает.

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

NotGonnaGetUsНикто в здравом уме не станет заменять классы на бины с public геттерами и сеттерами и создавать классы со статическими утильными методами (хотя есть и такие примеры реализации ORM :)), но в бд именно это и имеет место, потому что за счёт этого покупается возможность писать эффективные запросы.
Хм. Боюсь, я вроде как знаю все слова, но вот полностью понять смысл фразы не смог. Нельзя ли объяснить более доступно?

NotGonnaGetUsС каждым листом связан итератор позволяющий перебирать его элементы наиболее эффективным способом.

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

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

Соответственно, если у нас есть, условно говоря, классы "Эффективно Сортируемый Список" и "Неэффективно Сортируемый Список", хороший сортировщик таки должен уметь работать с обоими. В противном случае для сортировки семи строк комбобокса мне придется делать что-нибудь типа


что вряд ли "хорошо".

NotGonnaGetUsЕсли слово "сортировщик" заменить на другое (которому не достаточно итератора), то получится "плохой" дизайн
Я бы не стал утверждать столь однозначно.

NotGonnaGetUsЭто от желания наследовать реализацию, а не интерфейс.
Примерно это я и имел в виду в своей формулировке. Аналог private наследования.

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

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

NotGonnaGetUsи не может обеспечить всё тоже самое, что и наследование (доступ к protected компонентам предка).
Ну, это-то элементарно обходится созданием публикующего нужные вещи потомка.

NotGonnaGetUsПри необходимости сделать какой-то член класса видимым в классе из другого пакета нужно сделать его public, при этом возникает side эффект в виде видимости для всех классов, всех пакетов.
Да. Я поэтому упомянул и дружественность, и protected; фактически Вы хотите нечто типа


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

NotGonnaGetUsТак вЫшло.

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

NotGonnaGetUs private abstract class (or interface) S { abstract int eval(); }
?

NotGonnaGetUs softwarer
Протестую. Полиморфизм придумали люди, для решения вполне определенных задач. ......

Полиморфизм это один из механизмов реализованных в ОО языках.
Кто и как его использует зависит от фантазии.
Верно. Но если используешь его "от фантазии", неуместно критиковать его за то, что он "не подходит".

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

NotGonnaGetUsЯ не вижу смысла в измывании над этим высказыванием.
OK.

NotGonnaGetUsОчень трудно доказывать очевидное :)
Но надо :)

NotGonnaGetUsКакой пример? Не заметил опровержения.
С undo-контейнером.

NotGonnaGetUsМне тоже интересно, какой из этого факта нужно сделать "И?".
Следующий: не нужно по каждому случаю обсуждения ООП вспоминать про "страшные if-ы". Это такая же страшилка, как goto в структурном программировании.

NotGonnaGetUsПроверенные и выведенные из опыта подходы родили ООП, шаблоны GRASP и GoF, как средства позволяющие их использовать.
Уходить в прошлое и смотреть как эти подходы когда-то пытались реализовывать, интересно только с научно-позновательной точнки зрения.
Хотелось бы согласиться, но к сожалению не получится.

Специфика моего жизненного опыта в том, что я встречал много людей, способных сказать довольно много умных слов на модные темы, но при этом не понимающих сути того, о чем говорят и что страшнее - что вроде бы используют в работе. Скажем, лет дцать назад, когда паттернов еще не было, а модной темой был C++, я беседовал с одним юношей, который влез в тему сверхстандартного учебного задания на полиморфизм - класс "фигура" с наследниками "круг", "квадрат" итп - и начал рассказывать, что все надо делать на template-ах, поскольку только они способны решить эту задачу. В ходе беседы до меня постепенно дошло, что человек просто не понимает классов, для него это скорее записи - благо, если помните, в C++ class и struct весьма похожи.

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

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

NotGonnaGetUsПытаться найти и исправить фрагмент логики дублирующийся в 256 местах объективно сложнее, чем сделать исправление в одном единственном месте.
Точно так же, например, "вызвать 256 методов в единственно правильном порядке" объективно сложнее, чем вызвать их в произвольном порядке.

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