Java - внутренний частный класс только для инкапсуляции конструкции для внешнего класса

Является ли хорошей практикой иметь класс, то есть внутренний класс (не статический), единственной задачей которого является создание и инициация объекта внешнего класса (в ее конструкторе)? Время жизни этого класса будет равно времени жизни конструктора внешнего класса.

Вот пример:

OuterClass {
    // (...fields here...)
    private ConstructClass {
        // (...some useful methods and fields here...)
        public ConstructClass(String param1, int param2, ...) {
           // (...construction of OuterClass here...)
        }
    }
    public OuterClass(String param1, int param2, ...) {
        new ConstructClass(param1, param2, ...);
    }
}

person Krzysztof Stanisławek    schedule 07.06.2014    source источник
comment
Это то, что вам нужно? Почему вы хотите это сделать?   -  person Sotirios Delimanolis    schedule 07.06.2014
comment
Да, для удобства. OuterClass очень просто, строится только сложная часть. Мне не нужны ненужные поля и методы в OuterClass.   -  person Krzysztof Stanisławek    schedule 07.06.2014
comment
Я не вижу в этом смысла. Либо используйте шаблон строителя, либо заводской шаблон. Это запутанная путаница двух.   -  person Boris the Spider    schedule 07.06.2014
comment
разве это не работа для фабричного образца?   -  person T.G    schedule 07.06.2014
comment
Что может сделать добавленный внутренний класс и его конструктор, чего не может внешний класс?   -  person Sotirios Delimanolis    schedule 07.06.2014
comment
Инкапсулировать код — поля и методы, которые нужны только в конструкторе. У меня просто не может быть методов, видимых для методов, которые существуют в GNU-C и функциональных языках, поэтому я понял, что могу получить его, используя внутренний класс.   -  person Krzysztof Stanisławek    schedule 07.06.2014
comment
Так почему бы вам не поместить их в конструктор внешнего класса? Можете привести реальный пример?   -  person Sotirios Delimanolis    schedule 07.06.2014
comment
Я не могу определять методы в конструкторе - все дело в этом. Я пытаюсь подражать стилю кодирования, который я могу использовать в GNU C и функциональных языках, где я могу определить метод, где захочу.   -  person Krzysztof Stanisławek    schedule 07.06.2014
comment
Просто напишите private методов. Эти методы являются частью процедуры инициализации внешнего класса, а не внутреннего класса.   -  person Sotirios Delimanolis    schedule 07.06.2014
comment
Я отредактировал комментарий выше - все дело в том, чтобы разместить код на том месте, которому этот код принадлежит. Эти частные методы и поля не используются после построения, так почему они должны быть там? И они действительно заняли бы 4/5 определения класса: P.   -  person Krzysztof Stanisławek    schedule 07.06.2014
comment
Похоже, ваш класс пытается сделать слишком много, если это так.   -  person JonK    schedule 07.06.2014


Ответы (1)


Мне кажется, что вы пытались заново открыть шаблон конструктора :). Вы подошли довольно близко к этому, однако было бы намного лучше, если бы вы изменили свой конструктор, чтобы установить только отдельные поля, а не создавать весь объект.

Создание билдера может привести к некоторому снижению эффективности (должна быть зарезервирована дополнительная память в jvm), но это может в значительной степени уменьшить количество различных параметризованных конструкторов, которые вам нужно создать - так код НАМНОГО понятнее. Стоит принять во внимание изменение вашего кода для выполнения парадигмы строителя, но окончательное решение остается за вами.

person TheMP    schedule 07.06.2014
comment
На мой взгляд, Конструктор ConstructClass слишком прост для строителя. - person Krzysztof Stanisławek; 07.06.2014
comment
Строитель? Каким образом? Как сборщик требует резерва памяти jvm? - person Val; 07.06.2014
comment
@Val: потому что вам нужен дополнительный объект. - person Oliver Charlesworth; 07.06.2014
comment
@OliCharlesworth Вы правы, вам понадобятся дополнительные 20 байт (не килограмм, не мега, не гига, простые байты) дополнительной памяти. Это едва ли возможно с настройками JVM по умолчанию. Вы правы, вам нужно зарезервировать дополнительную память. - person Val; 07.06.2014
comment
@Val: Конечно, но это складывается, если вы строите (скажем) миллионы объектов. - person Oliver Charlesworth; 07.06.2014
comment
@OliCharlesworth Что это складывается? Вы понимаете, что Builder прекращает свое существование, как только он закончил производить желаемый объект? Что происходит с объектами, которые выходят за рамки и восстанавливаются сборщиком мусора? О каких миллионах объектов вы говорите? Как можно проявлять двойные стандарты (если мы создаем миллион объектов без Buider, то нам нужен 1 МБ памяти, если мы создали их с помощью Buider, эти же объекты занимают 2 МБ памяти). Это двойные стандарты. Размер вашего объекта не должен зависеть от способа его создания. - person Val; 07.06.2014
comment
@Val: это зависит от того, когда GC решит начать работу. - person Oliver Charlesworth; 07.06.2014
comment
@Val Ну, действительно, я не совсем ясно выразился. Я думал о резервировании места для построителя, создании объекта, последующем освобождении места для построителя и т. д., что может использовать некоторое количество процессорного времени. Кроме того, вы должны зависеть от сборщика мусора, который запускается, когда это необходимо. - person TheMP; 07.06.2014
comment
@Krzysztof Stanisławek Если это слишком просто для строителя, нет необходимости использовать и внутренний класс построения. - person TheMP; 07.06.2014