KachalovПрограммист с ООП мышлением в Вашем искуственном примере первым делом бы завел поле:
и вокруг него бы выстраивал методы. То что получилось у Вас это не ООП, а пародия на него.

О, давайте вы, как программист с ООП мышлением, покажите где будет заведено это поле, какие методы с ним будут работать и т.д.

Плз.


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

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

Попробуйте читать то, что я пишу.

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

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

Самый лучший вариант ООП + функциональное программирование так, как это сделано в nemerle.

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

Kachalov
- не забывайте про полиморфизм, который поможет адаптировать методы под изменение задачи

Какже я его забуду, он мне по ночам только не снится :)

Полиморфизм не бесплатная штука. Любое использование полиморфизма приводит к появлению нового класса наследника, а цепочки наследований приводят к коду изменять, который в некоторых случаях существенно труднее, чем "лапшу" из if-else.


Если вам всё кажется таким солнечным, сделайте то, что я прошу. Не одному мне, думаю, будет интересно увидеть "ООП в действии".

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

1.

a. Сообщения, которые выводятся на экран должны совпадать с теми, что присутствуют в исходном коде. В общем случае эти сообщения произвольные, т.к. мнения о том, что good или bad у разных людей разные.
Т.е. универсального toString() сделать нельзя.

b. Алгоритм определения типа OS в вашем варианте не работает, т.к. ни одна из версий windows не идентифицируется как osName == "windows".

Если учесть это, что ваш варинт будет таким:


2. Проблемы:

а. Нет возможности расширить класс OS поведением специфичным для конкретной операционной системы. Н-р, для windows имеет смысл метод "получить реестр", а для unix или unknown - нет.
Т.е. в нём недостаточно гибкости.

b. Добавление нового типа OS потребует изменения в коде класса OS.
Нарушение OCP.

Общий вывод: требуется рефакторинг "замена переменной типа наследованием или стратегией" (либо наследуем Unix -> OS, либо добавляем в OS поле Type и реализуем Type <- Unix).

с. Класс OS содержит методы c низкой степенью сцепления. Попытки добавления новых методов для работы с OS только усугубят ситуацию. Н-р, есть две группы методов (findByName, isWindows и isLinix) и (getName, getMessage) явно решающих не связные друг с другом задачи. Поэтому нужно выделить первую группу методов в класс OSFactory.

d. Класс OS обладает информацией о всех своих "подтипах". Это проблема, т.к. постоянно появляются новые версии OS, что приведёт к необходимости изменений в классе OS.
Если бы набор OS был фиксирован раз и на всегда, то можно было бы обойтись использованием простого enum'a.

e. Метод getMessage находится не на своём "месте". Пожелания всех желающих засунуть в (полу)библиотечный класс не выйдет. Нужен механизм позволяющий каждому клиенту расширять поведение класса не прибегая к его модификации (опять OCP).

...

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

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

NotGonnaGetUs

Опечатка :)

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

NotGonnaGetUsОднако операции с "товаром" могут то исчезать, то появляться.
Какие такие операции? Мне просто интересно может я чего нить не понимаю ...


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

Операции == действия над объектами/данными.
Н-р, вчера нужно было напечатать в консоль, что "This is a UNIX box and therefore good.", а сегодня версию OS и тип файловой системы. Объект один и тот же - "OS", а представить его ввиде классов/данных можно очень по разному (и сильно потом жалеть).

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

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

А я давно заметил, что написание программ очень смахивает на работу с MS Word, т.е. эдакое набирание буковок на клавиатуре.

Правда, мы с тобой "зрим в корень", а все остальные ничего в этой жизни не понимают?

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

заранее сапсибо


А вы почитайте это сообщение .
Там есть п.1 и п.2.
Если согласны с п.1., то переходим к п.2 про проблемы (не знаю как можно не согласиться с п.1.)

Если в пунктах a/b/c/d/e что-то не понятно, то зацитируйте и задайте вопрос об этом.

Или можете повторить опыт Kachalov'a и показать нам, что ваш моск советует сделать с исходным кодом (тем, где всего один метод main), чтобы он стал "чиста" объекто ориентированным, а не процедурным.


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

