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!
Среда разработки 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!

Комментарии (10)
RSS свернуть / развернутьSergei_T
yababay
Sergei_T
yababay
Вначале было СЛОВО !
Когда много писал на С и С++ всегда была проблема ПРАВИЛьного названия
переменных. В одной из программ у меня их было 3000.
И каждую надо было назвать со смыслом.
Markony
yababay
Java стал просто зубодробительно сложным инструментом (((
Gangsta
Обычно я не тороплюсь осваивать новые возможности языка: придет время и они познаются сами собой, при удобном случае. Например, коллекции я освоил лишь два года назад, до этого обходился массивами и классами из старого (1.2) java.util. Никто ведь не гонит: можно освоить минимальный набор самых основных пакетов (java.lang, java.io, java.net, java.util) и писать вполне жизнеспособный софт (с учетом Deprecated, конечно). Обратная совместимость в Java реализована отлично.
yababay
Sergei_T
Markony
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.