Александр +, ну понятие "новичок" размытое, мы же не знаем на какоую позицию человек пытается получить. Для меня junior и middle (вчерашний junior) и человек вчера выучивший синтаксис языка попадают в эту категорию.
Все верно, сочитания клавиш могут работать и не работать в зависимости от того где они используются. Если вы выделите какой-то view там могут быть совсем другие комбинации клавиш, отличные от других view. Тоже самое с редакторами. Список комбинаций клавиш доступных в текущем "контексте" можно получить по комбинации Ctrl+Shift+L
Вашу програму вам надо разбить на 2 части: 1) общие интерфейсы, 2) ваша программа с функционалом добавления/удаления плагинов. Особняком стоят модули которые имплементируют "общие интерфейсы". Задача общих интерфейсов: должны включать в себя набор классов и методов для того чтоб обновлять существующий GUI (напр. public interface PluginUI{ public void initialize(Component target)}. При загрузке плагина вам надо открыть диалог выбора плагинов (напр. open jar file), создать отдельную компоненту (java.awt.Component) в которой этот плагин будет отрисован. Найти класс который будет отрисовывать данный плагин (тот который имплементирует PluginUI). Последнюю задачу можно упростить если хранить названия класса в property file внутри jar file.
p.s.s самое главное тут это загрузка классов с помощью class loader, этому нужно уделить больше внимания
можно положить скрипты инициализации базы в git, и для переключения бранчи использовать скрипт который будет делать git checkout + DB reset + DB setup. После переключения у вас будут скрипты актуальные для данной бранчи останется лишь удалить существующую базу. Если нет возможности пересоздать базу с нуля или полностью ее почистить придется хранить в git еще и скрипты очистки базы. В скрипте для git checkout поменяется порядок: DB reset + git checkout + DB setup (т.е. удалили структуру в ветке А, переключились на ветку Б, проинициализировали БД скриптами из ветки Б).
p.s. если нужно заполнять базу какими-то данными то надо обновить главный скрипт
Правильно поставленый вопрос уже содержит ответ в себе. Что изучить - то что вам нужно для того чтоб брыть заказы. Что нужно для того чтоб брать заказы: 1) опыт 2) то что нужно есть в самом заказе. Как получить опыт: 1) устроится в компанию 2) делать лабы, курсовые студентам 3) Делать те же заказы не за деньги а за отзыв. Дальше по аналогии...
Лучше сделать два отдельных репозитория. Все что обьединяет frontend с backend это документация, где ее хранить и как шарить с обеими командами это уже другой вопрос.
самая типичная ошибка "я перепишу все" - в результате вы напишете тот же код еще раз но немного по другому учитывая кое-какие ошибки. Однако вы сделаете новые. Умение "писать код с нуля" и умение "улучшать код" - немного разные.
для того чтоб постигнуть "дзен" курите траву "Single Responsibility". Пока не освоите этот принцип никогда не поймете ООП по настоящему.
несмотря на то что о нем пишут часто как о единственной ответственности класса (обьекта), попробуйте применить этот принцип ко всему:
1) эта программа решает одну задачу?
2) этот модуль/библиотека решают одну задачу?
3) этот класс/обьекта решает одну задачу?
4) этот метод решает одну задачу?
если ответ на вопрос - "нет": разделяем на составляющие.
p.s. если есть нужда исправить существующий код спускайтесь по списку сверху вниз и исправляйте, только не спешите переходить от одного уровня к следующему
Для того чтоб выделить группу обьектов в отдельную категорию можно добавить им отдельный интерфейс:
interface CanBeThrowed { void throw() }
interface CanBePickedUp ( void pickUp(); void pickUp (Object from) )
interface IsWeapon ( Weapon getWeapon() );
p.s. лично мне показалось что задача слишком сложная для вас. Если вас все-же интересует результат начните с прототипа и добавляйте новые "фичи" по очереди. И пишите на каждую фичу тесты. Это единственный способ как не забросить идею. Путь этот долгий и достаточно тяжелый
Neoline: я так понимаю вы снова делитесь своим опытом. А моем все было по другому: большую часть простых паттернов я научился использовать еще до того как почитал теорию. К освоению теории я пришел намного позже поэтому сразу получил "толчек" в развитии. Мое мнение: паттерны не какая-то заоблачная теория которую придумали профессора в белых халатах а еще две ступеньки на пути которые надо освоить (теория, практика). А если вы вспомнили о том с чего все началось то: автору как раз SOLID нужен хотя вы рекомедуете не разбиратся с этим, на этом этапе паттерны автору не нужны это факт, но это еще не значит что то что случилось с вами: "будите разбираться вообще запутаетесь" постигнет всех.
Neoline: аргументы и обьективность потерялась сначала в вашем комментарии, как раз в том на который я и ответил сарказмом и картинкой. Касательно ООП и паттернов - нравится или нет есть только 2 вида кода: ООП код и процедурный, и то что происходит в реальном мире большее похоже на ООП код чем на процедурный. А шаблоны (они же паттерны) в реальном мире везде используются, они не добавляют никакой сложности в код как и не убавляют, ведь их надо применять тогда когда они нужны. А для того чтоб знать когда этот момент наступил надо в них разбиратся чтоб не "лепить ооп где надо и не надо"
Neoline: не надо свой опыт екстраполировать на других, паттерны полезно изучать хотя бы для того чтоб знать что у многих задач есть типичное решение и ненадо придумывать свой велосипед.
Проблема с ООП в том что все термины в программировании и разработке приложений это иностранные слова, которые в лучшем случае мы можем перевести. Для того чтоб разобратся в чем-то нужно перенести "проблему" в жизненную плоскость.
Например: у шара неможет быть метода "катится" потому что как бы он не хотел он не может сам себя покатить. Но человек может покатить шар. У класса человек может быть метод "кушать", а вот метод "накормить" уже не привязан к конкретному человеку (т.е. должен быть статичным) т.к. кормить кого-то необязательно нужно делать самому человеку: дай еду, другой человек сам поест (даже если эти два обьекта один и тот же человек). Комментарий не может добавить сам себя, только человек (пользователь) может добавить комментарий. Если посмотреть на это под другим углом то можно сказать что: комментарий это сообщение у которого есть автор и "цель", целью может быть статья, новость, фаотка или другой комментарий/сообщение.
В серверной разработке часто все классы делят на 2 группы: модели, контроллеры (так же как и в паттерне MVC). Модель используется для представления, хранения и передачи данных. А контроллеры занимаются тем что управляют ими (создают, удаляют, меняют), обмениваются данными между собой итд итп.
если вы боитесь кода то этому могут быть 2 причины: а) лень читать/разбиратся в чужом/своем коде б) сложно читать/разбиратся в чужом/своем коде
в обоих случаях рецепты "лечения" такие: больше читать чужой код, реже менять стандарты (форматирование, принципы наименования, ахитектуру, технологии). С другой стороны надо больше читать незнакомого вам кода (для того чтоб подтянуть скилл), можно так же читать свой старый код
каждая константа в enum является анонимным абстрактным классом который наследуется от enum в котором он обьявлен, все их свойства вытекают из этого. На примере вашего enum Type, иерархия классов для INT будет выглядеть как-то так: Type.INT extends Type, Type extends Enum, реальные же имена скомпилированных классов такие же как у обычных анонимных.
Сергей Протько: спасибо за детальный ответ, но на мой вопрос: "где в моем коде процедурное программирование" я все же не нашел ответа. Для себя я вижу только 2 существенные разницы (помимо того что я писал выше), у вас классы User которые содержат в себе модель и контроллер - stateful, у меня UserEntity модель - stateful, UserManager контроллер - stateless. И как следствие функционал ваших классов может менятся в зависимости от их состояния, у меня же все контроллеры - stateless (за редким исключением). А дальше осталось лишь угадать как писать тесты для всего этого. Если в моем случае для тестирования метода надо учитывать лишь данные на входе то в вашем случае еще и состояние.
p.s. я не буду спорить, ваш подход имеет право на существование, но он применим только лишь (субьективное мнение): а) для домашних поделок, где вы вкурсе всего что происходит б) для фриланса (сделал - забыл) в) для маленьких проэктов сильно ограниченных во времени. Ни в одном серьезном проэкте я б не стал подобную структуру использовать, такой код мне сильно напоминает то, что можно увидеть в толстых книжках по EJB 2.0 (т.е. уже не актуально)
p.s.s касательно "лазанья код" - да вы правы, изменение всех слоев это рутина требующая усиленного внимания и концентрации (в прочем как и все что делает программист). Однако код в таком случае максимально прост и читабелен. К тому же есть варианты которые позволяют предупредить изменения всех слоев при изменении структуры model (или субд или еще-чего-то там).
Сергей Протько: я понял суть вашей позиции, однако я уверен что в моем случае классы будут тоньше (но их будет больше). Но и минус моего подхода: изменений тоже будет больше - но они будут точечные (одно поле добавилось/удалилось), одна-две строчки. Единственное что я не уверен что правильно понял так это почему вы такой подход называете процедурным, можно более детально?
