Внутренние классы (сокрытие реализации)

@Arvien · Регистрация: 26.03.2015

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

Когда мы создаем внутренний класс и объявляем его поля/методы приватными, они все равно доступны напрямую из внешнего класса. Есть ли способ скрывать поля и методы внутренних классов от внешних?

@Sqgvek · 21.12.2015, 00:17

нет, думаю здесь был бы уместен вопрос так ли это необходимо ?

@Arvien · 21.12.2015, 00:30 **[ТС]**

Мне это не шипко необходимо, т.к. программа не очень большая. Но просто дело в том, что когда мы создаем объект, то хотим, чтобы у него был интерфейс, который позволяет взаимодействовать с объектом, посылать объекту сообщения, и скрытая часть, чтобы объект хранил свое состояние и внутренние механизмы поведения. А тут эта логика оказывается нарушена. Можно например случайно прочитать поле напрямую а не через метод, который при этом меняет состояние объекта, и получить труднообнаружимую ошибку.

@KEKCoGEN · 21.12.2015, 00:54

Arvien, когда программист пишет внутренний класс, он имеет в виду что функционал этого класса тесно связан с внешним классом то есть оба класса делают одно итоже \ дополняют друг друга. Разделение обычно происходит больше из-за удобства. Таким образом нет смысла скрывать внутреннюю имплементацию вложенного класса. Если это не ваш случай, значит вы ошиблись когда делали класс внутренним.

@Arvien · 21.12.2015, 02:23 **[ТС]**

Есть еще одна возможность ) Мб я просто не программист! )))

@KEKCoGEN · 21.12.2015, 11:09

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

Мб я просто не программист!

тогда не понятно почему вас вообще это интересует.

@Arvien · 21.12.2015, 23:23 **[ТС]**

В таком случае у меня вопрос, касающийся правил хорошего тона в программировании на Java. Добиться того, чего я хочу можно, создав пакет с одним публичным классом, а все классы, которые были описаны как внутренние для этого класса, вытащить и сделать видимыми только на уровне пакета. И так поступить со всеми классами, которые у меня содержали внутренние классы (переделать их в пакеты). Стоит ли так делать? Получатся пакеты, состоящие из небольшого числа классов, публичный из которых только один. Это нормальная практика, или нужно просто в одном пакете лепить классы, пока свалка не станет слишком большой?

@KEKCoGEN · 21.12.2015, 23:45

Arvien, лучше скажите какую задачу вы пытаетесь решить используя вложенные классы

@Arvien · 22.12.2015, 02:04 **[ТС]**

Именно сами вложенные классы мне не нужны. Я пытаюсь понять, как мне правильно структурировать проект. В моем представлении его структура должна быть иерархична. Т.е. когда я пишу класс, который решает сложную задачу, и у меня в процессе написания кода возникает необходимость разбить эту задачу на подзадачи, то я хочу, чтобы описание классов, которые я создаю для этого, были скрыты. Я хочу создать самодостаточную единицу, ответственную за решение определенной задачи, а все, что она для этого делает, должно быть скрыто внутри. Должен получиться черный ящик, предоставляющий интерфейс для взаимодействия с собой, и прячущий реализацию. Я предполагал, что вложенные классы для того и существуют, чтобы составить сложный объект из простых, спрятав описание этих объектов внутри. Но оказывается это не так. Т.к. содержимое внутренних классов полностью доступно внешним, то внутренние классы получаются уже не объектами. Возникает обычная каша, в которой ответственность за то чтобы не залезть не туда и не сделать не то ложится на плечи программиста и апеллирует к его внимательности. Вот я и пытаюсь понять, как же тогда мне создавать эти независимые единицы.

Добавлено через 13 минут
Обычная композиция для решения этой задачи не подходит. Хотя мы собираем объект из более простых, описание всех этих объектов как бы вываливается наружу. В итоге глядя на проект сложно понять что там и для чего существует. Огромное количество классов, отвечающих за решение совершенно разных задач, просто свалено в кучу. Ни о какой иерархии тогда речи не идет и структура проекта совершенно не ясна.

@Sqgvek · 22.12.2015, 02:28

для этого обычно структуру которую необходимо инкапсулировать помещают в отдельный файл, таким образом из вне будет доступен интерфейс только public класса

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class A{
    private B b;
    public A(){
      b=new B();
    }
   
    public method...(){
        ...
        b.method1(); 
        ... 
    }
}
 
