Fragmental

Pergunta na XP-Rio:

Me ajudem no seguinte, no processo unificado, espera-se que todos os casos de uso gerem algum tipo de artefato dentro do projeto. Na verdade, com os casos de uso espera-se chegar em classes que juntas formarão o sistema. Dentro da metodologia existe artefatos que quando feitos, permitem mapear todos os artefatos gerados a partir de um caso de uso. A matriz de rastreabilidade.

Gostaria de saber como o XP permite chegar as classes (código) a partir das User Stories. Por exemplo, dado uma User Stories, quais são as classes geradas para atender essa User Stories?

O XP permite isso? Como é feito?

Provavelmente a primeira coisa a se perguntar é: por que eu precisaria deste dados? Alguns modelos de processo como CMMI definem rastreabilidade, que geralmente é definida nesta linha:

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases.)

- Gotel O.C.Z and Finklestein A.C.W (tirado da Wikipedia)

A necessidade parece justa e real, é preciso saber quais partes do software são afetadas por mudanças no negocio e vice-versa. O grande problema desta métrica é que transformações de modelo não são mais tão drásticas há algumas décadas. Ao utilizar qualquer tecnologia relativamente comum (Java, Ruby, .Net, Python, JavaScript…) não existe motivo técnico para que o software não modele o negocio em uma relação próxima de 1-para-1, desta forma saber qual parte de um código realiza qual tarefa torna-se bem simples.

Outro problema é que eu nunca vi um artefato de rastreabilidade, seja qual for, que não ficasse defasado. Se você abraça uma metodologia ágil sabe que refactoring faz parte da vida.

Mesmo com todos os problemas que esta métrica possui eu entendo que existem casos onde seu uso se faz necessário –especialmente por equipes tentando introduzir agilidade em ambientes tradicionais. Supondo que exista uma necessidade justificável para algum controle deste tipo, metodologias ágeis em geral possuem um mecanismo muito mais eficiente que documentos ou mesmos sistemas: testes.

Toda história, todo cartão, deve ter um critério de aceite. O critério de aceite traz o que o cliente considera ser o mínimo para que a história seja considerada concluída. Por exemplo:

História: Como administrador eu quero criar um novo grupo para que possa aplicar permissões à diversos usuários de uma só vez.
Critérios de Aceite:

• O novo grupo criado deve possuir o usuário que o criou como seu administrador
• O novo grupo não deve conter outros membros
• O novo grupo não deve ser visível na listagem de grupos

Cada um destes critérios via um teste unitário e/ou funcional que é executado como parte da integração contínua. Para saber exatamente quais classes e códigos são afetados por cada um deles é simples: use uma ferramenta de test coverage como o Emma e execute apenas os testes de aceitação para aquele cartão. A ferramenta irá gerar relatórios como estes:

[class, %]	[method, %]	[block, %]	[line, %]	[name]
25%  (1/4)!	25%  (3/12)!	40%  (3012/7446)!	25%  (3/12)!	com.sun.tools.javac.v8.resources
94%  (16/17)!	49%  (41/83)!	48%  (1111/2292)!	45%  (201.1/450)!	com.sun.tools.javac.v8
88%  (45/51)!	61%  (242/397)!	54%  (3070/5729)!	52%  (809.6/1563)!	com.sun.tools.javac.v8.tree

Classes que possuem alguma cobertura foram afetadas pelo teste, logo são parte da execução daquela história. Não é difícil escrever um script que –talvez como parte do build- processe estes relatórios e gere o artefato de rastreabilidade que seu processo te obrigar a fazer. Melhor ainda: este artefato nunca estará desatualizado.

Só não se esqueça que melhoria contínua é um conceito importante. Se o artefato de rastreabilidade é algo tão ineficiente a obrigação de um desenvolvedor que perceba isto é mostrar para sua organização que o valor desta pratica é nulo. Não se acomode.

Percebi que boa parte das dúvidas quanto ao meu post sobre como objetos não possuem atributos se deve ao fato das pessoas não terem geralmente um conhecimento real sobre o que é troca de mensagens.

Perfeitamente compreensível. Na maior parte dos livros e faculdades as pessoas aprendem que Orientação a Objetos é sobre como utilizar classes e sobre como as funções são chamadas de métodos. Por algum motivo esquecido nas areias do tempo decidiu-se que chamar o método em uma classe era passar uma mensagem e por isso algumas pessoas notoriamente pedantes usam este termo ao invés de dizer apenas “chama a função”.

Bem, os conceitos no parágrafo acima estão errados. Orientação a Objetos não é sobre classes e sim sobre…er… objetos. Você pode ter OO sem ter classes, como JavaScript e Io e pode ter também OO sem mensagens.

Troca de mensagens é um conceito utilizado em diversas áreas, não apenas Orientação a Objetos. Você pode ter um Sistema Operacional baseado neste conceito -como o MINIX por exemplo- ou criar uma arquitetura de computação distribuída como SOAP.

O que distingue a passagem de mensagens é o fato de que o recipiente da mensagem, seja um objeto, um serviço ou um processo, é quem decide o que é feito em decorrência de sua invocação.

Para tentar içar um pouco mais claro eu criei um meta-modelo bem bobinho em Java. Este representa um sistema Orientado a Objetos com classes e passagem de mensagens. O código abaixo mostra como declarar uma Classe calculadora e enviar uma mensagem dizendo para que esta multiplique números.

BlocoDeCodigo bloco = new BlocoDeCodigoImpl<Integer, Integer, Integer>(){
			public Integer executar(Integer a, Integer b){
				return a * b;
			}
		};

		Classe classeCalculadora = novaClasse("Calculadora");
		classeCalculadora.declaraMensagem("multiplique", bloco);

		Instancia calculadora = instanciar("Calculadora");

		assertEquals(8, calculadora.enviaMensagem("multiplique", 2, 4));

Note os passos realizados. Primeiro criamos um bloco de código, uma função. Depois dizemos ao sistema que existe uma classe chamada calculadora. Logo apos registramos o fato de que calculadora responde a uma mensagem executando o bloco que havíamos declarado.

Em termos de semântica, este código é mais ou menos equivalente a este:

public class Calculadora{
 public Integer multiplicar(Integer a, Integer b){
  return a * b;
}
}

Depois nós instanciamos a classe e passamos uma mensagem para ela, o que seria equivalente a:

Calculadora calc = new Calculadora();
calc.multiplicar(2,4);

As classes relevantes:

public class Ambiente {
	static Map<String, Classe> classesDeclaradas = new HashMap<String, Classe>();

	static Classe novaClasse(String nomeDaClasse) {
		ClasseImpl classe = new ClasseImpl(nomeDaClasse);
		classesDeclaradas.put(nomeDaClasse, classe);
		return classe;
	}

	static Instancia instanciar(String nomeDaClasse) {
		return new Instancia(classesDeclaradas.get(nomeDaClasse));
	}
}

public class ClasseImpl implements Classe {

	private final String nome;

	private Map<String, BlocoDeCodigo> mensagens = new HashMap<String, BlocoDeCodigo>();

	public ClasseImpl(String nome) {
		this.nome = nome;
	}

	public void declaraMensagem(String nomeDaMensagem, BlocoDeCodigo blocoASerExecutado) {
		mensagens.put(nomeDaMensagem, blocoASerExecutado);
	}

	public String nome() {
		return nome;
	}

	public boolean respondeA(String nomeDaMensagem) {
		return mensagens.containsKey(nomeDaMensagem);
	}

	public BlocoDeCodigo codigoParaMensagem(String nomeDaMensagem) {
		return mensagens.get(nomeDaMensagem);
	}

}

public class Instancia {
	private final Classe minhaClasse;

	public Instancia(Classe classe) {
		this.minhaClasse = classe;
	}

	public Object enviaMensagem(String mensagem, Object... args) {
		Object primeiro = args.length > 0 ? args[0] : null;
		Object segundo = args.length > 1 ? args[1] : null;

		return minhaClasse.codigoParaMensagem(mensagem).executar(primeiro,
				segundo);
	}

	public Classe classe() {
		return minhaClasse;
	}

}

Esse meta-modelo é baseado em troca de mensagens. A classe Calculadora não recebe código a ser executado ela apenas recebe o nome de uma mensagem e parâmetros. Imagine que eu registre o mesmo bloco de código para várias mensagens, ou que eu use recursos de AOP e intercepte a execução do bloco. Nada disso é relevante para quem invoca a mensagem, ele apenas a envia e o que acontece em decorrência disso é responsabilidade do receptor.

Como quase todas as linguagens atuam desta forma pode ser difícil entender o conceito já que nunca se viu nada diferente. Vamos então implementar outro meta-modelo que não usa troca de mensagens mas sim uma outra forma chamada Data-Directed.

Nesta forma de invocar operações em objetos –que, como a anterior não é específica de OO- quem decide qual função será aplicada é o ambiente de execução, o runtime. Quando você invoca uma operação o ambiente vai procurar dentre os métodos registrados qual é o aplicável para aquele objeto e vai executar o método nele. Common Lisp utiliza este recurso de maneira tão poderosa em suas Generic Functions que praticamente elimina a necessidade de coisas como proxies e AOP.

Nosso meta-modelo para Data-Directed é executado dessa forma:

BlocoDeCodigo bloco = new BlocoDeCodigoImpl<Integer, Integer, Integer>(){
			public Integer executar(Instancia instancia, Integer a, Integer b) {
				return a * b;
			}
		};

		Classe classeCalculadora = novaClasse("Calculadora");
		registrarMetodo("multiplique", classeCalculadora, bloco);

		Instancia calculadora = instanciar("Calculadora");

		assertEquals(8, executarMetodo("multiplique", calculadora, 2, 4));

Repare que agora o bloco de código recebe como seu primeiro argumento uma referência para a instancia a qual se aplica (se você já usou java.lang.Method sabe que isso não é incomum quando se desce ao nível de implementação de linguagem). Caso nosso exemplo fosse minimamente usável seria desta forma que o bloco obteria acesso ao objeto em si.

Logo depois criamos a classe como antes mas ao invés de registrar uma mensagem na classe nós registramos um método no ambiente, dizendo que o método se aplica àquela classe. A invocação em si é bem parecida com a anterior.

Na implementação a única classe mais interessante é o Ambiente, que agora é bem mais esperto:

public class Ambiente {
	static Map<String, Classe> classesDeclaradas = new HashMap<String, Classe>();
	static Map<String, Map<Classe, BlocoDeCodigo>> metodos = new HashMap<String, Map<Classe, BlocoDeCodigo>>();

	static Classe novaClasse(String nomeDaClasse) {
		ClasseImpl classe = new ClasseImpl(nomeDaClasse);
		classesDeclaradas.put(nomeDaClasse, classe);
		return classe;
	}

	static Instancia instanciar(String nomeDaClasse) {
		return new Instancia(classesDeclaradas.get(nomeDaClasse));
	}

	static void registrarMetodo(String nomeDoMetodo, Classe tipoEmQueSeAplica,
			BlocoDeCodigo bloco) {
		metodo(nomeDoMetodo).put(tipoEmQueSeAplica, bloco);
	}

	static Object executarMetodo(String nomeDoMetodo, Instancia instancia,
			Object... args) {
		Map<Classe, BlocoDeCodigo> tiposAceitaveis = metodo(nomeDoMetodo);
		if (!tiposAceitaveis.containsKey(instancia.classe()))
			throw new RuntimeException("Metodo inexistente");

		BlocoDeCodigo bloco = tiposAceitaveis.get(instancia.classe());

		Object primeiro = args.length > 0 ? args[0] : null;
		Object segundo = args.length > 1 ? args[1] : null;

		return bloco.executar(instancia, primeiro, segundo);
	}

	private static Map<Classe, BlocoDeCodigo> metodo(String nomeDoMetodo) {
		if (!metodos.containsKey(nomeDoMetodo))
			metodos.put(nomeDoMetodo, new HashMap<Classe, BlocoDeCodigo>());

		return metodos.get(nomeDoMetodo);
	}

}

Agora não apenas registra as classes mas também os métodos que são aplicáveis à cada classe e faz a invocação dos métodos em si.

Estes exemplos são bem educacionais, sem muita aplicação pratica, mas como já vimos em posts passados o fato de se usar message-passing ou Data-Directed ou properties, ou componentes ou qualquer outra coisa interfere no modo como devemos projetar nosso software. Existe uma vasta literatura sobre este tema mas ainda assim é uma das coisas mais desconhecidas pelo programador profissional.

