exppс возрастом это проходит
Интересно, почему "это" не прошло у разработчиков c# 3.0 и java 7?

exppниправда: первая версия таблица забивается в коде в static инициализаторе. вторая версия выносится в конф.файло.

Код в студию. Мне не понятно о чём вы.


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


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

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


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

Можете меня переубедить. Для этого достаточно привести-таки целиком ваш вариант с табличками и показать как он изменится при изменении одного из правил проверки с equlas на startWith.

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

ПОКАЖИТЕ. Зачем произносить лишние слова?

expp
это было написано для того чтобы показать насосанность из пальца вашего утверждения про то что descision table это на самом деле паттерн стыренный оопниками.


Повторюсь, в тайной надежде, что вы просто не внимательно до этого читали.

Использование "таблицы выбора" оставит процедруный код процедурным.
В ООЯзыке этот "паттерн" вшит, называется "полиморфизм".
Использование классов и полиморфизма вместо дискриминатора и таблицы лучше тем, что
- вызывать метод быстрее, чем бегать по мапе,
- не нужно каждый раз изобретать велосипед и заставлять разбираться в нём своих коллег,
- из-за плюсов статической типизации (н-р, Map<string, string> adress2name и Map<string, string> name2department не попадут в один метод)
- ...

expp
выкобениватья на немерлях. пройдёт. как и у польских аспирантов. получится очередной похеренный .NET O/S проект.

Что значит "выкобениватья на немерлях"? Приверженцы функциональных языков тоже только "выкобениваются"? :)

Есть пример DLINQ от МS. Языки like nemerle уже реальность.

expp
Про jdk 7 слышал... поморщился и подумал про PR. пусть лобают. но недай бог какаяннить зараза в моём проекте closure заюзает - я думаю смогу популярно объяснить что именовать методы и классы возможно и вполне по силам. про делегаты - ваще молчу

Объясните здесь.

expp
о чём дискусия то? если про subj - то я "за" немедленное выжигание калёным железом быдлокодерства в любых проявлениях. и "за" смачный оопный дизайн .

Давайте повспоминаем о чём дискусия...

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

Вы как-то вяло стали спорить с тезисами и привели микс из класса и таблицы выбора в качестве оо решения.

Далее я писал о том, что этот микс к ООП не имеет никакого отношения и ничем не лучше, чем набор if/else, а вы писали, что у меня "всё пройдёт", что вы "умеете готовить ООП", но так никому и не показали как и что-то там про насосасывание из пальца добавили...

Резюмируя: Я не знаю о чём вы ведёте дискусию и что хотите сказать (кроме того, что к if/else у вас не любовь). Я же пытался и пытаюсь узнать, как "правильно готовить ООП" и почему у меня оно на ваш (или чей угодно ещё) взгляд "галимое"(с) :)

alexx726Ребята, пукать в лужу не надоело друг перед другом?
Неужели нет более достойных тем (тем более в Java) для обсуждения, кроме как вариантов написания идиотской программки для даунов?
Аж читать гнусно...

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

Будет только хуже. Почитай только, что о хибернейт с соседних топиках писалось.

exppце кот

можно я map у из файла грузить не буду а то работать нада ...

1. new OsDescisioner(); - это опечтка?

2. Я предлагал изменить правило сравнения только для windows (т.е. для unix - equals, для windows - startWith), ваш вариант поэтому не подходит.

3. В примере были более сложные условия выбора. У вас оно выглядело бы так:
Т.е. появляется дублирование.

Когда понадобится в другом месте использовать аналогичный выбор, то получится ещё большое дублирование:


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

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


4. Грузить из файла? Зачем?!

expp
NotGonnaGetUs
Я уже писал, таблицы порой даже проигрывают if/else, т.к. они фиксируют алгоритм сравнения.

не а. мапы рулят. нужен алгоритм сравнения пишем IEqulizer - и фаны closure показывают всю свою мощь

Т.е. каждая запись в мапе содержит проинициализированный IEqulizer и строку результат?

А зачем тогда тут map, если это чистой воды list (сторку-результат легко забросить через параметр в IEqulizer) ?

