какая часть хранимого состояния объекта используется для реализации каждого интерфейса.
Вообще да. Но если такое состояние является частью основной логики класса то не вижу в его хранении ничего страшного. А когда начнутся трудности с пониманием то я таки воспользуюсь вашим советом и вынесу реализации интерфейсов в отдельные классы.
Аннотации никак не уберегут Вас от конфликта имён
Согласен на 100%, но эти ситуации довольно редкие.
вы указываете тип нужного идентификатора (строка, число, UUID, полоски зебры), отдельно указывается алгоритм проверки, что идентификатор свободен.
Будь алгоритм проверки чуть сложнее (хотя бы 3 строки), я бы, наверное, так и сделал.
А на Stackoverflow иногда бывают очень хорошие решения, но очень редко их можно использовать как есть, в основном приходится еще дополнительно подпиливать. Так что копипаст меня вряд ли поглотит)
но только предварительно установить специальный плагин нужно
Сам бы я не додумался даже поискать такой плагин, а теперь буду знать.
Рефлексия это да, иногда сильно упрощает жизнь, но если решил использовать подумай, может не все таки стоит)
А пример в конце раздела «Постановка задачи» не подходит? Там в классе UnitManager есть метод isValueFree() помеченный @Implements. Или я неправильно понял о каком примере идет речь?
Дело в вкуса. Лично мне не нравится плодить дополнительные объекты, они меня запутывают еще больше.
Про getMagicValue() согласен, раньше именно так и делал. Но наличие аннотации над методом уже говорит, что он не простой. Слово класс, уверен, подсвечивается всеми IDE как ключевое слово языка. Все это позволяет понять, что метод для реализации интерфейса даже не читая его названия!
Про инкапсуляцию не согласен. Валидность идентификатора зависит от внутренней реализации UnitManagerа и RotateCounter, который, кстати, я и использую в нескольких местах, ничего не должен знать об ее особенностях.
Дальше сложнее. Честно говоря, я не знаю что такое SOF (и гугл выдает нечто вроде Special Operations Force).
Eclipse-проект нельзя просто так взять и запустить в другой IDE. А в другом Eclipse без проблем. К тому же, в коде или сборке .jar нет ничего eclipse-специфического. Как будет время надо будет сделать через gradle.
Про reflection тоже не понятно. Это же не рефлексия. Рефлексия это получение информации о типе на этапе выполнения. А это обработка на этапе компиляции.
Про JavaDoc согласен. Это красиво и без танцев с бубном. Но огорчает, что в C# эта возможность встроена в язык, а в Java нет.
За опечатку отдельное спасибо. Я отредактировал тот абзац и постарался пояснить подробнее. Если не трудно, глянь, пожалуйста, абзац, стало ли понятнее?
Ага, написать Implement как съесть печеньку и не запить чайком, вроде и вкусно, но чего-то не хватает. Но и существующая аннотация Override и совпадение имени аннотации с ключевым слово языка немного режет глаз.
"О том, как можно улучшить свою производительность – здесь." – а ссылочки то нет)
Согласен на 100%, но эти ситуации довольно редкие.
А на Stackoverflow иногда бывают очень хорошие решения, но очень редко их можно использовать как есть, в основном приходится еще дополнительно подпиливать. Так что копипаст меня вряд ли поглотит)
Сам бы я не додумался даже поискать такой плагин, а теперь буду знать.
Рефлексия это да, иногда сильно упрощает жизнь, но если решил использовать подумай, может не все таки стоит)
За статью спасибо, почитаю на досуге.
Про getMagicValue() согласен, раньше именно так и делал. Но наличие аннотации над методом уже говорит, что он не простой. Слово класс, уверен, подсвечивается всеми IDE как ключевое слово языка. Все это позволяет понять, что метод для реализации интерфейса даже не читая его названия!
Про инкапсуляцию не согласен. Валидность идентификатора зависит от внутренней реализации UnitManagerа и RotateCounter, который, кстати, я и использую в нескольких местах, ничего не должен знать об ее особенностях.
Дальше сложнее. Честно говоря, я не знаю что такое SOF (и гугл выдает нечто вроде Special Operations Force).
Eclipse-проект нельзя просто так взять и запустить в другой IDE. А в другом Eclipse без проблем. К тому же, в коде или сборке .jar нет ничего eclipse-специфического. Как будет время надо будет сделать через gradle.
Про reflection тоже не понятно. Это же не рефлексия. Рефлексия это получение информации о типе на этапе выполнения. А это обработка на этапе компиляции.
Про JavaDoc согласен. Это красиво и без танцев с бубном. Но огорчает, что в C# эта возможность встроена в язык, а в Java нет.
За опечатку отдельное спасибо. Я отредактировал тот абзац и постарался пояснить подробнее. Если не трудно, глянь, пожалуйста, абзац, стало ли понятнее?