3f-lab и Капитан Очевидность

Начало см.: mtaalamu.ru/blog/coding/491.html

Среда разработки Java-приложений 3f-lab — это, еще раз повторю, не программный продукт, а методология. «Гнездиться» она должна не на жестком диске компьютера, не в оперативной памяти, а в голове программиста. Главный принцип — принцип бритвы Оккама: не запоминай ничего, о чем потом придется забывать. Рассмотрим некоторые проблемы, которые такой подход позволяет решать.


Допустим, вы создаете пространство имен для нового проекта. Нужно выбрать имя пакета. По какому пути идут начинающие программисты? Процентов 70 из них — по самому глупому: «Создам быстренько пакет test.* (или вообще прикольное слово какое-нибудь использую), потом переделаю если что». Думаю, тут даже комментировать нечего: переделывать приходится практически сразу же. Если кому-то это не кажется очевидным — спрашивайте, поясню в комментариях.

Гораздо опаснее второй путь, «путь эстетствующих». Они-то как раз хотят начать работу на абы как, а именно с чего-то впечатляющего. Например, специально заводят для проекта домен второго уровня и называют пакет как-нибудь типа com.superproject.*. Казалось бы, всё правильно и даже в соответствиями рекомендациям фирмы Sun. Но я бы не советовал и это: завтра вы затеете проект org.superresearch.*, послезавтра — ru.aboutmycountry.* и в конце концов так во всем этом запутаетесь, что с немалой долей вероятности бросите программирование на Java.

Как же быть? Да очень просто. Есть вы, есть ваши проекты, вот и храните каждый из них в пространстве имен вида ru.vasiliypuplo1995.projects.MY_SUPER_PUPER_PROJECT.*. Может и длинновато, но зато резко уменьшает диапазон каталогов для поиска исходников и бинарников. О том, почему в имени ракета использован капс расскажу как-нибудь потом.

Идем далее. Иногда в процессе программирования возникают интересные находки, пригодные для многократного применения, т.е. повторного использования в других проектах. Как быть в таких случаях? Естественно, выделять в отдельные классы и хранить во «внепроектных» пространствах имен. Например, написали вы собственную реализацию алгоритма base64 — поместите ее в класс ru.vasiliypuplo1995.util.B64. Вроде очевидно, ан нет: бывают случаи, когда по этому поводу городятся такие огороды, что мама не горюй, вплоть до java.util.VasyaPuploBase64.

Хорошо, пространство имен создали. Начинаем создавать классы и интерфейсы. Как назвать главный (а в немалом количестве случаев он же и единственный) класс в рамках проекта ru.vasiliypuplo1995.projects.AUDIO_PLAYER? Может быть MyCoolAudioPlayer? Может быть Client или Server? Да нет. Назовите его тупо Main и разместите исходник в файле Main.java. Информация о назначении проекта уже понятна из пространства имен и дублировать ее не надо. Зато когда вы начнете другой проект и поступите так же (создадите класс с именем Main), вы с приятным удивлением обнаружите, что во вспомогательных файлах (таких как build.xml) менять почти ничего не надо, что позволяет существенно сократить затраты на наладочные операции и перейти сразу к сути. Если в проекте есть клиентская и серверная части — создайте ru.vasiliypuplo1995.projects.AUDIO_PLAYER.client.Main и ru.vasiliypuplo1995.projects.AUDIO_PLAYER.server.Main. Не бойтесь длинных имен пакетов, от них пользы больше, чем вреда.

Точно так же следует поступать и в случае многократно используемых библиотек. Например, последние года два я активно разрабатываю виджеты для GWT. Появляются такие пакеты, как com.michaelbelyakov1967.gwt.menu, com.michaelbelyakov1967.gwt.rss, com.michaelbelyakov1967.gwt.login. Вместо того, чтобы называть главные классы этих пакетов как-нибудь вроде LoginWidget или LoginWithForgottenPassword, я называю их WidgetEx, а в случае, если нужна многоступенчатая реализация с наследованием — WidgetEx_A, WidgetEx_B и т.д. Казалось бы, не информативно. Зато во всех подкаталогах лежат файлы с примерно одинаковыми именами и их легко обрабатывать. А информацию о том, над чем же мы в данный момент, все-таки, работаем, можно получить и из имени пакета. Поверьте, когда вы через полгода вернетесь в этот каталог чтобы что-нибудь подправить, вас не спасут никакие самые адекватные имена файлов типа LoginWithForgottenPassword — всё равно придется разбираться заново во всем коде. А система WidgetEx_A, WidgetEx_B по крайней мере позволяет понять что откуда вытекает.

Sapienti sat. Ну и to be continued!
  • +4
  • 01 февраля 2010, 10:56
  • yababay

Комментарии (10)

RSS свернуть / развернуть
+
0
Как скажешь так и напишем — свои шишки нет никакого желания набивать
avatar

Sergei_T

  • 01 февраля 2010, 12:33
+
0
Рад этим словам. Давно уже не интересно работать в одиночку. А чтобы работать командой — нужны договоренности о правилах взаимодействия. Достигнуть их гораздо труднее, чем написать сложную программу. Зато если они достигнуты — программа создается в десятки раз быстрее, чем если бы ее писал один программист (хотя количество работающих увеличивается всего в два-три раза . Кстати, у меня сейчас «белый IP». Может замутить git-репозитарий «на антресолях»?
avatar

yababay

  • 01 февраля 2010, 12:48
+
0
Можно запустить
avatar

Sergei_T

  • 01 февраля 2010, 12:57
+
0
ОК, сейчас подготовлю, в личку настройки скину.
avatar

yababay

  • 01 февраля 2010, 12:59
+
0
Согласен.
Вначале было СЛОВО !
Когда много писал на С и С++ всегда была проблема ПРАВИЛьного названия
переменных. В одной из программ у меня их было 3000.
И каждую надо было назвать со смыслом.
avatar

Markony

  • 01 февраля 2010, 19:54
+
0
3000! Не хило…
avatar

yababay

  • 01 февраля 2010, 21:27
+
0
КЭП классный
Java стал просто зубодробительно сложным инструментом (((
avatar

Gangsta

  • 01 февраля 2010, 21:49
+
0
Согласен. Иной раз страшно делается и ум за разум заходит . Для меня ряд моментов (например, аннотации) до сих пор темный лес.

Обычно я не тороплюсь осваивать новые возможности языка: придет время и они познаются сами собой, при удобном случае. Например, коллекции я освоил лишь два года назад, до этого обходился массивами и классами из старого (1.2) java.util. Никто ведь не гонит: можно освоить минимальный набор самых основных пакетов (java.lang, java.io, java.net, java.util) и писать вполне жизнеспособный софт (с учетом Deprecated, конечно). Обратная совместимость в Java реализована отлично.
avatar

yababay

  • 01 февраля 2010, 22:07
+
0
Думаю что продуктами sun можно автоматизировать много чего без всяких там SAP и тд
avatar

Sergei_T

  • 01 февраля 2010, 22:40
+
0
Bo!
avatar

Markony

  • 02 февраля 2010, 17:48

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.