Boas práticas JAVA

Construtores são métodos especiais utilizados para instanciar classes, utiliza-se a instrução new para invocar construtores.
Se você não declarar explicitamente algum construtor, o Java assume que sua classe possui um construtor público sem parâmetros.

Não entendi o que você quis dizer com “atualmente eu utilizo POJOS para trabalhar com construtores”.
POJO é o nome dado a uma convenção de criar classes com getters e setters para seus atributos (convenção que considero imbecil).

O construtor de uma classe tem que ser declarado na própria classe, não dá pra você declarar um construtor da classe X na classe Y.

Na verdade essa convençao de ter getters, setters e construtor público sem argumentos é o padrao Java Beans.

POJO é um objeto java qualquer que nao precisa herdar de uma classe base ou algum tipo de restriçao.

Construtores se aplicam a qualquer classe java, seja ela seguindo a convenção de POJO ou não.
TODA classe java possui por padrão um construtor sem argumentos. Todo construtor com argumento, implicitamente possui uma chamada para o construtor sem argumento. Daí entra dois conceitos importantes:

1. Toda classe java que não possui um construtor declarado possui um construtor sem argumentos por padrão, ou seja, o Java quebra esse galho pra vc.

2. Se vc tiver n construtores com argumentos, o construtor sem argumentos deve ser declarado programaticamente, pois todo construtor com argumento possui uma chamada ao construtor sem argumento por padrão. Veja:

public class Teste{}

Se nada for declarado, implicitamente a classe Teste possui o construtor:

public Teste(){}

Vejamos a classe Teste com construtor recebendo uma String como parâmetro:

public Teste(String teste){
....
}

Implicitamente o Java faz chamada ao construtor sem argumento neste caso, porém, se houver construtores com argumentos, a API não cria o construtor sem argumentos de forma automática. Vejamos:

public Teste(String teste){
  super(); // todo construtor com argumento faz esta chamada, implicitamente ou não.
  System.out.print(teste);
}

Logo, podemos concluir que se sua classe tiver um construtor com argumentos e não possuir um construtor sem argumentos, vai dar ruim erro de compilação.

// compila beleza, pois o construtor com argumento chama o construtor sem argumento de forma implicita!!!!

public Teste(String teste){
....
}

public Teste(){
....
}


// erro de compilação

public Teste(String teste){
....
}

Resumidamente:

1. Construtores estão presentes em todas as classes java, independente de padrão ou convenção.
2. Se a classe não declara um construtor, ela possui um construtor sem argumentos declarado de forma implicita pela API.
3. Se usar construtor com argumento, vc deverá ter um construtor sem argumentos declarado programaticamente, pois implicitamente todo construtor com argumento chama o construtor sem argumento, seja ele público ou não.

Entendi raphael, dando um exemplo de metodo de salvar usuario:

// Ja vi em muitos casos, passarem pojos aqui, recebendo os dados do usuário a ser cadastrado.
public String salvarUsuario(UsuarioPojo pojo){

}

No UsuarioPojo, teriam os argumentos que estão sendo passados no cadastro. Por exemplo: nome, telefone e cpf.

Não sei se ficou claro, mas essa é a minha duvida… Se utilizar construtores para receber argumentos, é uma boa prática.

Acho que vc está confundindo um pouco os conceitos. Vejamos a classe UsuarioPojo com alguns dos atributos que falou:

public class UsuarioPojo{
  private String nome;
  private String telefone;

    public UsuarioPojo(String nome, String telefone){
      this.nome =nome;
      this.telefone=telefone;
    }

    private UsuarioPojo(){}

  }

Podemos tirar desta classe duas informações bacanas:

1. UsuarioPojo só pode ser instanciado por meio do construtor com argumentos.
2. A presença do construtor sem argumentos com modificador de acesso private garante que o objeto seja instanciado somente pelo construtor público, e ao mesmo tempo atende a especificação de que construtores com argumentos chamam o sem argumento, uma vez que membros de classes privados são acessados somente pela classe em questão.

Quando vc fala do método salvarUsuario, não podemos garantir como o objeto pojo foir criado, pois isso não é responsabilidade do método. Vejamos na prática:

public String salvarUsuario(UsuarioPojo pojo){
 // quando chegar aqui, o obj pojo já foi criado, ou seja, a forma como ele foi criado não interessa para este método.
// sabemos que o UsuarioPojo só pode ser criado por meio do new UsuarioPojo("Raphael", "[telefone removido]"), pois este é o construtor público deste objeto.
}

Ou seja, quando falamos de construtores estamos nos referindo ao processo de criação de determinado objeto. Se a criação de um obj é independente de padrão, convenção ou framework, esta premissa se aplica tb aos construtores.

Vejamos um exemplo prático da criação do objeto e uso do mesmo no método salvarUsuario. Leve em consideração a classe UsuarioPojo da forma que coloquei no início do post.

public class TesteApplication{
  public static void main(String... args){
    UsuarioPojo pojo = new UsuarioPojo("Raphael", "619999999999");
    UsuarioService service = new UsuarioSevice(); // digamos que o salvarUsuario esteja definido nesta classe
    service.salvarUsuario(pojo); // veja que o salvar usuario não se interessa em como o objeto foi criado, mas sim em  o objeto UsuarioPojo é valido.
  }

}

Entendi que precisaria instanciar o UsuarioPojo, mas de forma dinâmica, se eu passar um objeto $scope.user contendo nome e telefone, o pojo irá receber os dados certo? Aqui no trabalho, enviamos um objeto que contenha os mesmos atributos que estão no pojo e fazemos com o que o pojo receba todos os dados enviados.