А вообще, да... Мапы рулят. Зачем нам классы, статическая типзация, полиморфизм, инкапсуляция и т.д. и т.п., если любой объект можно промоделировать map'ой?
Моделировать средствами ООЯзыков паттерны процедурных языков - это круто...


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

для клинических случаев дсл и кастро языки или plug-in class (каждый раз что то новое придумываю - воистину не исчерпаемая затача таксономии ОСов). дсл и кастро языки уже есть бери и юзай если надо. не надо приплетать сюда полиморфизм чтобы показать, что он "не вывозит"


А я опять скажу "дсл и кастрированные языки это существенно большее усложнение решения, чем использование полиморфизма".

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



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

Мы не "конфиг" пишем.

А в целом вы правы. Зря статик мапы держали. Вместо:

Куда лучше написать по-человечески, вынеся все проверки из runtime в compile time:


expp
NotGonnaGetUsЧто значит "выкобениватья на немерлях"?
это значит злобать на них helloworld не убившись от стену, восклицать : "буть прокляты годы на с# (жабе и т.п.)"
...
smalltalk, lisp, oberon, OODB, ai тоже реальность

Я не испытываю никакой радости от возможно написать helloword вне class {void main{}}.
Что меня радует так это:
- кратность нотации без потери статической типизации,
- вывод типов (фактически возможность локально применять duck typing),
- возможность делать больше проверок при компиляции средствами языка (таже валидация sql),
- паттерн матчинг и record'ы, для того чтобы забыть о проблемах с if-ами и возвращением множественных значений,
- оптимизация хвостового вызова (долой неукюжие for'ы для раскрутки стека)

expp
NotGonnaGetUsЕсть пример DLINQ от МS. Языки like nemerle уже реальность.
про jdk7 я конечно рад closure и delegateам в ущербном жабаязыке, но думаю никогда их использовать не буду т.к. они явлются излишней мутью, необходимой только их авторам

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

teb
Дык... мил-человек... разве ООП инструмент для решения абстрактных задач?

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

Конечно, можно отказаться этой возможности и других, и страгать на ООЯ в стиле "plain c", но тогда к чему все эти слова о "распределении обязанностей", гибкости решений и т.п.?

teb grexhide вдруг начали с "общего перепугу" натягивать

Так "натягивать" - это не ООП.
Вот NotGonnaGetUs этим как раз и занялся в своём примере.
Мне так каэтся.

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

И получилось плохо.
Чему удивляться?

Солнышко! Ну покажи, наконец-то, дурачку как правильно классы писать.
Приведи решение, аргументируй почему оно гибче/лучше того, что приводил я.
Покажи как оно будет меняться при возможных изменениях тербований. И все станут счастливы.
Зачем сидеть и просто так "удивляться"?!

какбытькакжитьА если этих вариантов (поведений) 50-100? Что, 100 классов наследовать? А как в одиночку с этим справиться, может проще как советует expp, налабать таблицу выбора?

А ты просто попробуй, поделишься потом впечатлениями :)

expp

NotGonnaGetUs2. Я предлагал изменить правило сравнения только для windows (т.е. для unix - equals, для windows - startWith), ваш вариант поэтому не подходит. такое изощрение лечиться wildcardами или сразу regexpами



Такое изощрение лечить не надо.
Нужно лечить того, кто для определения типа ОS по имени предалагает вместо класса содержащего простой метод (вроде s.equals("Linux") || s.equals("SunOS")) что-то параметризовывать и интерпретировать (да ещё с регэкспами).

expp

NotGonnaGetUs
Т.е. появляется дублирование.




Осталось привести код, как избавиться от дублирования в случае с "anotherDscTable"... чтобы понять всё удобство использования map вместо полиморфизма.


expp
Collections.unmodifableMap и воьще поставить с default доступом

Круто...

expp
NotGonnaGetUs4. Грузить из файла? Зачем?! а вот это помоему действительно нужный функционал - конфигурировать прогу неперекомпиляя её. во всяком случае очень много людей думают так же