class B{
   int method1();
}

@Arvien · 22.12.2015, 03:44 **[ТС]**

К сожалению нет =( Классы без модификатора public будут доступны из других файлов этого же пакета. Чтобы их скрыть надо создавать отдельный пакет. Тогда действительно снаружи будет доступен только public класс. Но что, если внутри пакета мне надо скрыть реализацию одного из классов? Я уже получается не могу этого сделать, ведь если я создам еще один пакет, где этот класс будет public, а остальные нет, то подключить этот пакет сможет кто угодно, а не только мой первый пакет. А значит я уже не смогу полностью поменять реализацию этого вспомогательного пакета, потому что если им теоретически можно воспользоваться, то нет гарантий, что кто-то другой им не пользовался и его код не крашнется, если я полностью изменю поведение паблик класса либо его интерфейс. Кошмар какой-то.

@KEKCoGEN · 22.12.2015, 09:02

Arvien, у вас какая то паранойа. Ненадо городить вложенные классы. Если хотите создать логическую единицу которая решает некую задачу, напишите это решение и запакуйте в jar. Затем этот джар можно импортировать в любой проект, там где нужно будет пользоватся этой либой. Внутри джара разделяйте классы на пакеты если это нужно.
Пройдитесь по maven repository, скачайте оттуда джары и посмотрите как они устроенны.

Pablito · 22.12.2015, 12:12

Java
1
2
3
4
5
class A {
    private static class B {
        int i = 42;
    }
}

поле i не будет видно из внешнего класса
я ответил на вопрос из начала этой бессмысленной темы?

@turbanoff · 22.12.2015, 12:45

Паблито, Как это не будет?

Java
1
2
3
4
5
6
7
8
9
class A {
    private static class B {
        int i = 42;
    }
 
    public static void main(String[] args) {
        new B().i = 213;
    }
}

Всё отлично компилируется

Pablito · 22.12.2015, 14:10

Не по теме:

вот черт, точно, не подумал

Добавлено через 1 час 19 минут
turbanoff, меня бомбануло

а если так?

Java
1
2
3
4
5
6
7
class Weird {
    interface I {
        class A {
            private int i = 42;
        }
    }
}

@turbanoff · 22.12.2015, 17:04

И всё равно будет доступен.

Pablito · 22.12.2015, 17:12

как?
это выше моего понимания, но очень интересно

@turbanoff · 22.12.2015, 17:29

Вроде всё как обычно. A - это обычный static inner class

Java
1
2
3
    public static void main(String[] args) {
        new I.A().i = 234;
    }

@Arvien · 22.12.2015, 22:33 **[ТС]**

KEKCoGEN, я уже не собираюсь городить внутренние классы, т.к. они не решают задачу, которая мне необходима. Пакеты тоже не решают ее. Почему? Я уже написал выше.

Долго гуглил. К сожалению, на java то что мне нужно вообще не может быть сделано.

Не для того чтобы устроить тут холивар, но я проверил, как дела с внутренними классами обстоят в С#, в силу большого сходства этих языков. Там все в порядке: приватные члены внутреннего класса не доступны внешнему классу. Зависть (((

Я прочитал про внутренние классы множество статей и пару глав посвященных им в книгах по java, но ни разу не встретил упоминания о том, что приватные поля внутреннего класса доступны внешнему. А мне бы очень хотелось понять, зачем это вообще может быть нужно. Какой логикой руководствовались создатели языка, когда принимали такое антиинтуитивное решение, которое лично у меня вызывает глубокое разочарование в языке.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	Установка Emscripten SDK (emsdk) и CMake на Windows для сборки C и C++ приложений в WebAssembly (Wasm) 8Observer8 30.01.2026 Чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. Система контроля версиями Git. . .	Подключение Box2D v3 к SDL3 для Android: физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .
Загрузка PNG с альфа-каналом на SDL3 для Android: с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 28.01.2026 Содержание блога SDL3 имеет собственные средства для загрузки и отображения PNG-файлов с альфа-каналом и базовой работы с ними. В этой инструкции используется функция SDL_LoadPNG(), которая. . .	Загрузка PNG с альфа-каналом на SDL3 для Android: с помощью SDL3_image 8Observer8 27.01.2026 Содержание блога SDL3_image - это библиотека для загрузки и работы с изображениями. Эта пошаговая инструкция покажет, как загрузить и вывести на экран смартфона картинку с альфа-каналом, то есть с. . .	Влияние грибов на сукцессию anaschu 26.01.2026 Бифуркационные изменения массы гриба происходят тогда, когда мы уменьшаем массу компоста в 10 раз, а скорость прироста биомассы уменьшаем в три раза. Скорость прироста биомассы может уменьшаться за. . .	Воспроизведение звукового файла с помощью SDL3_mixer при касании экрана Android 8Observer8 26.01.2026 Содержание блога SDL3_mixer - это библиотека я для воспроизведения аудио. В отличие от инструкции по добавлению текста код по проигрыванию звука уже содержится в шаблоне примера. Нужно только. . .

@Arvien 0 / 0 / 0 Регистрация: 26.03.2015 Сообщений: 9

	Внутренние классы (сокрытие реализации) 20.12.2015, 23:53. Показов 2703. Ответов 18 Метки нет (Все метки) Когда мы создаем внутренний класс и объявляем его поля/методы приватными, они все равно доступны напрямую из внешнего класса. Есть ли способ скрывать поля и методы внутренних классов от внешних? 0

@Sqgvek 1 / 1 / 0 Регистрация: 18.12.2015 Сообщений: 17
	21.12.2015, 00:17
	нет, думаю здесь был бы уместен вопрос так ли это необходимо ? 0

@Arvien 0 / 0 / 0 Регистрация: 26.03.2015 Сообщений: 9
	21.12.2015, 00:30 [ТС]
	Мне это не шипко необходимо, т.к. программа не очень большая. Но просто дело в том, что когда мы создаем объект, то хотим, чтобы у него был интерфейс, который позволяет взаимодействовать с объектом, посылать объекту сообщения, и скрытая часть, чтобы объект хранил свое состояние и внутренние механизмы поведения. А тут эта логика оказывается нарушена. Можно например случайно прочитать поле напрямую а не через метод, который при этом меняет состояние объекта, и получить труднообнаружимую ошибку. 0

@KEKCoGEN 2399 / 2224 / 565 Регистрация: 28.12.2010 Сообщений: 8,672
	21.12.2015, 00:54
	Arvien, когда программист пишет внутренний класс, он имеет в виду что функционал этого класса тесно связан с внешним классом то есть оба класса делают одно итоже \ дополняют друг друга. Разделение обычно происходит больше из-за удобства. Таким образом нет смысла скрывать внутреннюю имплементацию вложенного класса. Если это не ваш случай, значит вы ошиблись когда делали класс внутренним. 0

@Arvien 0 / 0 / 0 Регистрация: 26.03.2015 Сообщений: 9
	21.12.2015, 02:23 [ТС]
	Есть еще одна возможность ) Мб я просто не программист! ))) 0

