В общем я давно это хотел высказать публично, да не находил времени. Меня всегда удивлял тот факт, что люди, которые должны в силу своих седин и многочисленных ранений под ребрами, проповедовать ясность и простоту кода, так вот именно они, порой выкобениваются почище коз на костромском лугу. Я в данном случае имею ввиду тот факт, что всем известное правило, - "Название класса/метода должно быть говорящим" было попрано архитекторами этого языка с поистине дьявольским размахом. Перейду от слов к делу. Возьмем два класса - Vector и ArrayList, простой нормальный еврей никогда не догадается, что эти два названия говорят о том, что первый является синхронизированной версией второго. Пойдем далее, как вам названия Hashtable и HashMap, прошу заметить, что в первом названии второе значащее слово написано с маленькой буквы. Наверное, у кого-то дрогнул мизинец или кнопка Shift залипла, а в далеком 95-м кроме кустарных перловых скриптов инструментов рефакторинга еще не существовало. 
   
   Коллекции это конечно отдельная история. Не проходит и месяца, как я забываю напрочь, какая из них, что означает и когда какую лучше использовать. Прошло больше 10 лет, из компании Sun ушли многие из тех, кто участвовал в написании версий больше единицы и меньше двух, но по всей видимости традиции нарушать там не принято и вот сначала появляется интуитивно понятная добавка в компанию к String'у и StringBuffer'у в виде StringBuilder'а а чуть погодя появляются новые коровые интерфейсы NavigableMap и NavigableSet с замечательным набором методов lower, floor, ceiling и higher (для Map они имеют суффиксы Entry и Key). Поднимите мне руку если вы догадались что они делают не разу не читав их описание, а теперь бросьте в меня камень те, кто читал о том, что они делают и никогда не путал floor с lower и ceiling с higher.
   Великий боже! Кто придумал название Externalizable, которое всего лишь означает, что сериализация будет происходить по моему усмотрению?!?!
Эх, написал бы дальше, но думаю пока достаточно. Суть моей петиции ясна. Ее итог ясен - хорошим программистам Java гарантирована хорошая зарплата(*) и слабое здоровье... конечно последнего не случится если вы не будете вместо завтрака и ужина пить двойную порцию каппучино, любезно сваренную вам кофе-машиной на офисной кухне.


* Здесь автор хочет сказать, что отчасти тенденция к усложнению играет на руку тем кто, успел в этом усложнении разобраться. И, хотя вот этого интервью (Интервью Бьорна Страуструпа, данное 1 января 1998 года для журнала Computer), на самом деле, никогда не было все же это забавно.

Это сообщение отредактировал(а) Royan - 23.3.2008, 20:28

На самом деле кроме плохих архитектурных решений (названных тобой) есть еще много отличных, из-за которых мы и любим Java'y. И зарплата  тут ни при чем (хотя приятный момент ).
Тем более, я думаю, у умных дядек были причины так называть классы, интерфейсы, методы. Может мы когда-нибудь поймем их   

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



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


   

Да уж во много раз лучше так чем, например, в ассемблере трёх или четырёх буквенные названия операций. И ещё куча языков со своими минусами и плюсами....

Изначально в Java 1.0 были Vector и Hashtable. После того, как появился Java Collections Framework, были введены вполне логичные классы с именами ArrayList и HashMap. Одновременно Vector и Hashtable оставили для обратной совместимости и доработали для совместимости с JCF, сделав синхронизированными.



Насчет floor, lower, higher и ceiling (условия соответственно <=, <, >, >=) могу сказать, что англоговорящим программистам эти слова ближе и более понятны.
Ну а Externalizable так был назван видимо потому, что он предоставляет методы readExternal и writeExternal (наподобие того как в .NET есть интерфейс IDisposable с методом Dispose).
Кстати "externalize" гугл переводит как "курирую", что означает "контролирую процесс". Следовательно "externalizable" можно перевести как "можно контролировать процесс".

Это сообщение отредактировал(а) $tatic - 23.3.2008, 21:47

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

StringBuffer vs StringBuilder  - ясно что разные, не составляет труда запомнить разницу. 
Hashtable - наоборот хорошо что с маленькой буквы, хорошее напоминание что старая штука и без надобности пользовать не надо. Опять же позволяет легко запомнить что эта штука synchronized, в стародавние времена многое было медленно, это сейчас все летает, потому часто надобности в синхронизации нет. 
ArrayList - отличное название. Vector хуже, но изначально было тоже хорошее. Не называть же было ArrayList скажем как NonSyncVector   
Externalizable - видно что похоже на Serializable но другое, это отличие надо запомнить. Отличное название, по моему. Есть другие варианты? 
lower, floor, ceiling и higher - интуитивно понятно, но пока не пользовал. Посмотрел API - да, навания отлично отражают суть. Сами названия NavigableMap и NavigableSet тоже отлично отражают суть. Не понимаю в чем проблема. 

Такое ощущение что у тебя просто стоит изначальная установка на то что это глупость, потому и принять не получается. 

Это сообщение отредактировал(а) niasilil - 23.3.2008, 22:42

Если честно - никогда не заботили такие вещи. Java runtime создавали и дополняли разные люди, в разное время, у каждого свои предпочтения и разное количество тараканов в голове  

Гораздо больше беспокоит, когда в java runtime появляются достойные лишь критики архитектурные решения.

Это сообщение отредактировал(а) w1nd - 23.3.2008, 23:26