Внешняя конфигурация усложняет код, далеко не всегда такое усложнение оправданно.


expp
NotGonnaGetUs
Т.е. каждая запись в мапе содержит проинициализированный IEqulizer и строку результат?

нет каждая DescistionTable имеет свой IEqulizer.

Я привёл пример, когда одним equlizer'ом не обойтись. Только не надо опять об регэкспах.

expp
NotGonnaGetUs
А зачем тогда тут map, если это чистой воды list (сторку-результат легко забросить через параметр в IEqulizer) ? да. при извратской логике доступ по ключу не нужен - просто список пар.

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

expp
NotGonnaGetUs
А вообще, да... Мапы рулят. Зачем нам классы, статическая типзация, полиморфизм, инкапсуляция и т.д. и т.п., если любой объект можно промоделировать map'ой?
Моделировать средствами ООЯзыков паттерны процедурных языков - это круто...
пишу буквами побольше ни нужен тут этот рукав (полиморфизм)

Ну так обоснуйте...

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

Что-то не пойму в каком смысле вы используете слова статическая/динамическая.
Полиморфизм - шутка "динамическая", т.к. вызов метода происходит на основе рантайм информации, и к статической/динамической типизации отношения не имеет.

Почему вам проще связать таблицу с интерпретируемым языком вместо того, чтобы написать один класс - не знаю. А ещё говорили, что код на динамичеки типизируемых языках "отстрел ног"...


expp

NotGonnaGetUs
Мы не "конфиг" пишем.

повторюсь. это и есть конфиг, нах.

Неа. Это не конфиг. Это вывод сообщения в зависимости от типа ос/цвета шерсти кролика/чего угодно другого.

Не забывайте, что начали мы с замены гирлянды if/else на что-то нибудь более подходящее.
Каждый if/else будем выводить в файл? А если вместо печати строки нужно подстричь газон/сходить под кустик? Эти действия тоже в файл пойдут?

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

Выносить логику в файлы конфигурации в данном случае не оправданно абсолютно.


expp

NotGonnaGetUsЗря статик мапы держали. Вместо:

Куда лучше написать по-человечески, вынеся все проверки из runtime в compile time:

какая то странная прога её для виндов перекомпилять нада???? решение вроде принимается исходя из значения runtime ?


Слава богу. А то, я уж грешным делом подумал, что вы всё и всегда кладёте в статик мапы.

Тогда проясните:
Вы создавали на каждое проперти по статик мапе?
Или у вас была статик мапа с единственным проперти, которое само по себе было мапа?

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

expp

NotGonnaGetUs
Я не испытываю никакой радости от возможно написать helloword вне class {void main{}}.
Что меня радует так это:
- кратность нотации без потери статической типизации,
- вывод типов (фактически возможность локально применять duck typing),
- возможность делать больше проверок при компиляции средствами языка (таже валидация sql),
- паттерн матчинг и record'ы, для того чтобы забыть о проблемах с if-ами и возвращением множественных значений,
- оптимизация хвостового вызова (долой неукюжие for'ы для раскрутки стека)
круто, рад за вас.... нахер всё это. дайте жабу да будет свет!!!

Нахер? Всё? Точно? :)
Вот и поговорили.

expp
NotGonnaGetUsСмеха ради, почитайте как используются ущербные лямбды в DLINQ'е. всё бросил и пошёл читать ... буду как приду
%)

expp------>>> как избавиться от дублирования в случае с "anotherDscTable"...
надо на неё посмотреть чем она another ... в крайнем случае putAll()

Как чем another... Там решения другие принимаются в зависимости от типа ос.

putAll куда писать?

expp
------>>> Внешняя конфигурация усложняет код, далеко не всегда такое усложнение оправданно.
угу. вот сложность то - дёрнуть Property

----->>>Каждый if/else будем выводить в файл? А если вместо печати строки нужно подстричь газон/сходить под кустик? Эти действия тоже в файл пойдут?
В ФАЙЛЕ ПИШЕМ МАПУ ось1=решение ос2=решение ос*=решение_с_wildcardой, что не понятно???