@Arvien 0 / 0 / 0 Регистрация: 26.03.2015 Сообщений: 9
	21.12.2015, 23:23 [ТС]
	В таком случае у меня вопрос, касающийся правил хорошего тона в программировании на Java. Добиться того, чего я хочу можно, создав пакет с одним публичным классом, а все классы, которые были описаны как внутренние для этого класса, вытащить и сделать видимыми только на уровне пакета. И так поступить со всеми классами, которые у меня содержали внутренние классы (переделать их в пакеты). Стоит ли так делать? Получатся пакеты, состоящие из небольшого числа классов, публичный из которых только один. Это нормальная практика, или нужно просто в одном пакете лепить классы, пока свалка не станет слишком большой? 0

@KEKCoGEN 2399 / 2224 / 565 Регистрация: 28.12.2010 Сообщений: 8,672
	21.12.2015, 23:45
	Arvien, лучше скажите какую задачу вы пытаетесь решить используя вложенные классы 0

@Arvien 0 / 0 / 0 Регистрация: 26.03.2015 Сообщений: 9
	22.12.2015, 02:04 [ТС]
	Именно сами вложенные классы мне не нужны. Я пытаюсь понять, как мне правильно структурировать проект. В моем представлении его структура должна быть иерархична. Т.е. когда я пишу класс, который решает сложную задачу, и у меня в процессе написания кода возникает необходимость разбить эту задачу на подзадачи, то я хочу, чтобы описание классов, которые я создаю для этого, были скрыты. Я хочу создать самодостаточную единицу, ответственную за решение определенной задачи, а все, что она для этого делает, должно быть скрыто внутри. Должен получиться черный ящик, предоставляющий интерфейс для взаимодействия с собой, и прячущий реализацию. Я предполагал, что вложенные классы для того и существуют, чтобы составить сложный объект из простых, спрятав описание этих объектов внутри. Но оказывается это не так. Т.к. содержимое внутренних классов полностью доступно внешним, то внутренние классы получаются уже не объектами. Возникает обычная каша, в которой ответственность за то чтобы не залезть не туда и не сделать не то ложится на плечи программиста и апеллирует к его внимательности. Вот я и пытаюсь понять, как же тогда мне создавать эти независимые единицы. Добавлено через 13 минут Обычная композиция для решения этой задачи не подходит. Хотя мы собираем объект из более простых, описание всех этих объектов как бы вываливается наружу. В итоге глядя на проект сложно понять что там и для чего существует. Огромное количество классов, отвечающих за решение совершенно разных задач, просто свалено в кучу. Ни о какой иерархии тогда речи не идет и структура проекта совершенно не ясна. 0

