Стиль написания кода

@xPANICx · Регистрация: 31.12.2015

Студворк — интернет-сервис помощи студентам

Имеется внешний класс. Внутри этого внешнего класса объявлен private static класс. Клиенты внешнего класса не имеют представления о существовании внутреннего класса, с инкапсуляцией у внешнего класса полный порядок.
Внутренний класс не имеет геттеров и сеттеров, код внешнего класса обращается к его полям напрямую. Вопрос в следующем: является ли подобный стиль приемлемым? Или, немного переформулировав, как бы вы, будучи потенциальным работодателем, отреагировали бы на подобный стиль написания кода потенциального соискателя?
С одной стороны, имея геттеры и сеттеры, я в любой момент смогу вынести внутренний класс за пределы внешнего без особых проблем. С другой стороны, не будет ли код в данном случае too verbose? Какой подход избрать?

@korvin_ · 26.02.2017, 17:23

Сообщение от xPANICx

является ли подобный стиль приемлемым?

Зависит от роли вложенного класса.

Сообщение от xPANICx

как бы вы, будучи потенциальным работодателем, отреагировали бы на подобный стиль написания кода потенциального соискателя?

См. выше.

Сообщение от xPANICx

С одной стороны, имея геттеры и сеттеры, я в любой момент смогу вынести внутренний класс за пределы внешнего без особых проблем

Во-первых, http://www.javaworld.com/artic... -evil.html
Во-вторых, исходить нужно из роли класса, если он фактически выполняет роль структуры с полями, то при выносе достаточно будет сделать поля публичными, например.
В-третьих, если предполагается, что этот класс может быть полезным вынести, лучше сразу его вынести и объявить package-visible и раставить модификаторы доступа к его полям и методам соответствующим образом.

@xPANICx · 27.02.2017, 08:54 **[ТС]**

korvin_, ссылка была полезной. Спасибо!

Новые блоги и статьи Все статьи Все блоги /
Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: при выборе сотрудника (справочник Сотрудники) в ТЧ документа. . .	Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .	модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .
Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .	Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20% kYBz3eJf3jQ	Дальние перспективы сервера - слоя сети с космологическим дизайном интефейса карты и логики. Hrethgir 07.04.2026 Дальнейшее ближайшее планирование вывело к размышлениям над дальними перспективами. И вот тут может быть даже будут нужны оценки специалистов, так как в дальних перспективах всё может очень сильно. . .	Горе от ума kumehtar 07.04.2026 Эта мне ментальная установка, что вот прямо сейчас, мол, мне для полного счастья не хватает (нужное вписать), и когда я этого достигну - тогда и полный кайф. Одна из самых сильных ловушек на пути. . . .

@xPANICx 21 / 21 / 2 Регистрация: 31.12.2015 Сообщений: 100

	Стиль написания кода 26.02.2017, 12:42. Показов 995. Ответов 2 Метки нет (Все метки) Имеется внешний класс. Внутри этого внешнего класса объявлен private static класс. Клиенты внешнего класса не имеют представления о существовании внутреннего класса, с инкапсуляцией у внешнего класса полный порядок. Внутренний класс не имеет геттеров и сеттеров, код внешнего класса обращается к его полям напрямую. Вопрос в следующем: является ли подобный стиль приемлемым? Или, немного переформулировав, как бы вы, будучи потенциальным работодателем, отреагировали бы на подобный стиль написания кода потенциального соискателя? С одной стороны, имея геттеры и сеттеры, я в любой момент смогу вынести внутренний класс за пределы внешнего без особых проблем. С другой стороны, не будет ли код в данном случае too verbose? Какой подход избрать? 0

@xPANICx 21 / 21 / 2 Регистрация: 31.12.2015 Сообщений: 100
	27.02.2017, 08:54 [ТС]
	korvin_, ссылка была полезной. Спасибо! 0