Um construtor em Java pode ser privado?

Um construtor pode ser privado? Como um construtor privado é útil?

Sim, um construtor pode ser privado. Existem diferentes usos disso. Um tal uso é para o anti-padrão do projeto singleton , que eu recomendaria contra você usando. Outro uso mais legítimo é delegar construtores; você pode ter um construtor que tenha muitas opções diferentes que sejam realmente um detalhe de implementação, para torná-lo privado, mas depois os construtores restantes delegam a ele.

Como um exemplo de delegação de construtores, a class a seguir permite que você salve um valor e um tipo, mas só permite fazer isso para um subconjunto de tipos, portanto, tornar o construtor geral privado é necessário para garantir que apenas os tipos permitidos sejam usados . O construtor privado comum ajuda a reutilização de código.

 public class MyClass { private final String value; private final String type; public MyClass(int x){ this(Integer.toString(x), "int"); } public MyClass(boolean x){ this(Boolean.toString(x), "boolean"); } public String toString(){ return value; } public String getType(){ return type; } private MyClass(String value, String type){ this.value = value; this.type = type; } } 

Editar
Olhando para esta resposta de vários anos depois, gostaria de observar que esta resposta é incompleta e também um pouco extrema. Singletons são de fato um antipadrão e geralmente devem ser evitados sempre que possível; no entanto, há muitos usos de construtores privados além de singletons, e minha resposta nomeia apenas um.

Para dar mais alguns casos em que os construtores privados são usados:

  1. Para criar uma class não instanciável que é apenas uma coleção de funções estáticas relacionadas (isso é basicamente um singleton, mas se é stateless e as funções estáticas operam estritamente nos parâmetros em vez de no estado de class, essa abordagem não é tão irracional quanto a minha self anterior parece sugerir, embora o uso de uma interface que é injetada com dependência geralmente torna mais fácil manter a API quando a implementação requer um número maior de dependencies ou outras formas de contexto).

  2. Quando existem várias maneiras diferentes de criar o object, um construtor privado pode facilitar a compreensão das diferentes maneiras de construí-lo (por exemplo, o que é mais legível para você, new ArrayList(5) ou ArrayList.createWithCapacity(5) , ArrayList.createWithContents(5) , ArrayList.createWithInitialSize(5) ). Em outras palavras, um construtor privado permite que você forneça funções de fábrica cujos nomes sejam mais compreensíveis e, em seguida, tornar o construtor privado garante que as pessoas usem apenas os nomes mais óbvios. Isso também é comumente usado com o padrão de construtor . Por exemplo:

     MyClass myVar = MyClass .newBuilder() .setOption1(option1) .setOption2(option2) .build(); 

Eu esperava que alguém tivesse mencionado isso (o segundo ponto), mas … há três usos de construtores privados:

  • para impedir a instanciação fora do object, nos seguintes casos:

    • singleton
    • método de fábrica
    • class static-methods-only (utilitário)
    • class somente de constantes
      .
  • para evitar a sublimação (extensão). Se você criar apenas um construtor privado, nenhuma class poderá estender sua class, porque ela não pode chamar o construtor super() . Isso é algum tipo de sinônimo de final

  • construtores sobrecarregados – como resultado de methods de sobrecarga e construtores, alguns podem ser privados e alguns públicos. Especialmente no caso de haver uma class não pública que você usa em seus construtores, você pode criar um construtor público que crie uma instância dessa class e, em seguida, passe-a para um construtor privado.

Sim pode. Um construtor privado existiria para impedir que a class seja instanciada ou porque a construção ocorre apenas internamente, por exemplo, um padrão Factory. Veja aqui para mais informações.

Sim.

Isso é para que você possa controlar como a class é instanciada. Se você tornar o construtor privado e, em seguida, criar um método construtor visível que retorne instâncias da class, poderá limitar o número de criações (geralmente, garantir que exista exatamente uma instância) ou reciclar instâncias ou outras tarefas relacionadas à construção .

Fazendo new x() nunca retorna null , mas usando o padrão de fábrica, você pode retornar null , ou até mesmo retornar diferentes subtipos.

Você pode usá-lo também para uma class que não tenha membros ou propriedades de instância, apenas estáticos – como em uma class de function de utilitário.

