Comments on: Анти-паттерн проектирования (Java): интерфейс для констант

By: marov

marov — Tue, 15 Sep 2009 09:51:47 +0000

Блин, даже мысли никогда не возникало засунуть в интерфейс константу.

By: Sergey

Sergey — Mon, 14 Sep 2009 01:21:58 +0000

Согла�?усь с Oleg’ом. Видно сразу, человек заканчивал программирование с филосовским уклоном :).

Ко всему им сказанному, хотел бы добавить. Причина многих затруднений кроется в наскакивании на идеи, до которых люди еще не доросли. Поясню. Человек только начинает учить программирование и на него сразу сваливается ООП, которое не родилось сразу из ничего, а люди при�?ли к нему в процессе взросления своих идей.

Я считаю, что начинающего нужно знакомить с простым линейным программированием, дать ему саму упереться в стенку и задать вопрос: “А нет ли способа реализовать задачу вывода всех чисел от 0 до 100 проще, чем писать:
Writeln(”0″);
Writeln(”1″);
…
Writeln(”99″);
?”, и тогда скормить ему циклы, затем функции. Так же и классы нужны тогда, когда человек уже созрел для них. Так же и интерфейсы, и все остальные концепции. Я, конечно, пояснил сильно утрированно, но, надеюсь, донес свою мысль.

Если во время спора о необходимости использования того или иного подхода (паттерна) на вопрос какие преимущества в нем заключаются, оппонент дает заученную формулировку. А после вопроса, как он к этому при�?ел, говорит, одну из следующих фраз:
1. Мне лид сказал так делать.
2. Мы так всегда дели.
3. Так в книжке “Н” написано.
Сразу становится понятно, насколько человек понимает то, о чем говорит. Понятно, что он следует “своему” любимому паттерну, даже если тот совер�?енно не подходит для его языка или противоречит структуре приложения. �? он сделает все, чтобы соблюсти чистоту этого паттерна, даже если для этого приходится идти на неоправданные жертвы.

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

By: Leshij

Leshij — Wed, 08 Oct 2008 11:46:47 +0000

По поводу ResultSet. Эти константы как раз являются косвенно частью контракта класса, реализующего РизалтСет. Метод getFetchDirection, допустим, возвращает одну из этих констант. Правда, такие вещи луч�?е делать Перечислениями (enum), но в версии 1.2 их еще не было).

By: m.victor

m.victor — Fri, 05 Sep 2008 20:02:17 +0000

А если уж выносить константы в интерфейс, то луч�?е выносить их в отдельный класс с приватным конструктом.

By: Oleg

Oleg — Thu, 14 Aug 2008 19:32:33 +0000

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

By: Oleg

Oleg — Thu, 14 Aug 2008 19:25:54 +0000

Прочитав, хочется ли�?ь поддержать вовку (vovka)..
�?бо говорящий не знает, а знающий не говорит :).
ООП и паттерны будоражат на�?и умы как красная тряпка возбуждает быка, или модный яркий магазин влечет блондинку. Как… эээ… ну вобщем понятно я думаю.
�? что самое интересное, мы теперь начинаем рассуждать: “Это противоречит правилам ООП”. Здрасте приехали… Боже мой! Если всю жизнь следовать правилам - можно никогда ничему не научиться. Пи�?ите как вам взбредет в голову и со временем все встанет на свои места. О�?ибки и эти все “антипатерны” проявятся сами собой. А может быть вы выработаете свой, совер�?енно уникальный стиль, и откроете новые “паттерны”. А заранее вы все равно соломку не подстелите в нужном месте. А все эти “паттерны” - ПРОСТО Ж�?ЗНЕННЫЕ ВЕЩ�?, которые новичкам кажутся чем-то магическим, что (каким-то вол�?ебным образом) они спасут их в будущем, избавят от страданий и разочарований, ли�?ней работы и т.п.

By: scorp

scorp — Mon, 10 Mar 2008 18:41:34 +0000

2Leledinn
нельзя считать библиотеку классов java чем-то сверъестественным и на 100% правилным. несмотря на то, что над ней уже много лет работают, в ней есть опло�?ности, неадекватные ре�?ения и т.п. Эккель в своей “Философии Java” приводит с пяток примеров того, как не надо делать, на основе кода библиотек классов java 1.1-1.3 например.

By: c0nst

c0nst — Tue, 22 Jan 2008 18:15:10 +0000

2Leledinn:
На счет ResultSet. �?нтерфейс не может содержать полей-членов. Поэтому нет смысла писать public static final. Кстати, модификатор public перед именем метода тоже писать не нужно.

2AlexeyEgorov:
�?нтерфейс - это контракт, согла�?ение между разработчиком класса и пользователем класса. Реализуя интерфейс, класс становится частью API, которое доступно пользователю. В итоге получается, что разные константы, несущие порой абсолютно разную смысловую нагрузку и часто являющиеся деталями реализации, становятся частью API. Непорядок…

2stan: Спасибо боль�?ое за отличный комментарий.

By: Denis

Denis — Wed, 16 Jan 2008 18:48:34 +0000

Спасибо, Человечищи! �?з Ва�?их разговоров узнал много нового! Ещё раз спасибо.

By: AlexeyEgorov

AlexeyEgorov — Sat, 29 Dec 2007 19:33:09 +0000

наследование констант в теории ООП не запрещено

см. например Бертран Мейер “Object-Oriented Software Construction”, тут перевод
http://www.intuit.ru/department/se/ooad/6/ooad_6.html, “льготное наследование”

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