@Arvien 0 / 0 / 0 Регистрация: 26.03.2015 Сообщений: 9
	22.12.2015, 03:44 [ТС]
	К сожалению нет =( Классы без модификатора public будут доступны из других файлов этого же пакета. Чтобы их скрыть надо создавать отдельный пакет. Тогда действительно снаружи будет доступен только public класс. Но что, если внутри пакета мне надо скрыть реализацию одного из классов? Я уже получается не могу этого сделать, ведь если я создам еще один пакет, где этот класс будет public, а остальные нет, то подключить этот пакет сможет кто угодно, а не только мой первый пакет. А значит я уже не смогу полностью поменять реализацию этого вспомогательного пакета, потому что если им теоретически можно воспользоваться, то нет гарантий, что кто-то другой им не пользовался и его код не крашнется, если я полностью изменю поведение паблик класса либо его интерфейс. Кошмар какой-то. 0

@KEKCoGEN 2399 / 2224 / 565 Регистрация: 28.12.2010 Сообщений: 8,672
	22.12.2015, 09:02
	Arvien, у вас какая то паранойа. Ненадо городить вложенные классы. Если хотите создать логическую единицу которая решает некую задачу, напишите это решение и запакуйте в jar. Затем этот джар можно импортировать в любой проект, там где нужно будет пользоватся этой либой. Внутри джара разделяйте классы на пакеты если это нужно. Пройдитесь по maven repository, скачайте оттуда джары и посмотрите как они устроенны. 0

@turbanoff 4094 / 3828 / 745 Регистрация: 18.05.2010 Сообщений: 9,331 Записей в блоге: 12
	22.12.2015, 17:04
	И всё равно будет доступен. 0

Pablito 2884 / 2296 / 769 Регистрация: 12.05.2014 Сообщений: 7,978
	22.12.2015, 17:12
	как? это выше моего понимания, но очень интересно 0

@Arvien 0 / 0 / 0 Регистрация: 26.03.2015 Сообщений: 9
	22.12.2015, 22:33 [ТС]
	KEKCoGEN, я уже не собираюсь городить внутренние классы, т.к. они не решают задачу, которая мне необходима. Пакеты тоже не решают ее. Почему? Я уже написал выше. Долго гуглил. К сожалению, на java то что мне нужно вообще не может быть сделано. Не для того чтобы устроить тут холивар, но я проверил, как дела с внутренними классами обстоят в С#, в силу большого сходства этих языков. Там все в порядке: приватные члены внутреннего класса не доступны внешнему классу. Зависть ((( Я прочитал про внутренние классы множество статей и пару глав посвященных им в книгах по java, но ни разу не встретил упоминания о том, что приватные поля внутреннего класса доступны внешнему. А мне бы очень хотелось понять, зачем это вообще может быть нужно. Какой логикой руководствовались создатели языка, когда принимали такое антиинтуитивное решение, которое лично у меня вызывает глубокое разочарование в языке. 0