В данной теме я решил перечислить самые распространённые ошибки которые допускают новички при разработке своих плагинов.
Возможно, вы сможете решить свой вопрос при прочтении этой темы.
1. Static Abuse
Речь о ключевом слове 'static'. Любимый модификатор каждого новичка, потому что он позволяет легко получить доступ к методу или полю из другого класса! Что может быть проще, чем просто сделать метод или переменную статичной, чтобы вы могли использовать их в других своих классах? Смысл в том, что ключевое слово 'static' предназначено не для этого. Слишком часто я вижу, что 'static' используется для доступа к полю из другого класса, особенно к реализациям Collection и Map, а также к экземпляру основного класса. Это частая ошибка новых разработчиков, которая создает серьезные проблемы с точки зрения дизайна кода и гибкости в будущем.
Не поймите меня неправильно, всегда есть место для использования 'static', и вот некоторые из распространенных ситуаций, в которых это приемлемо:
1.1 Синглтоны
Синглтоны являются предметом огромных дискуссий, особенно с учетом того, что основной класс (тот, который расширяет JavaPlugin) является синглтоном.
Я часто вижу, как люди защищают свое использование статических полей / геттеров в основном классе, потому что это синглтон. JavaPlugin имеет метод для получения одноэлементного экземпляра вашего основного класса, JavaPlugin#getPlugin(Class <T extends JavaPlugin>). Если вы действительно хотите использовать аргумент, что основной класс является синглтоном, поэтому создание статического поля / метода для доступа к экземпляру - это нормально, тогда, по крайней мере, используйте для этого соответствующий метод.
Приведенный выше аргумент следует воспринимать с недоверием. MinecraftServer (класс, который управляет обычным сервером Minecraft) также является синглтоном и имеет статический метод получения. Как и клиентский класс «Майнкрафт». Тем не менее, хотя у них есть статические методы для получения экземпляра, внедрение зависимостей конструктора используется там, где это возможно. Это четко определенные 'Singleton' шаблоны. Когда дело доходит до основного класса плагина, статический геттер следует использовать как последнее средство, когда внедрение зависимостей либо не имеет смысла, либо его невозможно использовать. Этот аргумент предназначен в первую очередь для начинающих, которым не хватает базового понимания ключевого слова 'static'.
Помимо основного класса, синглтоны следует использовать только тогда, когда должен применяться только один экземпляр класса. Например, если у вас есть исполняемый файл, который должен быть выполнен в вашем методе onEnable(), но вы хотите, чтобы он выполнялся только один раз вашим собственным плагином, синглтон, вероятно, будет способом гарантировать, что никакой другой ресурс не поддерживает его выполнения. Ключевое слово "принудительно". Если вы просто создаете статическое поле и метод получения, это НЕ обеспечивает применение 'Singleton' шаблона. Перед использованием паттерна рекомендуется хорошо ознакомиться с тем, как и в каких случаях лучше всего использовать этот паттерн.
2. Повторяющиеся блоки кода (принцип DRY)
Многим новичкам не хватает базовых знаний в области программирования и они совершают ошибку, нарушая принцип «Не повторяйся» ('DRY - Don't repeat yourself'). Как следует из названия, если вам нужно постоянно копировать и вставлять код с разными переменными или параметрами метода, вы, вероятно, делаете что-то не так, и вам нужно пересмотреть структуру вашего кода.
В указанном выше коде есть целый ряд ошибок. Во-первых, вся кодовая база полагается на строки, а не на какой-то объект Pet (более подробно описанный в «Недостаточном понимании ООП»), и в указанном выше примере было создано кучу операторов if и else if, проверяющих равенство строки только для выполнения очень похожей задачи. Наконец, для Entity нет глобальной переменной, а #setDisplayName() без необходимости вызывается более одного раза. Общий дизайн вышеупомянутого метода настолько плох, что весь проект будет основан на том, что мы называем 'Spaghetti Code'. Со временем проект будет становиться слишком большим, в зависимости от беспорядочной системы на основе строк, которая может быть чрезвычайно повторяющейся и длинной.
3. Непонимание ООП.
Как многие из вас знают, Java - это язык объектно-ориентированного программирования (ООП), который в значительной степени опирается на 4 основные концепции:
3.1 Плохой дизайн / структура кода
Как упоминалось в разделе «Повторяющиеся блоки кода», если ваш проект полностью полагается на плохо спроектированную кодовую базу, вам будет сложно поддерживать свой код в будущем. Ваш код станет беспорядочным, с ним будет сложно работать, и вам в конечном итоге придется постоянно возвращаться назад, чтобы каким-то чудом заставить ваш код функционировать должным образом. Ваш окончательный проект должен быть максимально дружелюбным к объектно-ориентированному программированию, иначе вам может быть сложно поддерживать свой проект, поскольку вы продолжите добавлять новые функции.
3.2 Весь код в одном классе
К сожалению, это наблюдается так же часто, как и плохой дизайн кода. Если ваш плагин достаточно простой - например, выводит сообщения о входе и выходе игрока на сервер, то в этом нет ничего страшного. В ином же случае можно смело заявить, что вы не понимаете ООП, не желаете учиться и не можете правильно организовать проект. Если весь код вашего проекта размещён в одном классе - начните перемещать / группировать код в разные классы и модулируйте свой проект. Слушатели могут быть сгруппированы в новые классы и вынесены в отдельный пакет, команды - в их собственные отдельные исполнители и отдельный пакет и т.д. для очистки кода и улучшения стиля программирования.
4. Отсутствие базовых знаний о Java.
Наконец, одна из вещей, которую люди обычно упускают из виду, - это базовые знания самой Java.
Конечно, у каждого свои предпочтения, но есть минимальный стандарт кода, установленный Oracle, которому вы должны следовать. Вот некоторые примеры:
5. Вывод
Если у вас проблемы с пониманием базовых концепций Java- сделайте шаг назад, чтобы изучить язык, прежде чем продолжать программировать плагины.
Это очень поможет вам в дальнейшем пересмотреть свой взгляд на написание кода.
Если у кого-то возникли дополнительные вопросы или вы считаете что я что-то пропустил в списке выше - дайте мне знать, я постараюсь добавить это в тему.
Надеюсь, это небольшое руководство помогло вам.
Возможно, вы сможете решить свой вопрос при прочтении этой темы.
1. Static Abuse
Речь о ключевом слове 'static'. Любимый модификатор каждого новичка, потому что он позволяет легко получить доступ к методу или полю из другого класса! Что может быть проще, чем просто сделать метод или переменную статичной, чтобы вы могли использовать их в других своих классах? Смысл в том, что ключевое слово 'static' предназначено не для этого. Слишком часто я вижу, что 'static' используется для доступа к полю из другого класса, особенно к реализациям Collection и Map, а также к экземпляру основного класса. Это частая ошибка новых разработчиков, которая создает серьезные проблемы с точки зрения дизайна кода и гибкости в будущем.
Не поймите меня неправильно, всегда есть место для использования 'static', и вот некоторые из распространенных ситуаций, в которых это приемлемо:
- Создание постоянного поля:
Константы гарантируют, что это значение всегда будет равно 42, несмотря ни на что.Java:
public static final int CONSTANT = 42;
Если требуется единственный (неизменяемый) экземпляр объекта, лучше всего, чтобы он был статичным и постоянным ('final'). - Объявление (правильного) шаблона singleton
Если необходимо принудительно использовать только один экземпляр класса, используйте паттерн 'Singleton'.
Не «Мне постоянно нужен экземпляр этого обьекта, давайте сделаем статический геттер». Это НЕ синглтон. - 'Util' методы
Распространенной особенностью, которую люди часто путают со статическим злоупотреблением, являются служебные методы.
Метод, который вообще не требует экземпляра и существует исключительно с целью предоставления полезности на протяжении всего проекта, может быть объявлен как статический.
1.1 Синглтоны
Синглтоны являются предметом огромных дискуссий, особенно с учетом того, что основной класс (тот, который расширяет JavaPlugin) является синглтоном.
Я часто вижу, как люди защищают свое использование статических полей / геттеров в основном классе, потому что это синглтон. JavaPlugin имеет метод для получения одноэлементного экземпляра вашего основного класса, JavaPlugin#getPlugin(Class <T extends JavaPlugin>). Если вы действительно хотите использовать аргумент, что основной класс является синглтоном, поэтому создание статического поля / метода для доступа к экземпляру - это нормально, тогда, по крайней мере, используйте для этого соответствующий метод.
Приведенный выше аргумент следует воспринимать с недоверием. MinecraftServer (класс, который управляет обычным сервером Minecraft) также является синглтоном и имеет статический метод получения. Как и клиентский класс «Майнкрафт». Тем не менее, хотя у них есть статические методы для получения экземпляра, внедрение зависимостей конструктора используется там, где это возможно. Это четко определенные 'Singleton' шаблоны. Когда дело доходит до основного класса плагина, статический геттер следует использовать как последнее средство, когда внедрение зависимостей либо не имеет смысла, либо его невозможно использовать. Этот аргумент предназначен в первую очередь для начинающих, которым не хватает базового понимания ключевого слова 'static'.
Помимо основного класса, синглтоны следует использовать только тогда, когда должен применяться только один экземпляр класса. Например, если у вас есть исполняемый файл, который должен быть выполнен в вашем методе onEnable(), но вы хотите, чтобы он выполнялся только один раз вашим собственным плагином, синглтон, вероятно, будет способом гарантировать, что никакой другой ресурс не поддерживает его выполнения. Ключевое слово "принудительно". Если вы просто создаете статическое поле и метод получения, это НЕ обеспечивает применение 'Singleton' шаблона. Перед использованием паттерна рекомендуется хорошо ознакомиться с тем, как и в каких случаях лучше всего использовать этот паттерн.
2. Повторяющиеся блоки кода (принцип DRY)
Многим новичкам не хватает базовых знаний в области программирования и они совершают ошибку, нарушая принцип «Не повторяйся» ('DRY - Don't repeat yourself'). Как следует из названия, если вам нужно постоянно копировать и вставлять код с разными переменными или параметрами метода, вы, вероятно, делаете что-то не так, и вам нужно пересмотреть структуру вашего кода.
Java:
public void spawnPet(String pet, Location location) {
if (pet.equals("Bunny")) {
Entity entity = location.getWorld().spawnEntity(location, EntityType.RABBIT);
entity.setDisplayName("Bunny Pet");
} else if (pet.equals("Cow")) {
Entity entity = location.getWorld().spawnEntity(location, EntityType.COW);
entity.setDisplayName("Cow Pet");
}
// и ещё 20+ подобных блоков
}3. Непонимание ООП.
Как многие из вас знают, Java - это язык объектно-ориентированного программирования (ООП), который в значительной степени опирается на 4 основные концепции:
- Абстракция: раскрытие конкретных и основных функций объекта при сокрытии менее важной или конфиденциальной информации от конечного пользователя.
- Инкапсуляция: скрытие значений от публичного доступа и создание геттеров / сеттеров, чтобы заставить пользователей взаимодействовать с вашими данными в более безопасном и контролируемом состоянии. Изменчивость и контроль данных.
- Наследование: понимание того, что классы могут наследовать поля и методы от родительских классов.
- Полиморфизм: изменение значения или функциональности метода во время выполнения из родительского класса. Полное переопределение метода при использовании другой реализации.
3.1 Плохой дизайн / структура кода
Как упоминалось в разделе «Повторяющиеся блоки кода», если ваш проект полностью полагается на плохо спроектированную кодовую базу, вам будет сложно поддерживать свой код в будущем. Ваш код станет беспорядочным, с ним будет сложно работать, и вам в конечном итоге придется постоянно возвращаться назад, чтобы каким-то чудом заставить ваш код функционировать должным образом. Ваш окончательный проект должен быть максимально дружелюбным к объектно-ориентированному программированию, иначе вам может быть сложно поддерживать свой проект, поскольку вы продолжите добавлять новые функции.
3.2 Весь код в одном классе
К сожалению, это наблюдается так же часто, как и плохой дизайн кода. Если ваш плагин достаточно простой - например, выводит сообщения о входе и выходе игрока на сервер, то в этом нет ничего страшного. В ином же случае можно смело заявить, что вы не понимаете ООП, не желаете учиться и не можете правильно организовать проект. Если весь код вашего проекта размещён в одном классе - начните перемещать / группировать код в разные классы и модулируйте свой проект. Слушатели могут быть сгруппированы в новые классы и вынесены в отдельный пакет, команды - в их собственные отдельные исполнители и отдельный пакет и т.д. для очистки кода и улучшения стиля программирования.
4. Отсутствие базовых знаний о Java.
Наконец, одна из вещей, которую люди обычно упускают из виду, - это базовые знания самой Java.
Конечно, у каждого свои предпочтения, но есть минимальный стандарт кода, установленный Oracle, которому вы должны следовать. Вот некоторые примеры:
- Имена классов, методов, пакетов и переменных имеют свои собственные схемы именования.
- Классы должны быть названы в схеме UpperCamelCase
- Названия методов должны быть указаны в схеме lowerCamelCase.
- Пакеты должны быть названы строчными буквами и в обратном порядке под вашим доменом (например, com.google.<project>)
- Если у вас нет домена, используйте com.github.<username>.<project> или me.<username>.<project>
- Поля должны быть названы в схеме lowerCamelCase, исключая случаи когда поле содержит модификаторы 'static final' - в таком случае имя поле должно быть написано по схеме UPPER_CASE.
- Непонимание использования и недостатков различных модификаторов доступа - 'public' / 'private' / 'protected' / 'static' / 'final' и т.д.
- Постоянное повторение одного и того же кода вместо создания метода для выполнения общих функций
- Слепое приведение объектов без предварительной проверки instanceof
- Использование примитивных классов-оболочек, а не самих примитивов (например, Integer вместо int)
5. Вывод
Если у вас проблемы с пониманием базовых концепций Java- сделайте шаг назад, чтобы изучить язык, прежде чем продолжать программировать плагины.
Это очень поможет вам в дальнейшем пересмотреть свой взгляд на написание кода.
Если у кого-то возникли дополнительные вопросы или вы считаете что я что-то пропустил в списке выше - дайте мне знать, я постараюсь добавить это в тему.
Надеюсь, это небольшое руководство помогло вам.
Последнее редактирование: