Excelente artigo! Gostaria de saber qual ferramenta você utilizou para modelar o exemplo?

Att.

Almir

Obrigado pelo comentário.

Não tenho muita certeza do que vc quer dizer com “Método de Extensão”, mas o fato é que tem um erro no diagrama, falta colocar público o método Inativar na classe funcionário. O atributo de “ativo” de funcionário realmente é privado, mas este é manipulado apenas através de métodos, neste caso o método “Inativar”. Na classe empresa, é possível acessar este método normalmente pq ele é público na classe funcionário.

Um bom ponto de partida para entender um pouco sobre projeto orientado a objetos é o livro do Craig Larman segue o link
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062/ref=sr_1_1?ie=UTF8&s=books&qid=1280894086&sr=8-1.

É uma excelente introdução e tem uma versão em português também.

Nós escrevemos um post aqui no saga ano passado sobre modelo de objetos e modelo de dados, talvez possa te ajudar.
Segue o link
http://www.sagadoprogramador.com.br/2009/07/nosso-modelo-de-objetos-nao-deve-ser-uma-copia-do-nosso-modelo-de-dados/

Um abraço,
Luiz Costa

@marcio
Obrigado pelo comentário. A arquitetura antiga do j2ee realmente influenciou bastante a comunidade java. Mas isso tem mudado bastante. Mas acho que isso não é exclusividade do java, em .net também temos vários exemplos de design questionáveis. Mas como vc mesmo disse, design é design.

so fiquei com uma duvida, se a propriedade Ativo do Funcionário esta Private no ultimo Diagrama de Classe, como é que se faz para pode realizar com sucesso o metodo de Extensão funcionario.Inativar() no Metodo Demite() da classe Empresa?
Necessito saber isso, pois estou na busca de informações de como fazer um bom Design já que não sei trabalhar OOP e so faço modelos anêmicos por falta de dominio de modelagem/Design.

Por falar nisso, o que vocês indicam para quem quer aprender mais sobre modelagem/Desing?
Hoje só consigo pensar em Tabelas e querys que vão realizar alguma modificação no Banco. Uma limitação de quem não domina OOP e Design. Este sou eu…!!

[]´s

Edmilson

Evidente que o modelo rico aumenta a coesão e melhora muito a leitura, ao contrário do modelo anêmico. Já vi muitos casos semelhantes ao que falaste, como (em Java) getFuncionarios().add(funcionario), isto dentro de um objeto de negócio (no estilo Transaction Script, como um EJB).

Sou iniciante na plataforma .NET, tenho muito mais background em Java, mas estes conceitos são crosslanguages e crossplatforms, afinal, é design.

Um abraço.

private List funcionarios;
public List Funcionarios
{
get { return funcionarios.AsReadOnly(); }
}

Obrigado pelo seu comentário.

Neste caso, a lista de funcionários privada é proposital. Não é interessante, neste contexto, deixar obter uma referência para lista de funcionários, isto vai quebrar o encapsulamento. O meu ponto é que se esta referência estiver disponível, tem que se ter muito cuidado para não fazer operações sobre a lista que deveriam ser da classe Empresa. Tenho visto alguns projetos ignorando este detalhe e tendo uma duplicação absurda de código.
Mas você tem razão, as properties do C# são uma mão na roda mesmo. Só tem que tomar cuidado com o encapsulamento.

Até
Luiz Costa

No primeiro exemplo, você poderia utilizar

public List Funcionarios {get; private set;}

a fim de que fosse possível recuperar a lista de funcionários. Isto aproveita melhor os recursos da linguagem C#.

Se você fez que nem em Java (como abaixo), você praticamente dispensou o uso das propriedades automáticas do C# 3.0.

private List Funcionarios;
public List GetFuncionarios(){
return this.Funcionarios;
}

Quanto a parte de encapsulamento e Linq, ficou muito bom. É isso mesmo! Parabéns!