1. Если злоупотреблять ООП, т.е. порождать классы при декомпозиции поведния объектов выведенных из предметной области, изменения в коде будет делать так же сложно, как если бы весь код был насквозь процедурным.
2. ООП со статической типизацией (и без вывода типов) приводит к большему количеству кода (в строчках) и к более сложным решениям (количество объектов и связей между ними), чем ООП с динамической типизацией.
3. Хороший ООЯ должен сочетать не ООП + процедурное программирование, а ООП + функциональное программирование.
4. Останавливаться нужно на самом простом решении из возможных, но при этом оставлять возможности для будущих рефакторингов (чтобы при необходимости можно было легко получить более "правильное" решение).
5. "Естественные" понятия, которые проблематично описать фиксированным набором "свойств", представить "универсальным" классом практически невозможно. Конкретное задачи потребуют разные классы. Откуда следует вывод, что применимость ООП достаточно ограничена и рассматривать его как "мышление" можно только с натяжкой.

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

expp
ловим


Полную имплементацию плз (вместе с инициализаций descisionTable и т.п.), чтобы между нами не вышло не понимания.

А пока могу констатировать только то, что таблица выбора - это паттерн процедурного/структурного программирования и прикрученный к map'е
класс OsDesc* просто лишний.
Достаточно иметь проинициализированный map.

Сравниваем:

Практически никаких _потенциальных_ проблем исходного решения ваше решение не решает и добавляет новые.
Так при изменении условий проверок, н-р, с (osName.equals("Windows NT") || ...) на (osName.toLowerCase().startWith("win")) таблицу придётся целиком выкинуть.

expp
а если херакнуть молотком по пальцу ... не злоупотребляйте им. <<хороших>> молотков не бывает.

Тоже любите боянить? :)

Говоря "не злоупотребляйте", вы соглашаетесь с невозможность применять объекто-ориентированный подход на всех этапах написания кода. А это равнозначно признанию в том, что данный подход не является универсальным и достаточно полным. Если это так, то ни о каком оо-мышлении говорить нельзя. А вы, кажется, с этим не хотите соглашаться? )


expp
NotGonnaGetUs
2. ООП со статической типизацией (и без вывода типов) приводит к большему количеству кода (в строчках) и к более сложным решениям (количество объектов и связей между ними), чем ООП с динамической типизацией.
просматривая подобные объёмы кода я как правило вспоминаю "обезъяну с гранатой". динамические языки верный способ отстрела собственных ног.

И тем не менее факт на лицо: кода получается меньше :)

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

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

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

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

Что с чем и как скрещивать иллюстрирует язык nemerle.

exppв том то и прикол что если мысль есть то занимает она две строки от силы...
мой код вы поняли более чем верно.

Прикол в том, что такая таблица приведёт к существенно большему дублированию кода, чем несколько в if-else, если нам потребуется в каком-то месте вывести чуть другие сообщения.
Так же точно потребуется вносить много изменений в уже написанные код, если нужно будет получать не строку в зависимости от типа ОС, а какую-то специфичную для данной ОС информацию.
И т.д. и т.п. (много буков)

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

И вы это похоже прекрасно понимаете :) Тогда я не понимаю к чему были ваши слова "голимая крамола".


expp
NotGonnaGetUsА пока могу констатировать только то, что таблица выбора - это паттерн процедурного/структурного программирования и прикрученный к map'е
ООП вообще паттерн процедурного/структурного программирования.

И чего? Вместо полиморфизма будет использовать опять таблицы, а вместо классов структуры или массивы с дикриминаторами? И зачем?

expp
да ни в жисть - уметь надо и всё

Трухлявый бояян. Умеете - покажите. Не умеете - не говорите.

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


expp
NotGonnaGetUsИ тем не менее факт на лицо: кода получается меньше :) ассемблер вот язык достойный лаконичного мужа.

Разве на ассемблере получается коротко? Мы вроде как не размер бинарников сравниваем...


expp
Лапшу из if ов я просто не навижу авторов её предаю разнузданному геноциду

Геноцид заключается в том, что авторов заставляют переписывать всё на таблицы? :)


expp
вы пробовали ? лично я использовал Drools. впечатления нормальные

Drools/Groovy/etc это не java. Это другие языки.
Писать тела методов java классов на них не получится.

expp
NotGonnaGetUsnemerle. с возрастом это проходит

Что именно? Желание иметь лямбды, паттерн матчинг, вывод типов и прочии конструкции позволяющие писать более лаконичный код, в частности, лишённый структурного дублирования ? )
Добавте пару буковок для расшифровки, я их осилю.