Falando em coisas agitadas, fui convidado para palestrar no Australian Architecture Forum 2008. O título é “Lightweight SOA Through Web Widgets” e falar de SOA com REST num evento onde vai estar presente o impagável Jim Webber é algo bem diferente.

Como meu Google Analytics diz que ese blog é acessado por pessoas aqui na Austrália fica o convite.

Uma pessoa me escreveu um email sobre o tópico anterior. Novamente não vou citar nomes porque não pedi permissão (e não tenho motivos para expôr esta):

Shoes, beleza cara?

Então, lendo sobre a discussão sobre o Maker eu cheguei no seu blog e li sobre RAD.
Aquela ferramenta no NetBeansLixo pra fazer GUIs é um RAD? Ele desenvolve parte de um software, eu sei, não é um modelo de processo de desenvolvimento, né??

Enfim, acredito que existam mais algumas por aí como Maker e queria saber da sua opinião: todas essas ferramentas são RADs e todas elas cometem gafes? Onde quero chegar é na pergunta: Hoje em dia, SEMPRE teremos um desenvolvedor por trás da solução?

É que eu sou totalmente contra essas ferramentas de gerar códigos automáticos… não confio muito nessas coisas… prefiro eu mesmo fazer os códigos, mas tenho a dúvida: estou muito antiquado (no sentido de muito atrasado e não acompanhando as tecnologias que estão evoluindo hoje) ou estou no caminho correto?

Bom, se você respondeu que sim na primeira pergunta (do NetBeans sobre GUIs), a principal desvantagem das ferramentas RAD (se é isso que aquele Lixo é) é a manutenção e evolução, certo? Uma vez, fazendo um trabalho pra faculdade, tive que usar aquele NetBeans. Quando fui usar Refactoring… nossa cara, que coisa mais chata… tive que refazer praticamente toda a interface gráfica.

Abraço.

Apesar de usar, eu odeio o termo RAD. Ele significa um grupo enorme de coisas e ao mesmo tempo não significa nada. O livro Software Development: Building Reliable Systems define RAD:

For the last ten years, many software projects have incorporated the use of “Rapid Application Development” methodologies in an effort to decrease development times. RAD, as it is generally referred to, incorporates an umbrella of methodologies based on spiral, iterative development technologies. RAD techniques range from the simple use of GUI development tools to quickly build prototypes, to processes incorporating complete, cross-functional business analysis. […]

Então vou considerar que você quer dizer por RAD “ferramentas geradoras de código” do contrario este post nunca vai acabar. Sim, o Matisse do Netbeans é uma ferramenta geradora de código.

Ferramentas geradoras, em geral, são úteis quando não querem dominar o mundo. Eu adoro quando o Hibernate ou o Rails gera meu DDL SQL e eu não tenho que escrever CREATE TABLE. Eu adoro quando o Eclipse gera meus getters e setters e coisa do tipo. O problema é que esses geradores não costumam sobreviver num projeto de verdade.

O grande problema do gerador de código padrão, como o citado, é que ele possui diversos vazamentos de abstração. O Joel Spolsky fala especificamente sobre geradores:

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.

Como pode-se perceber pelas discussões citadas o mercado destas ferramentas é… complicado. Um desenvolvedor que entende como a plataforma funciona (Java EE, no caso) dificilmente se encantaria pela ferramenta. Ele pode utilizar algo como um Spring IDE para gerar arquivos de configuração mas sabe que isso não é tão simples assim.

Os programadores mais recentes na plataforma Java podem não ter consciência disso mas uma ferramenta chamada xdoclet era muito usada quando sofríamos diariamente com EJBs 2.1. O que o xdoclet faz é gerar código, ele gerava todo o mapeamento do EJB (uns 3 arquivos XML diferentes, pelo menos) a partir de anotações JavaDoc (não existia Java 5 naquela época). O xdoclet era a salvação da lavoura, conseguia abstrair muitos problemas mas.. não era perfeito, nem pretendia.

Eu já trabalhei em projeto onde 50% do código era gerado pelo xdoclet e do restante ele não dava conta. A ferramenta não possui o tal do round-tripping então não dava para misturar código gerado com modificado. A solução foi optar por uma arquitetura que isolava as duas partes em módulos diferentes e só conseguimos chegar até ela porque –como disse o Joel- sabíamos como a ferramenta funcionada. Essa é uma ferramenta de automação, não de “geração automática de sistema”. Ela automatiza o trabalho que você teria, não te livra do fato de conhecer o que… bem… é sua profissão.

Acho que o Matisse se enquadra neste tipo.

O problema é que essas ferramentas –e seus persuasivos vendedores- dizem que irão abstrair todo o desenvolvimento. Para os cenários ideais elas podem fazer todo o prometido mas não houve até hoje uma ferramenta que conseguisse real sucesso fora dos casos mais simples e isso porque não é assim que construímos sistemas hoje. Nossos sistemas são uma salada de linguagens, conceitos, mapeamentos e configurações que uma ferramenta deste tipo não consegue acompanhar.

O que geralmente elas fazem é te prender à uma ou algumas arquiteturas genéricas que servem razoavelmente para alguns casos -geralmente sitezinhos CRUD de intranet- mas não para todos ou sequer para a maioria. Como arquitetura não é commodity não se pode simplesmente aplicar a mesma estrutura em todos os cenários.

Apos algum tempo em TI você começa a entender que o dia-a-dia desse mercado é um grande “mais do mesmo”. Você sempre está criando as mesmas coisas. Da última vez que contei eu já tinha criado uns sete gerenciadores de conteúdo web. Dá para utilizar a mesma arquitetura em todos? Não. Uns eram simples formulários, outros se integravam com back-ends complicados, outros era assíncronos, outros tinham integração com legado… cada um tinha uma história. Se há oito anos atrás eu comprasse uma ferramenta dessas e a tivesse aplicado nestes projetos eu teria que fazer personalização (i.e. sair do maravilhoso mundo do fluxograma) a cada projeto.

Mas eu estou falando de desenvolvimento de software de um tipo, não do mercado todo. Quando estive na faculdade pela última vez (antes da segunda fuga) estudei com uma pessoa de 43 anos que desde os anos 80 vive fazendo software em coisas como CLIPPER para lojinhas e boutiques. Ele não ganha mal. Pelo que entendo dos softwares deste tipo (já trabalhei neste ramo) a arquitetura é quase sempre a mesma. Talvez ele se favorecesse de algo assim nos seus negócios, apesar de que eu ainda acharia um risco desnecessário.