----->>>Выносить логику в файлы конфигурации в данном случае не оправданно абсолютно.
нафига тогда её туда выносят???

Есчо рас. Мы изначально говорили о лапше if/else. Вы всё сводите к задаче конфигурации.

Смотрим на два фрагмента кода:

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

expp
----->>>Почему вам проще связать таблицу с ...
Ну сложилось так. просто и всё

Т.е. просто "вредная" привычка? 6)

expp
----->>>Вы упорно продолжаете пытаться показать, что частное решение, уместное в процедурных языках (где нет полиморфизма), может быть успешно примененно в ООЯзыках.Его применить-то можно, но успешно нет. Полиморфизм решает подовляющее количество подобных задач существенно проще.
ДА НЕ ЭТИ ЗАДАЧИ ОН РЕШАЕТ!!! это просто подходящее решение этой задачи - на любом языке.

Огласите "задачу", а то мне кажется вы говорите о чём-то "своём".


expp
----->>>Вы создавали на каждое проперти по статик мапе? Или у вас была статик мапа с единственным проперти, которое само по себе было мапа?
убился ап текст ... ещё раз. Есть Descisioner c интерфейсом которого и работает клиент - даёт ему значение из системного окружения, берёт от него решение. Больше его ничего не волнует. Самая простая реализация Descisionerа использует статичну мапу, другая грузит таблицу из
файла. Этим достигается разделение кода и данных


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


Ок, ещё раз.
Поговорим о конфигурации приложения.
В зависимости от типа ос (o1, o2, o3) могут настриваться несколько параметров (p1, p2, p2).
Как это сделать при помощи мап?

Вижу один вариант:
все обращения к p1,2,3 идут через захардкоженный строки или через константы.


Как это сделать по-человечески:

все обращения к p1,2,3 идут через стандартный интерфейс, который является "халявной" документацией и избавляет от проблем при переименовании имён параметров и т.п. рефакторингов.

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

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

Где я не прав, говоря, что полиморфизм тут более чем уместен?

NotGonnaGetUsСмотрим на два фрагмента кода:


Во избежание не понимания: Это два блока 100% аналогичных друг другу if/else, различающихся только выбором действия.

exppпы-лять ... чо за склонность к изврату.

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

Не надо истерии.

Задача состояла в другом: показать как может выглядять решение в ОО-стиле и чем оно будет лучше/хуже решения в "процедурном" стиле.

Очевидные этапы решения:
1. Определение типа ОS по имени
2. Выбор действия в зависимости от типа OS.
3. Выделение и изоляция алгоритма определения типа OS (обеспечение точки расширения)

if/else при водит к ребусу, в котором все эти действия соединены воедино.
Маp - ещё больше запутывает решение, т.к. приводит к большому количеству "если" разрешаемых только в runtime (в отличии от легко верифицируемого набора if/else). А когда дело доходит до дублирования структуры if/else, map'ы, в общем случае, оказываются ещё хуже (я приводил примеры (anotherMap, etc)).

Ясное (как день) описание каждого из этапов в ОО-нотации почему-то приводит вас в ужас.

expp
я говорю
1. как быдлокодера меня не скребёт сама логика принятия решения. я делаю дырку для припендюривания разных логик и забываю оп этом.

А кому-то потом приходится вспоминать и ругаться матом автора дырки, потому что логики приходится именно "впендюривать" :)

expp
2. быдлокодера налепившего ифов придётся порешить при попытке в них разобриться или существенно прорефакторить каркас - например переделать решение в <код, строка>

Вы всё-таки определитесь: все if'ы заменять на мапы и выносить ветки в конфигурационные файлы, или только те, где действительно производится конфигурация приложения? :)

expp
3. быдлокодера налепившего для каждого case'а класс нужно сдать в html дизайнеры где он сможет раскрыться в css

А налепившего на каждый case' по десишн мап куда надо сдать? В perl-программисты? :)

exppговно вопрос и трёп закончен
Если бы вы не трепались, а проявили больше конструктива, то вопрос не стал бы гавном :)