Bem, se todos os seus methods em uma class são estáticos, então um construtor privado é uma boa idéia.

Construtores privados podem ser definidos no Java pelas seguintes razões

  1. Para ter controle sobre a instanciação dos objects Java, ele não permitirá criar uma instância de um object.

  2. Não permitirá que a class seja Subclass

  3. Isso tem uma vantagem especial ao implementar o Pattern singleton , os contstructors Private são usados ​​para ele e têm um controle na criação da instância para o aplicativo inteiro.

  4. quando você quer ter uma class com todas as constantes definidas e não requer mais sua instância, então declaramos essa class como um construtor privado.

Algumas razões pelas quais você pode precisar de um construtor privado: O construtor só pode ser acessado a partir do método de fábrica estática dentro da própria class. Singleton também pode pertencer a esta categoria. Uma class de utilitário , que contém apenas methods estáticos.

Sim.

Um construtor privado é usado para impedir a boot de instâncias, como a class final Math usada em java. Singleton também usa construtor privado

Sim. A class pode ter um construtor privado. Até mesmo a class abstrata pode ter um construtor privado.

Ao tornar o construtor privado, impedimos que a class seja instanciada, assim como a subclass dessa class.

Aqui estão alguns dos usos do construtor privado:

  1. Padrão de design singleton
  2. Para limitar o número de criação de instância
  3. Para dar um nome significativo à criação de objects usando o método estático de fábrica
  4. Classe de Utilitário Estático ou Classe Constante
  5. Para evitar subsorting
  6. Builder Design Pattern e, assim, para criar classs imutáveis

Sim, a class pode ter um construtor privado. É necessário desaprovar para acessar o construtor de outras classs e permanecer acessível dentro da class definida.

Por que você quer que objects de sua class sejam criados apenas internamente? Isso pode ser feito por qualquer motivo, mas uma possível razão é que você deseja implementar um singleton. Um singleton é um padrão de design que permite que apenas uma instância de sua class seja criada, e isso pode ser feito usando um construtor privado.

Sim e é usado para evitar instanciação e subsequente substituição. Isso é mais frequentemente usado em classs singleton.

sim, um construtor pode ser privado. Um Construtor privado impede que qualquer outra class instancie um exemplo de construtor privado

 public class CustomHttpClient { private static HttpClient customHttpClient; /** A private Constructor prevents any other class from instantiating. */ private CustomHttpClient() { }} 

Construtores privados impedem que uma class seja explicitamente instanciada pelos chamadores para obter mais informações sobre o PrivateConstructor

A idéia básica por trás de ter um construtor privado é restringir a instanciação de uma class de fora pela JVM, mas se uma class tiver um construtor de argumento, então inferirá que está intencionalmente instanciando.

De acordo comigo podemos declarar o construtor como privado e também podemos obter a instância dessa class na subclass usando o método estático na class na qual declaramos o construtor e depois retornamos o object de class. classificamos este método de para a subclass usando classname.method name bcz é o método static e obteremos a instância da class na qual declaramos const.

Um construtor pode ser privado? Como um construtor privado é útil?

Sim pode. Eu considero este outro exemplo de ser útil:

 //... ErrorType.java public enum ErrorType { X, Y, Z } //... ErrorTypeException.java import java.util.*; import java.lang.*; import java.io.*; //Translates ErrorTypes only abstract public class ErrorTypeException extends Exception { private ErrorTypeException(){} //I don't want to expose thse static private class Xx extends ErrorTypeException {} static private class Yx extends ErrorTypeException {} static private class Zx extends ErrorTypeException {} // Want translation without exposing underlying type public static Exception from(ErrorType errorType) { switch (errorType) { case X: return new Xx(); case Y: return new Yx(); default: return new Zx(); } } // Want to get hold of class without exposing underlying type public static Class toExceptionClass(ErrorType errorType) { switch (errorType) { case X: return Xx.class; case Y: return Yx.class; default: return Zx.class; } } } 

No caso acima, isso evita que a class abstrata seja instanciada por qualquer class derivada além de suas classs internas estáticas. Classes abstratas não podem ser finais, mas neste caso o construtor privado torna efetivamente final para todas as classs que não são classs internas