Dúvida quanto a padrão de projeto

Oi José, tudo bem?

Quando a gente cria classes apenas para guardar informações, ou seja, com atributos e getters apenas, a gente chama essa classe ( pelo menos em java ) de POJO, Plain Old Java Object, eles tem muita funções e são bastante usados, por exemplo em DTOs também.

Quando vc cria classes de modelo nesse sentido vc tem o que chamamos de modelo anêmico, ou seja, um modelo pobre em lógica de negócio.

Você pode ser um livro extremamente comentado pela comunidade que é o DDD, Domain driven design, é excelente e é referenciado muito por aí (:

Abraços!

Oi José, tudo bom?

Cuidado pois a classe Cliente possue seus métodos! Toda property com get e set, por baixo dos panos, tem os métodos get e set respectivos.

Acredito que a ideia de não criar classes sem método seja justamente essa. Encapsular os atributos (com properties ou com métodos explicitos) é uma boa prática sempre =)

Quanto a um livro de design patterns, o do Erich Gamma é com certeza a maior referência na area (https://www.amazon.com.br/Padr%C3%B5es-Projetos-Erich-Gamma/dp/8573076100?tag=goog0ef-20&smid=A1ZZFT5FULY4LN&ascsubtag=3e3a0ea4-3ebf-495b-b4e3-cfd2bfc39a51)

Ele não é escrito em C#. Normalmente os melhores livros de desenvolvimento são escritos em java por padrão. Mas, se você der uma olhada vai ver que até mesmo a sintaxe é muito parecida com a do C# e os conceitos são absolutamente compativeis, independente da linguagem.

Abraço!

Olá, José.

Como bem observado pelo Yuri, neste caso temos um modelo anêmico. Inclusive, no blog da Caelum, o instrutor Maurício Aniche fala sobre isto em "O que é Modelo Anêmico? E por que fugir dele?".

Além disso, o André reforçou um conceito importantíssimo do C#, onde a propriedade public int Idade { get; set; } é bastante diferente de um campo public int idade; - onde, esta segunda opção, é extremamente desaconselhável em qualquer situação.

Existem várias as situações onde lidamos precisamos lidar com modelos pobres, havendo apenas getters e setters. Contudo, devemos sempre evitar setters públicos (seja um public SetIdade(int valor) ou public int Idade { get; set; } no lugar de public int Idade { get; private set; }.

Padrões de projetos, em geral, são agnósticos. Ou seja, o conhecimento absorvido com uma linguagem continuará sendo válido em outra linguagem que segue o mesmo paradigma. Minha sugestão é a mesma do André, o Design Patterns.

Abs e bons estudos.

Olá José,

Recomendo, olhar a necessidade do objeto.

Ex: um objeto cliente, pressupõe que exista métodos, pois o cliente deve ser inserido, consultado, atualizado etc...

Em um cenário, onde você precise de uma classe sem métodos, vale a pena verificar, se uma classe abstrata ou Interface não te atende.

E ai, pessoal,

Muito obrigado pelos comentários. Com certeza irão me ajudar bastante!

Já comecei a dar uma olhada nas indicações de livros.

Obrigado!