Então sim, hoje precisamos de desenvolvedores para projetar um sistema. Desenvolver sua arquitetura, seu design e verificar para que tudo seja eito da maneira mais adequada para o projeto (que nem sempre é a técnica mais adequada). Mas e o futuro?

O futuro prevê o uso de ferramentas de um nível mais alto, mas de maneira diferente. O ponto crucial é que essas ferramentas não são geradores de código Java (ou C#, ou Ruby ou o que for), elas mudam a visão sobre o código. Ferramentas como Domain-Specific Languages aumentam o nível da linguagem não tornando-a mais abstrata apenas mas sim levando para perto do negócio. Ferramentas de visualização criam pontos de vista diferenciado sobre o mesmo artefato, dependendo de com que olhos se enxerga.

Tudo indica que para desenvolver softwares no futuro o desenvolvedor não terá o mesmo papel que tem hoje. Ao invés de criar o código do sistema em si iremos criar as ferramentas que dão suporte à criação de sistemas pelos usuários.

Seja qual for o futuro ele não é sobre gerar código. Isso nós já fazemos à décadas e serve apenas como quebra-galho para nos livrar da complexidade que nós mesmo criamos.

Este tópico está na minha fila de posts há meses, hora de sair algo. Eu vou me basear num e-mail que recebi de uma pessoa do GUJ (que só não vou falar o nme porque não pedi autorização):

Sobre o “polêmico” manjado tópico de que o java pode acabar.

Você postou o seguinte (na primeira página):

Software é programar. Se você que gerenciar uma equipe de desenvolvimento você tem que estudar matérias relacionadas à gestão de pessoas. Isso não é uma evolução do programador, um desenvolvedor de software é sempre um desenvolvedor de software.

Será que alguém que se forma em Ciência da Computação (como eu, se Deus quiser) não consegue o cargo de gerência de equipe? Eu vejo isso pelo meu tio… ele é formado em Engenharia Química e hoje é gerente de um empesa aqui, mas porquê? Porque ele conhece como as coisas funcionam… todo gerente que conheço ou que já ouvi falar aconteceu o mesmo… gerentes de supermercado geralmente sabem tudo o que se passa dentro do maldito mercado! Concorda? Logo, começa-se como programador, pra depois passar pra cima. Ou não? Você já foi programador? Estou em dúvida porque parece que o salário de um programdor (caso eu seja programdor pra vida inteira, que é algo que eu não quero) é baixo e não dê pra sustentar uma família, entende? Da maneira que eu digo faz parecer que eu não quero ser programador JAMAIS, mas eu quero… putz, amo programar, tenho um tesão gigantesco por programação… mas o problema é se vai me sustentar bem e minha família pro resto da vida, entende? Acredito que se um dia eu chegar a um cargo que não envolva programação eu ainda assim vou programar, pra me divertir mesmo.

E aí, o que você acha?

Este é um problema bem grande. Vamos começar sobre um problema que não está explícito no e-mail mas que existe: aquilo que alguns chamam de analista de sistemas.

Quando eu estava na faculdade pela primeira vez (ou seja: antes de largar ela pela rimeira vez) lembro de ter aula com um professor daqueles com anos de COBOL nas costas. Ele se lamentava sobre como o mercado confundia analistas e programadores e como estava surgindo a bizarrice do ‘progranalista’, alguém que combinava os dois papéis. Na comunidade em geral você vê este pensamento, eu tenho muitos conhecidos que querem ser ‘analistas’, o que para eles significa desenhar UML ou fluxogramas que são passados para os programadores.

Eu acho que já escrevi sobre isso aqui mas isso não é algo justificável. Eu nunca desenvolvi em COBOL ou uma destas plataformas mais antigas e não posso te dizer se se justificava há alguns anos mas não faz mais sentido, e há muito tempo. O papel do analista seria, teoricamente, converter um modelo abstrato (de negócios) em um modelo lógico, geralmente expresso de forma gráfica. O modelo lógico então passa a um modelo físico, que é a implementação.

Agora vamos analisar o caso de uma plataforma moderna de desenvolvimento como Java, .Net ou Ruby. Um modelo abstrato é composto por conceitos de negócio, geralmente estes conceitos não possuem uma estrutura que um computador entenda. O analista vai traduzir este conceito em lógica, provavelmente usando UML. Ora, UML é apenas uma notação gráfica para classes e objetos e sua linguagem favorita já trabalha com classes e objetos. A tradução entre um modelo lógico e o modelo físico é desnecessária: o modelo lógico já é o modelo físico. A diferença é que UML não executa, por mais que os evangelistas de MDA cismem do contrário.

A solução? Modele em código. Caso você precise erar diagramas basta você utilizar uma das dezenas de ferramentas de engenharia reversa. Modelando em código você tem algo executável, testável e que pode dar feedback ao seu usuário.

“Analista de sistemas” é algo que não existe. Pode ter existido um dia, não sei, mas não faz mais sentido há muitos anos. O modelo lógico é expresso em linguagens de altíssimo nível que modela muito bem o negócio: Java, Ruby, C#… Quem converte o lógico em físico é alguém que nem cobra muito por isso: o compilador.

Alguém colocar na sua assinatura de e-mail ou ter a carteira assinada (como eu já tive!) como “Analista Java” está se enganando e colaborando para a criação de papéis que só existem na burocracia das empresas e das pessoas.

Mas e o papel do analista de resolver problemas de negócio? Sinto informar mas se você fazia isso como analista você estava ou se enganando ou enganando seu cliente. É certo que muitos clientes precisam entender seus próprios negócios antes de criar um sistema mas isso não é papel de analista de sistemas, é papel de analista de negócios. Um analista deste tipo possui capacitação em campos bem diferentes, é completamente possível que um analista de negócios seja um desenvolvedor (vamos abolir o “analista de sistemas” a partir daqui) mas neste caso ele está assumindo duas especialidades. Um analista de negócios possui um perfil não-técnico e mais especializado em um mercado como bancos, marketing, telecomunicações e etc.

Mas e o gerente? Uma das piores coisas que podem fazer em uma empresa é promover um bom técnico à gerente (coordenador, o que for) apens porque ele está há mito tempo na casa. Querem estimular a pessoa? Transormem ele em um líder técnico, aumentem o salário do sujeito e o deixem em paz.

Gerência não é brincadeira. Não é porque alguém programa muito bem que vai ser um bom gerente. Se você é desenvolvedor mas sonha em dizer para a paquera no barzinho que é gerente de algo (nem que seja do McDonald’s) invista nisso. Aprenda sobre liderança, sobre mercado, plano de negócios, luxo de caixa, lean e todas as dezenas de disciplinas envolvidas. Vai levar um tempo.

Só não encare isso como uma evolução. Você está saindo da carreira de técnico, não evoluindo. Considerando que conseguir bons salários como técnico é raro pode ser uma boa escolha, mas nem sempre é. Se você é um bom técnico existem opções…

Um amigo outro dia me perguntou que tipo de arquitetura eu usaria num caso bem peculiar. Basicamente ele foi encarregado de definir a arquitetura corporativa de um grande banco, ou seja: definir hoje a forma como aplicações serão construídas pelas próximas décadas. Basicamente ele vai se ro cara que vai ser xingado por algumas centenas de programadores nos próximos tempos, não importa que arquitetura escolha.

Há poucos dias atrás falamos aqui sobre arquiteturas de referência e seu efeito danoso. Geralmente quando alguém tem à frente um desafio desse ele logo pensa em um modelinho que mostra obriga o uso de uma meia dúzia de frameworks e padrões (clássico moderno: Struts/JSF e JPA, clássico vintage: Struts 1.1 e EJB/DAO). Para melhorar ainda é incorporado um conjunto de classes “utilitárias” feitas com práticas que talvez tenham servido para um projetinho piloto mas hoje em dia só atrapalham.

Ainda assim uma arquitetura corporativa é algo interessante. Quando empresas grandes não possuem uma macro-arquitetura acabam crescendo de maneira desordenada e criando dezenas de aplicações redundantes e gambiarras de integração entre sistemas. Note no entanto que uma arquitetura corporativa não é uma arquitetura de referência, a arquitetura corporativa não fala sobre como implementar aplicações mas sim provê guias sobre como integrá-las, define as relações previstas em no ecossistema que é uma grande empresa.

Quais são as melhores macro-arquiteturas que você conhece? Eu consigo pensar em algumas: Apache, UNIX, World Wide Web… Nestes ecossistemas aplicações novas surgem, são alteradas e morrem todos os dias há décadas, um sistema criado com a tecnologia mais recente de 2007 vai rodar tranqüilamente neste ambiente. Por quê?

Porque estas arquiteturas se baseiam em primitivas e contratos, não em especificações rígidas. Criar um módulo para o Apache , um programa para rodar em UNIX ou uma site é basicamente criar um programa de computador em uma das plataformas suportadas que obedeça a um contrato.

Uma boa arquitetura corporativa vai definir algumas políticas e contratos para a aplicação se relacionar com o meio-ambiente e só isso. No caso do banco, poderíamos definir que uma aplicação deve disponibilizar via uma interface POX/REST seus WebServices, que ela deve utilizar a API do Mogile FS para guardar dados em disco, que cache deve ser feito utilizando a API do memcached.

E se o arquiteto quiser sair do padrão? Ótimo, saia, mas ele deve oferecer compatibilidade com o ambiente.

E se eu já tiver comprado um sistema que faz WebServices via SOAP? Eu preciso criar um meio de disponibilizar estes serviços via POX/REST também. Pode ser uma adaptador simples, um ESB, o que quer que seja. É como quando você compra um equipamento eletrônico com tomada americana, você não vai mudar uma tomada na sua casa para o padrão exótico, vai é comprar o adaptador necessário para plugar ele nas tomadas do seu ambiente.

Mas e se não precisarmos de filesystem distribuído? E se já estivermos utilizando uma solução de cache que faz mais sentido nesta aplicação?

Ótimo, use. O uso de filesystem X, cache Y, banco de dados Z deve ser um guia. Toda vez que alguém precisar de uma solução de cache, filesystem, etc. ele olha o guia da empresa, se não servir ele usa algo que sirva. O que importa é que o uso fique encapsulado no sistema. Imagine que ao invés do Oracle 10g eu resolva usar um MySQL na minha aplicação. Está ótimo mas eu devo manter essa peculiaridade interna à minha aplicação. Os outros sistemas que vierem a se comunicar com o meu não devem precisar saber sobre a existência deste banco, eu não posso usar este banco para comunicação entre aplicações (o que já é uma coisa péssima para se fazer de qualquer forma).

O que importa é:

1. O arquiteto tem liberdade para resolver seu problema da maneira mais adequada
2. O novo sistema é compatível com o meio-ambiente

Para ser um bom arquiteto não é necessário ter tanta experiência assim, basta saber olhar os casos de sucesso e aproveitar o que funciona. Geralmente as técnicas utilizadas nestas arquiteturas são também catalogadas como Padrões Arquiteturais em livros. Um bom arquiteto tem que ser um ávido leitor de livros e de código.

Há mais de dois anos que entrevistar candidatos faz parte do meu dia-a-dia. Neste período eu aprendi bastante sobre como entrevistar e ser entrevistado, acho que é um bom momento para compartilhar… não estou dizendo que o texto abaixo é ótimo, é aplicável ao seu caso, ou sequer que você deva usar. É apenas uma descrição sobre o que eu tenho de experiência nesta área.

Lição 1: Seja Claro no que Procura

Não são só arquiteturas que sofrem com padronização desnecessária, entrevistas também devem ser desenhadas de acordo a situação, especialmente com o que se espera encontrar.

É preciso saber o que se procura. Geralmente alguém decide que a equipe precisa de mais um ou mais membros para ter melhor performance mas a primeira coisa a fazer -como sempre- é fugir do senso comum e se perguntar: é isso mesmo? Será que estamos fazendo as coisas certas? Será que não podemos melhorar nosso desempenho simplesmente mudando a forma de trabalho? Empresas de três letras ensinaram ao mercado que quando um projeto vai mal devemos enfiar pessoas nele (e cobrar por homem/hora, não se esqueça) mas isso é simplesmente contra tudo que sabemos sobre projetos de software. Enfiar mais pessoas em um projeto só o faz atrasar mais (leia Fred Brooks).

Se a resposta for realmente mais pessoas, então que tipo de profissional precisamos contratar? Seja lá o que for deixe bem claro no anúncio, você não vai evitar que panfletadores de curriculum encham sua caixa de email (aliás, crie uma caixa só para isso e desative-a quando não existirem mais vagas) mas vai melhorar as chances que alguém realmente interessante e interessado responda. Também não coloque em qualquer lugar seu anúncio, divulgue em listas especializadas e em grupos de pessoas que confie. Aliás, grupos de pessoas são ótimos porque você pode verificar o histórico da pessoa que enviar o curriculum.

Lição 2: Capriche na Triagem

Se você for bem específico como sugeri na lição acima dificilmente vai ter uma chuva de curriculums, mas caso tenha uma técnica de triagem se faz necessária. Se você tem tempo faça a primeira entrevista por telefone. Se você não tem muito tempo sequer para entrevistas presenciais faça o seguinte: crie uma lista com alguns problemas e peça para o cara resolver e te mandar a resposta.

Os problemas precisam ser diferentes, crie um problema sobre concorrência, um sobre otimização, um sobre modelagem, eles precisam ter o mesmo nível de dificuldade também. O problema que a pessoa escolher (só deve escolher um) te diz sobre o perfil dela. Depois faça uma revisão via telefone do código com a pessoa, é mais para evitar fraude mas ainda assim é uma ótima oportunidade para perguntar alguns aspectos técnicos, porque tomou a decisão X e não fez Y, como refatorar a solução para que fique mais XYZ, etc.

Lição 3: Nada de Perguntas McDonald’s

Para entrar numa grande empresa fui entrevistado pelo meu futuro gerente. Ele tinha na mão uma lista com umas 10 páginas de perguntas variadas sobre Java e SQL, basicamente. Após a segunda página nós já havíamos abolido a folha e partido para um fluxo mais aberto de conhecimento mútuo. Dessa experiência eu tirei um fluxo de entrevista um pouco diferente do que costumo ver.

Quando seleciono um curriculum eu geralmente monto um estereótipo para aquela pessoa: “Arquiteto”, “junior”, “pleno”, “especialista em XXX”, “enrolão”, etc. Deste estereótipo eu penso em algumas primeiras perguntas.

Quando a pessoa chega eu geralmente peço a ela que se apresente, conte um pouco da sua história. Desta o estereótipo inicial pode ser alterado ou não, geralmente após isso eu já tenho uma boa noção do perfil profissional da pessoa. Aí começam as perguntas reais.

Se eu penso que o cara é junior eu começo com algumas perguntas pedindo para ele descrever conceitos. Eu dificilmente pergunto pelo conceito diretamente mas sim algo que indiretamente vai requisitar dele que o faça, como comparações. Continuando com conceitos eu vejo se possui boas bases ou é apenas apertador de parafusos. Eu continuo perguntando, seguindo os perfis de pleno, arquiteto e especialista até ver que o cara não sabe mais. Muitas vezes encontrei juniores que sabiam mais que arquitetos.

Para “desenvolvedor pleno” a coisa começa relativamente ao contrário. Eu peço para ele descrever alguma coisa em que tenha trabalhado e depois para ele dissecar a arquitetura. No meio do caminho surgem diversos pontos interessantes para explorar como Domain Models, BO/VO, programação concorrente, técnicas de performance, etc. Sempre que possível eu faço perguntas baseadas em um cenário real que eu já tenha vivido, até para a pessoa sentir o tamanho do desafio (é difícil fazer alguns entenderem o tamanho da encrenca). Muita gente morre aqui simplesmente porque não entende nada do que trabalha. O cara está há anos desenvolvendo aplicações e não tem idéia do porque usa um padrão ou outro. Todo mundo sabe responder “um design pattern é uma solução para um problema comum blablabla” mas ninguém sabe dizer que problema o tal do BO/VO soluciona.

Tenho que admitir que para arquitetos o buraco é way over mais embaixo. A coisa começa com descrições sobre arquiteturas que ele já tenha trabalhado e, principalmente, desenhado. Geralmente nestas descrições vai haver uma menção um pouco mais interessante que o usual, como conectores JCA, filas, caches ou clusters. Aí é que está o pulo do gato: um arquiteto tem que saber como isso funciona num projeto. Não importa se na época ele não se entitulava arquiteto, não é admissível alguém que nunca parou para saber como aquilo funcionava! Algumas perguntas sobre arquitetura da JVM são sempre boas também. Você consegue descrever como o Garbage Collector funciona com muita e com pouca memória disponível? Identificar erros mais simples de parametrização da JVM?

Interessante notar que não é preciso responder certo as perguntas. Aliás, eu nem espero que sejam respondidas. As respostas ideais, da melhor para a pior:

1. Resposta certa
2. Caminho certo (não chegou na resposta mas elaborou bem)
3. Resposta errada por uma bobeira qualquer
4. Dizer que não sabe

Nessa lista não está a resposta errada. Se um candidato não assume que não conhece a resposta (e algumas perguntas não supõem que você conheça a resposta!) e chuta ele perde muitos pontos numa entrevista dessa. Mentir sobre projetos e empresas é sempre engraçado, no Rio de Janeiro eu conheço muita gente em muitas empresas e sempre consigo lembrar de alguém que teoricamente teria trabalhado com o candidato no tal projeto.

Eu sempre insisto para a pessoa tentar chegar na resposta ao menos. Na sala sempre vai haver papel e caneta ou um quadro-branco, o ato de seguir por um caminho lógico para tentar chegar à resposta é muito importante. Uma das coisas que consigo verificar assim é escalabilidade, dificilmente aparece alguém que sabe como criar um site que suporte um fluxo muito grande de acessos mas geralmente as pessoas têm pelo menos uma idéia sobre conceitos que podem usar enste caso.

Tem gente que fica muito nervosa neste ponto então é melhor criar o ambiente mais descontraído possível. Aqui isso não é problema, geralmente eu converso com a pessoa com meu jeans e camiseta usual, muitas vezes com o pé na cadeira. Não é para impressionar, é assim que as coisas são e é bom a pessoa saber disso. Eu não quero saber se a pessoa é boa ou ruim, quero apenas saber se ela é quem eu estou procurando neste momento ou não.

Lição 4: Explique o Cenário

Após a entrevista em si eu explico o cenário. Descrevo como as coisas funcionam na equipe, a hierarquia, os tipos de projeto, tecnologias e o que espero da vaga. No final respondo dúvidas.

Por que não antes? Porque pode influenciar a pessoa. Ao ouvir que nós plantamos bananas ele vai se vender como o melhor bananeiro desde Jorge Ben Jor.

Lição 5: Racionalize o Candidato

As vezes você procura um semi-deus e aparecem apenas juniores, as vezes você procura juniores e o próprio Zahl aparece. Hoje em dia um gestor tem que saber flexibilizar seu quadro de pessoal.

Se você tem vaga de senior e arrumou um junior muito interessante que tal dividir a grana do senior em dois? Ou que tal pagar o salário do junior e com o resto do orçamento investir na equipe para que todo mundo suba de nível técnico?

O tipo de entrevista acima não dispensa ninguém. Se na segunda pergunta você já viu que o cara não serve para a vaga continue, descubra quem o cara é. Num mercado como esse no mínimo você pode indicá-lo a outro gestor precisando de pessoas ou guardar na manga para outra oportunidade. Claro que se o cara for ruim ele é ruim e pronto.

Eu sei bem que não é o ideal, mas este modelo de entrevista já me fez boas contratações e, sinceramente, nenhuma ruim. Um dos efeitos ruins é que as vagas demoram bons meses para serem preenchidas mas atualmente isso é “menos pior” do que ficar meses com um desenvolvedor não-qualificado.

E-mail do Caike:

Olá Phillip, tudo bom ?

Leio sempre seus posts em seu blog e no fórum do GUJ e vejo como algumas vezes suas constatações vão por caminhos diferentes dos do ’senso-comum’ (Freakonomics?). Gostaria de agradecer as ‘guerras’ (inclusive algumas vezes levadas muito mais a sério do que deveriam, por outras pessoas) sobre diferentes arquiteturas e aplicações de OO. Graças a elas, tenho ganho diversos pontos a serem investigados em meus estudos.
Sou recém graduado em Ciência da Computação por uma faculdade de Belém, PA, e a pergunta que estou prestes a fazê-lo envolve a tâo polêmica orientação a objetos.

Batendo a cabeça sobre tudo o que o pessoal vem falando e a idéia que você vem tentando passar, gostaria que avaliasse a minha possível avaliação de OO.

Vejo a OO como algo que tenta expressar mais como o mundo real funciona, e não como ele realmente é. Acredito que o foco da abordagem orientada a objetos deva estar nas mudanças de processos e, por conseqüência desta, acaba dando uma idéia de como as coisas são. Durante a modelagem de uma idéia devemos prezar pela situação que melhor expressar seu funcionamento, e não sua estrutura. A grosso modo: Se nosso sistema resolve um problema relativo a segurança de uma casa em Brasília, não deveríamos nos preocupar com a ameaça de um marémoto. Não devemos fazer nossos objetos serem capazes de fazer coisas que eles não vão precisar fazer. Um pensamento como este construirá uma boa arquitetura que terá sempre a robustez para se adequar a mudanças, ou, complementos de atividades.
Parabéns pelos posts e espero estar pensando de maneira coerente.
- Caike

Este é um ponto deveras interessante, como diria um grande amigo.

Orientação a Objetos é pura e simplesmente um conceito técnico. É pegar dados e lógica e manter num mesmo componente, seja através de classes ou qualquer outra forma (por isso tanta gente se espanta quando descobre que JavaScript é OO). É por isso, por exemplo, que Ma href=”http://www.objectmentor.com/ “>Uncle Bob introduz sua apresentação sobre design eliminando o mito de que “objetos modelam melhor o mundo real” e focando sua utilidade em gerenciamento de dependências.

Alan Kay, inventor de Smalltalk e um dos pioneiros na área (ele criou o termo object-oriented descreve em seu paper “The Early History of Smalltalk”:

In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing “computer stuff” into things each less strong than the whole–like data structures, procedures, and functions which are the usual paraphernalia of programming languages–each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computer all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly.

Para Kay, objetos são mini-computadores especializados em um conjunto específico de comportamentos. A idéia do autor era utilizar estes mini-computadores para aproveitar os recursos das máquinas mais eficientes dos anos 70.

Com o passar do tempo surgiu outro tipo de profissional, o que não estava mais tão preocupado assim em resolver problema computacionais mas sim em como a tecnologia pode ajudar seus clientes (este é o elo perdido entre os programadores e os pseudo-analistas de sistemas de hoje). As pessoas desta linha de pensamento começaram a fazer paralelos entre objetos e conceitos do mundo real e perceberam que podiam utilizar as boas características da OOP (herança, encapsulamento, contratos…) para modelar o domínio de um software.

Por isso um objeto serve para modelar o processo de negócios de uma empresa de uma maneira relativamente eficiente (pelo menos mais eficiente que abordagem de programação estruturada) assim como serve para modelar um Servlet, algo completamente tecnológico sem paralelo no domínio de negócios. Ambos, Servlet e objetos de domínio, tiram proveito das características de OO.

Esta falta de relacionamento real entre OO e “modelar o mundo” dá uma pista de que você está no caminho certo. Abstrair é tirar detalhes não-interessantes dentro de um contexto. Quando abstraímos algo nós nos concentramos apenas no que é necessário para fazer o que precisamos, é como quando eu falo para você “meu vôo sai assim que o sol nascer”. O vôo não é meu e ele não depende do Sol nascer para partir, mas você entendeu a mensagem mesmo abstraindo os detalhes. Objetos servem para modelar, seja br.com.empresa.Pedido ou javax.swing.JButton de forma abstraída.

Note que OO nem sempre é o ideal. Cada domínio já desenvolveu na sua história meios para modelar seu domínio. Pense no sempre utilizado exemplo de contabilidade. Por séculos os contadores utilizaram estruturas tabulares para efetuar seus cálculos, estruturas que evoluíram até planilhas eletrônicas como a Google Spreadsheet ou OpenOffice.org Calc. A tecnologia evolui e talvez estes modelos caiam, mas se você se manter próximo destes paradigmas vai conseguir muito mais satisfação ao lidar com usuários. Por isso os domínios expostos com orientação a objetos estão sendo desafiados por domínios expostos por Domain-Specific Languages (DSLs).

Seu exemplo, entretanto, foge mais do conceitual sobre modelagem e entra em princípios de processo de desenvolvimento. Se você mostrar este exemplo para algumas pessoas elas certamente dirão “Ah, mas amanhã pode ser que a empresa venda o produto para alguém no Rio, ou pode ser que o Sertão vire Mar e o Mar vire Sertão“. O que fazer neste caso? YAGNI. Implemente o que você precisa agora, deixe o amanhã para amanhã. Claro que é papel fundamental de um bom arquiteto (e não, arquiteto não é aquele cara que faz diagrama o dia inteiro, na maioria dos projetos todos somos arquitetos em maior ou menor nível) é prever possibilidade de extensão e flexibilidade, mas a minha experiência diz que a melhor maneira de criar flexibilidade sem overengineering é utilizar um ótimo design OO.

Pergunta na lista UML-BR:

Boa tarde a todos,

Estava estudando o DDD (Domain Drive Design)…

Percebi que a camada de negócios deve ser um reflexo da realidade, para que
o sistema possa evoluir de maneira mais fácil (flexibilidade) conforme a
regra de negócios do cliente tb muda…
Por isso temos as entidades.. Por exemplo Funcionario, Departamento, etc…

A duvida que eu tenho é a seguinte:
Vamos supor que eu tenha que exibir todos os funcionários em um JSP… eu
deveria criar um DTO do Funcionario e “mandar” para a camada de visão? ou
posso mandar o proprio objeto de negócio (o que na minha opinião é mais
pratico, já que eu não preciso duplicar código no DTO)?
Pois eu li o Artigo do Phillip Calçado e do Martin Fowler
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
http://www.martinfowler.com/bliki/AnemicDomainModel.html
onde eles dizem que não é bom criar DTO´s… e por isso estou confuso….

O que vcs acham… para exibir as entidades em tela a camada de visão pode
ter contato com as entidades… ou vou ter que duplicar o código criando um
DTO para cada entidade?

[…]

Então eu tb penso assim….

Mas pensando no lado negativo disso, imagine se eu tiver 50 JSP´s mostrando
os dados desse Funcionario…. Ai eu vou e faço uma refatoração no codigo
(talvez mudando metodos de uma classe pra outra, etc)…. vou ter que
verificar nos 50 JSP´s pra ver se não deu nenhum problema, ou até mesmo para
ajusta-los a nova mudança!!!!!
Talvez se eu criasse DTO´s para isso eu não teria esse problema pois os
DTO´s não mudariam…..
O que vcs acham disso…. faz sentido????

valeu pessoal…..

Felipe Regalgo

Você poderia ter objetos de transferência apenas para a interface - DDD
não fala explicitamente sobre isso- mas existem algumas questões
práticas neste sentido:

- Hierarquia duplicada desnecessariamente: Ao manter um DTO (VO é um
nome que já foi usado para DTOs mas não é mais) para isso você está
duplicando toda a sua hierarquia de classes, o que indica código
duplicado, tendo em dois ou mais lugares no seu sistema o mesmo
conceito implementado.

- Mudanças: Da mesma maneira que se eu alterar minha classe de
negócios vou ter que alterar a interface sem DTOs, com DTOs a cada
mudança no meu modelo de negócios *eu tenho que alterar o DTO
correspondente em si*, logo você só transfere o problema de lugar mas
continua com ele -e com código duplicado que é *muito* ruim.

- Se você pensar neste isolamento então precisa de DTOs para qualquer
coisa que não seja camada de negócios, logo vai precisar também para
persistência, por exemplo, caindo nos mesmos problemas acima para
outra camada.

- Encapsulamento: OO exige que suas abstrações sejam encapsuladas, e
isso quer dizer que dificilmente a mudança na implementação de uma
classe vai afetar outras em tão grande escala. Quando isso acontece é
porque houve um grande refactoring ou uma grande mudança de conceito de
negócios, e isso -além de raro- vai afetar seu sistema com ou sem
DTOs. A diferença, como citando no primeiro item, é que sem DTOs você
não precisa se preocupar em mudar vários lugares, apenas a classe de
negócios.

- Conceito de Negócios: DDD pressupõe que seu sistema modela ao mais
próximo da realidade possível. Se uma classe muda no modelo de
negócios é porque seu entendimento sobre o negócio mudou e
provavelmente alguma coisa na interface vai refletir isso.

Em DDD temos os ContextMappers que mapeiam domínios diferentes que
precisam se comunicar. Esta é a abordagem normal para os casos onde se
percebe a necessidade de algo como um ‘DTO interno’.

‘DTOs internos’ (”VOs”) são uma péssima prática, completamente não OO
e difundidas tristemente pela Sun para lidar com as falhas da
arquitetura de EJBs pré 3.0.

[]s

Como todo mundo que bloga há anos, eu estou sem tempo e inspiração para escrever muito (dá pra ver a distância entre um post e outro), então resolvi colocar aqui algumas respostas de e-mails que recebo com questionamentos sobre artigos, posts e etc.

O primeiro segue abaixo:

fromLeandro André Zis
date Feb 23, 2007 11:15 PM
subject Artigo MVC e Camadas, Repositorio e DAOs

Ola Phillip,

No artigo MVC e Camadas mostra os DAOs herdando do repositorio, isto
esta correto?

Leandro Zis

Oi, Leandro,

Sim, está.

Um repositório é um conceito abstrato. Ele representa o lugar onde os objetos estão guardados esperando serem utilizados por alguma operação. Os outros objetos de negócio não enxergam nada além dele, ou seja, não sabem onde os objetos são guardados de fato, num banco de dados, arquivos CSV, etc.

Um DAO (Data Access Object) é uma encarnação do padrão Data Mapper cuja responsabilidade é mapear um objeto para tabelas e vice-versa.

Desta forma o DAO pode se tornar a implementação do Repositório. Os objetos de negócios sabem apenas que podem guardar e recuperar objetos do Repositório, nada além disso. Por baixo dos panos eles estão utilizando um DAO que implementa o Repositório, cuja responsabilidade é apenas salvar e recuperar objetos do banco de dados nada além disso.

Existem casos onde os Repositórios devem ter lógica de negócio incluída. Isso não é muito comum, se for o caso vale uma revisão do design da aplicação, mas se realmente for necessário aí provavelmente você vai querer criar o Repositório como uma classe de negócios que delega as atividades de persistência para um DAO. Fazer este Repositório com regras uma classe abstrata que o DAO herda seria ruim porque numa classe (o DAO) haveria responsabilidade de negócios e persistência.

[]s