Post indexador sobre o que escrevi sobre OO em Javascript nesse blog apenas para guardar como referência rápida de consulta, estou revisando todos os posts para verificar o que falta escrever.

Name Binding

Herança no javascript

Overloading e overriding no Javascript

O governo do estado inaugurou essa semana “A Conta do Paciente“, um projeto inédito no Brasil que vai informar ao paciente quanto foi sua despesa desde a entrada no hospital até sua alta. Esse tipo de atuação aproxima o governo da agilidade que a sociedade cobra em relação à transparência nas contas públicas, antes era quase impossível saber o custo real por paciente. Fora que a secretaria vai saber precisamente e em tempo real os custos por unidade, além de facilitar a tomada de decisões que podem salvar vidas.

Esse formulário detalhado com a conta do paciente é possível graças ao ERP especialista em gestão hospitalar pública da empresa Insystem, nosso cliente e parceiro. A Insytem acreditou em nosso trabalho e é um dos maiores Cases, senão o melhor.

O ERP foi construído 100% com base em TDD em Java usando DWR, Hibernate e  Spring basicamente. Alguns requisitos necessários de usabilidade utilizam Reverse Ajax com DWR. O sistema é totalmente ajax e utiliza o Extjs seguindo a filosofia model 3. Fizemos algumas customizações no Extjs para se integrar ao DWR de forma transparente.

Fomos ágeis desde o primeiro momento, mas nunca nos preocupamos em implantação de processo, metodologia ou qualquer coisa que o foco não fosse software saudável. XP foi algo natural, valores e princípios foram assimilados desde o primeiro dia, mas foi e é o software funcionando e livre de erros [o mais livre possível] que nos moveu.

Destaque para o Felipe Andrade, funcionário da Insystem que se tornou especialista em Extjs com DWR e hoje domina e é talvez o maior conhecedor da união desses Frameworks no estado.

Agradecimentos especiais aos diretores Evando Chaves e Marcelo Meirelles que investiram nessa solução e tiveram a sagacidade de sair na frente da concorrência entendendo que software funcionando é mais importante do que processos bonitos e pomposos, afinal o barco não chega na frente por causa do tambor e sim dos remadores. A Insystem está de parabéns por ter enfrentado todas as correntes contrárias e ter chegado a essa vitória investindo e apostando no fator humano como responsável para a vitória.

Esse é um Case que entrou para a história, estamos procurando outra solução semelhante na saúde pública do Brasil e até agora não encontramos nada.

Orgulhoso por participar dessa conquista.

Como sempre criaram uma nomenclatura totalmente diferente para entidades da API, dificultando o entendimento da comunidade com anos de uso da única implementação que possuía essa API: Hibernate. Comparem a API de Criteria do Hibernate com a API de Criteria da Spec. Ok, podemos aceitar isso, política…

Faltou muita coisa ainda, mas parece que estão trabalhando para melhorar até a versão final, pelo visto DELETE_ORPHAN vai sair de alguma forma:

@Target({METHOD, FIELD}) @Retention(RUNTIME)
public @interface OneToMany {
    Class targetEntity() default void.class;
    CascadeType[] cascade() default {};
    FetchType fetch() default LAZY;
    String mappedBy() default "";   
    boolean orphanRemoval() default false;
}

Nota para os leitores:

Open Issue: We also discussed the alternative of introducing a separate annotation for the orphanRemoval functionality and the alternative of introducing a REMOVE_ORPHAN cascade
option. We would welcome feedback on the form that this metadata should take.

Não encontrei nada sobre como manipular as estratégias de fetching – que é primordial – nos relacionamentos como temos no Hibernate: Select fetching, Subselect fetching, Join fetching e Batch fetching. Nem a API de Criteria possui estratégia com FetchMode, apenas uma “Issue” aberta para a interface FetchJoinObject que deverá trabalhar isso, eu espero.

Ainda assim continuamos indicando o uso do Hibernate direto ao invés da especificação até que a especificação seja estável o suficiente com features decentes para um desenvolvimento sério em Java. A API de Criteria da implementação Hibernate continua ainda muito superior principalmente se você precisar de consultas um pouco mais avançadas.

Confiram o material e decidam.

Features proprietárias são sedutoras, antigamente usávamos grids com paginação no HTML com a propriedade datasrc na tag table, podíamos ler inclusive de arquivos XML. Isso muito antes de Ajax ou até do Firefox. Evidente que só funcionava no IE.

<XML ID="users">
<?xml version="1.0" ?>
<users>
	<user id="1" name="Christiano Milfont"/>
	<user id="2" name="Rafael Ponte"/>
</users>
</XML>
 
<TABLE DATASRC="#users">
<TR>
<TD><DIV DATAFLD="id"></DIV></TD>
<TD><DIV DATAFLD="name"></DIV></TD>
</TR>
</TABLE>

Com a popularização do Firefox e a necessidade das aplicações serem CrossBrowser, tivemos que nos adaptar às specs da W3C. Praticamente todas as aplicações WEB precisaram serem reescritas -algumas até hoje ainda só “rodam” no IE.

Usar uma Feature proprietária facilita, mas no final você pagará o preço da não interoperabilidade. Agora precisamos usar um Framework Ajax para fazermos coisas que antes era nativo. No IE tínhamos até DnD.

Especificação muito mais frágil do que as implementações nos força a criar uma “Isolation Layer” como solução de refactoring sem comprometer o sistema. Podemos então usar as features nos beneficiando do que a implementação tem a oferecer sem comprometermos o resultado final, o uso fica encapsulado na solução.

Especificação mal feita

O problema é quando a definição de uma especificação fica frágil o suficiente – por problemas políticos – para forçar um refactoring profundo na mudança entre implementações.

No CEJUG, ocorreu uma thread sobre problema com data na JPA, onde eu recomendei retirar a anotação @Temporal – que já tinha me dado trabalho anteriormente – e por “feeling” eu sabia que o problema era nessa anotação, mas nunca tinha pesquisado para saber o real porquê. Como quem ganhou dinheiro com Feeling no Brasil foi apenas Morris Albert – by Cardoso – eu dei uma pesquisada sobre isso e descobri que [como escrevei no email]:

From CMilfont
to discussao@cejug.dev.java.net
date Mon, Oct 27, 2008 at 9:54 AM
subject Re: [cejug-discussao] problema com data

Dei uma pesquisada e a conclusão que cheguei é:
A spec determina que propriedades do tipo Date e Calendar [util java] devem ter a anotação @Temporal.
TopLink obriga, se não tiver lança uma exceção ValidationException [pelo menos foi o que vi na documentação dele, não cheguei a testar].
Hibernate é opcional, mas se você colocar ele devolve uma instância de Calendar, porque entende que a data é completa [como Timestamp] mesmo dizendo que o tipo é Date – aqui entendo como uma falha e vi que as issues sobre isso no projeto já foram fechadas, os últimos builds devem ter consertado, ou não.
A spec não diz que deve lançar exception mesmo dizendo “must be” então o Oracle TopLink assumiu essa responsabilidade.
Claro que essas funcionalidades devem também mudar de build para build então podem ter diferenças nas versões de builds entre os próprios implementadores, como Hibernate e TopLink mudarem da versão x.x.1 para x.x.3 por exemplo.
Coisas de spec mal escrita, JPA tem que ser urgente revista, os capítulos ficam muito ambiguos, tem trechos que você fica bastante confuso, diferente de specs como da JSE que é bastante clara.

O problema disso é que não dá para encapsular a diferença entre as implementações porque o uso dessa anotação é incompatível entre dois desses implementadores.

Outro problema da JPA é a falta de elementos básicos que um ORM deve implementar – como a Criteria – impossibilitando a troca de implementações com um simples refactoring. Tudo bem que em um Domain Model você tem como – e deve – isolar essa diferença entre Engines ORM mas em termos de Refactoring da aplicação no geral, ter que reescrever todas as buscas de uma aplicação porque a Engine não suporta Criteria pode não afetar o modelo mais trará um prejuízo enorme.

Como o Hibernate é OpenSource, maduro e anos-luz à frente até da nova especificação de JPA 2.0, a escolha dele pelos profissionais experientes é a mais adequada. Spring, é outra solução ao JEE sem EJB que permanece como indicação desde o livro do Rod Johson de 2004 que era ainda sobre EJB2, recomendava o uso de JEE sem EJB e apresentou o Spring oficialmente ao mundo. Apesar de que Spring e EJB3 estarem bem nivelados hoje em dia, Spring ainda leva uma certa vantagem, ainda mais pela maturidade e semrpe estar nos trilhos corretos, coisa que o EJB está se ajustando aos trancos e barrancos.

Em regra eu sempre recomendo o uso de especificações, mas em determinados pontos a especificação é desaconselhada e o uso direto da implementação tem suporte mais adequado. Não temos o poder de sempre escolhermos as ferramentas mais adequadas, muitas vezes a política impera – como nos órgãos públicos que são obrigados a usarem Oracle ou IBM por imposição governamental feita em um escritório na Casa Civil.

Agora são 3 artigos meus publicados http://www.milfont.org/tech/published/

http://www.devmedia.com.br/resumo/default.asp?site=6

Escritores de Fortaleza

Orientação a Objetos no Javascript
Por: Christiano Milfont

Nesse artigo estudaremos como está fundamentada a orientação a objetos no Javascript e como entender a sintaxe dentro desse conceito. Todos os Frameworks Ajax modernos estão codificados com a orientação a objetos como base.

MP3 Player ME
Por: Ernandes Mourão Júnior

Neste artigo, vamos mostrar como podemos inserir a plataforma Java ME nesta estória. Vamos criar um cenário onde o seu dispositivo móvel não possui um tocador de MP3, mas você gostaria de ter um para poder ouvir as suas canções favoritas. Para isto, vamos mostrar o desenvolvimento de um tocador de MP3 simples, utilizando-se da JSR 75 – PDA Optional Packages e da JSR 135 – Mobile Media API (MMAPI). Explorando-as desde os conceitos até a prática, com exemplos de código.

Escritores de Natal

Gráficos em Sistemas Web
Por: David Pereira, Itamir Filho e Raphaela Galhardo

O artigo apresenta um conjunto de técnicas para criação de gráficos em sistemas web.

A abordagem de Domain Model proposta por Eric Evans, consegue isolar o núcleo do sistema (responsável pela lógica de manipulação das informações e processos de negócios) abstraindo das particularidades da arquitetura por meio de suas técnicas modernas e maduras. Mesmo assim o esforço de isolamento não é tão claro mesmo para coisas triviais como segurança, onde existe uma linha tênue entre o que é requisito funcional ou não.

Na construção do seu modelo, a profusão de abordagens como Fluent Interfaces e DSL ajudam a maximizar o entendimento do negócio, mas ainda assim restam dúvidas de como e onde aplicar adequadamente.

Confusão

Tenho visto muitos bons desenvolvedores caírem na onda do Hype e se tornarem fanboys “*-tards” e saírem por aí alegando que a linguagem X ou outra coisa qualquer é evolução do Java/C# ou coisas desse tipo, comparando linguagens de abordagens tão distintas entre si e até de paradigmas diferentes. Esse pessoal esquece “o porquê” de existirem tipos estáticos e dinâmicos, fortes e fracos. Uma linguagem funcional não é evolução de uma linguagem orientada a objetos, se bem que o vice-versa é contraditório porque alguns autores alegam que o object calculi seria evolução do lambda-calculi. Linguagens de tipos dinâmicos não são evolução de tipos estáticos, já existiam e servem para propósitos diferentes. Da mesma forma existem JAVAtards que esquecem que existem outras funcionalidades que Java não implementa (lembre-se que você não cria um MapReduce sem conhecimentos profundos de programação funcional).

O ponto principal é que os tipos estáticos são importantes em linguagens imperativas e são importantes na definição da camada de negócio, mas linguagens dinâmicas também o são, pela agilidade nas mudanças e na complexidade da arquitetura. Imagine o custo de um deploy para cada refactoring e mudança em uma arquitetura JEE e compare com o mesmo nível de complexidade de mudança em PHP ou Ruby.

O mais comum ultimamente é a divisão da camada de negócios em duas zonas distintas: uma estática, implementada com uma linguagem estática e fortemente tipada como Java; e uma dinâmica, implementada com o sabor de script que você goste, como ruby, javascript ou python.

Camada estática

Existem princípios em qualquer negócio que por mais ágil que esse negócio seja e mude constantemente, esses princípios nunca mudam, são aquelas funcionalidades facilmente detectadas na modelagem tradicional, onde se detecta o caminho principal de um ator pelo caso de uso e podemos prever os caminhos alternativos.

Alguns pseudoanalistas imaginam que todas as funcionalidades se revelam na modelagem tradicional e se não cobriu todas as possibilidades é porque falhou o processo de desenvolvimento. Essas funcionalidades facilmente detectáveis e controláveis fazem parte da camada estática do seu modelo, não devem mudar nunca ou muito pouco em relação à vida útil do software.

Imagine um sistema contábil, os princípios de crédito e débito, plano de contas, livros contábeis, a própria operação de contabilização a partir de documentos entre outros aspectos são os mesmos há uns 200 anos e mudaram muito pouco nesse tempo todo. Falo sobretudo da contabilidade fiscal. Uma modelagem desses princípios vai sofrer pouca alteração durante toda a vida útil do software.

Imagine o sistema jurídico, é praticamente o mesmo dos romanos. Imagine um sistema de vendas, desde a troca de sal por um carneiro, surgimento da moeda ao cartão de crédito, os princípios são os mesmos.

Para implementar essa camada, uma linguagem de tipos fortes e estáticos é o mais indicado.

Camada dinâmica

Agora imagine toda a contabilidade gerencial que é realizada com base na contabilidade fiscal. Imagine todas as operações possíveis e combinações imaginárias de vendas. Todos os cálculos de impostos que os governos mudam todo ano. A análise e modelagem total dos casos de usos é praticamente impossível e se mostrou inviável ao longo do tempo.

Alguém pode sugerir a utilização de métodos ágeis para solucionar esse problema em linguagens estáticas mas não é o bastante. Os métodos ágeis surgiram para prepararem as equipes para as mudanças, suavizar o impacto que refactoring causam no código. Observem que estamos falando apenas de negócio, puro negócio. Os métodos ágeis não dizem como fazer o seu código, eles te auxiliam.

A abordagem de utilizar uma linguagem dinâmica para esses requisitos mutáveis e tardiamente diagnosticáveis se mostrou eficientíssima. Isolamos parte do Domain Model para ser provido de uma linguagem dinâmica (de script de preferência), e concentramos na facilidade de montar um idioma comum para a equipe sem o custo de build ou deploy de linguagens estáticas.

Segmentação

Dividimos então essa camada dinâmica em duas camadas interiores: uma da própria linguagem dinâmica que facilita as modificações ágeis (aconselhavelmente com Fluent Interfaces); e outra mais rebuscada, criada para a criação de regras (DSL com ou sem Fluent Interfaces) e uma linguagem comum entre a equipe e os operadores do sistema que são geralmente não técnicos mas treinados para isso.

Implementação

Trabalhemos com esse pequeno exemplo, tenho uma operação fecharVenda de uma hipotetica classe Venda que entre suas responsabilidades, existe a geração de comissão do vendedor.

1
2
3
4
5
6
7

public void fecharVenda() {
 ...
	//pre-execução
 	this.vendedor.setComissao(this.valorTotal * (5/100) );
	//pos-execução
...
}

Agora imagine que surgiu uma modificação no sistema, existem dois percentuais diferentes. Isso é moleza, você refatora a operação com a modificação:

1
2
3
4
5
6
7
8
9
10
11
12
13

public void fecharVenda() {
 ...
 
	//pre-execução
	if(this.tipo.equals("VendaTipo1"))
		this.vendedor.setComissao(this.valorTotal * (5/100) );
	}
	if(this.tipo.equals("VendaTipo2"))
		this.vendedor.setComissao(this.valorTotal * (8/100) );
	}
	//pos-execução
...
}

Ah! Mas eu sou esperto, criei uma propriedade lá que amarro o tipo de documento com o percentual apropriado:

1
2
3
4
5
6
7
8

public void fecharVenda() {
 ...
	//pre-execução
	this.vendedor.setComissao(this.valorTotal 
                   * this.vendedor.getPercentualApropriado() );
	//pos-execução
...
}

Daí chega o seu cliente todo fogoso e diz que a regra mudou, agora não é mais no total da nota e sim nos ítens, cada item pode ter um percentual diferente. O caminho mais usual é você refatorar o item e copiar a propriedade para lá, percorrer todos os produtos no método fecharVenda e calcular a comissão, claro, deixando a abordagem atual comentada caso o cliente deseje voltar como era antes.

Usando uma linguagem de Script

Observe no comentário //pre e //pos execução, que acha de injetar uma chamada a um script no método?

Você faria essa última modificação assim em javascript (com Rhino):

Chamada ao Script que será injetado no modelo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName("JavaScript");
try {
	engine.put("lista", this.itens);
	engine.put("vendedor", this.vendedor);
	engine.put("nf", this);
	engine.put("total", this.total);
	engine.put("totalDescontos", this.totalDescontos);
	String path = NotaFiscal.class.getResource("script.js").getPath();
	engine.eval(new FileReader(path));
	this.total = (Double) engine.get("total");
	this.totalDescontos = (Double) engine.get("totalDescontos");
} catch (ScriptException e) {
	e.printStackTrace();
} catch (FileNotFoundException e) {
	e.printStackTrace();
}

Código no script.js:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

(function() {
	var _$ = function(els) {
		this.elements = [];
		var iterator = els.iterator();
		while(iterator.hasNext()) {
			this.elements.push(iterator.next());
		}
		return this;
	};
	_$.prototype = {
		each: function(fn) {
			for ( var i = 0, len = this.elements.length; i < len; ++i ) {
				fn.call(this, this.elements[i]);
			};
			return this;
		},
		comissionar:function(vendedor) {
			var comissao = function(e) {
				vendedor.comissao += (e.total * e.percentual);
			}
			this.each(comissao);
		}
	};
	$ = function() {
		return new _$(arguments[0]);
	};
}());
$('lista').comissionar();

Fortemente inspirado no código do prototype resolvi o problema temporariamente sem precisar refatorar o código da aplicação e deixei aberto para quantas modificações forem necessárias nessa parte que é variável.

A notação húngara influenciou outras áreas como Banco de dados. Criaram notações para objetos de banco devido às deficiências das ferramentas em identificar tipos, os DBAs mantiveram o costume de padronizar os nomes dos artefatos com prefixos e as vezes tambem com sufixos. Na SEAD-Ce usávamos “TB_” como prefixo de tabelas para diferenciar de “TR_” para triggers. Isso tem uma valia grande para um DBA na hora de listar os objetos no Oracle ou criar rotinas de manipulação.

Mas pelo amor de Javé, não use isso em uma linguagem orientada a objetos, ainda mais com tipos fortes e estáticos como JAVA.

Imagine a seguinte situação em java:

Class Categoria {
 
    private String nomeCategoria;
 
    //segue ...
 
}

Se nome é uma propriedade da classe Categoria, para que diabos nomear como nomeCategoria? Com qual Objetivo? Qual a vantagem que isso trás?

O pior é definirem padrões semelhantes ao que o DBA (que tem necessidade disso) define para seus artefatos em uma linguagem OO. Vi padrão definido como “usar as três primeiras letras da classe antes das propriedades” e todo tipo de monstruosidade.

Nem que voce me prove que usa o bloco de notas para programar, eu ficaria convencido da real utilidade disso.

Dar manutenção em código desse tipo mais atrapalha do que ajuda, fora que construir também nunca vi utilidade nisso.

Usar notação Java padronizada pela SUN tudo bem , como definir o nome de variáveis em minúsculo e as demais palavras com a primeira letra em maiúsculo, mesmo assim é uma sugestão para facilitar o reconhecimento pela comunidade, se você não quiser seguir o código compila numa boa. Outras comunidades definem a segunda palavra separada por “_” como data_inicio. Mas nada de PTcaixaDoisDTO por favor.

Não invente notação estranha para seu código, imagine que a pessoa que vai dar manutenção é o Dexter Morgan e ele sabe seu endereço.

Todos os objetos definidos pelo desenvolvedor são candidatos a objeto base. Como medida de segurança as classes Native e Host não estão eleitos a servirem como objetos base.

Selecionado o objeto base, agora voce pode criar os objetos que herdarão e modificarão o objeto base conforme os requisitos. Os objetos filhos criados pelo desenvolvedor herdam todas as propriedades e métodos do objeto base, incluindo o construtor e as implementações de métodos. Lembrando que todas as propriedades e métodos são públicos, então os objetos podem acessá-los diretamente. Esses objetos podem adicionar novas propriedades e métodos não presentes no objeto base ou reescrever com novas implementações.

Keyword This

A palavra chave This faz referência ao escopo do objeto onde ela está sendo chamada.

Como o uso do This no ECMAScript existe a possibilidade de emular os escopos privados usando a palavra chave var, já que por default a linguagem só conhece o escopo público.

function objetoY()  {
    var variavel_privada = "Essa variável é privada";
    this.variavel_publica = "Essa variável é pública";
}

Nesse código a variável denominada “variavel_privada” não é propriedade do objeto “objetoY” e sim uma propriedade local ao contexto desse objeto, simulando assim uma variável privada já que outros contextos não terão acesso a ela, apenas métodos e propriedades internas ao objeto, enquanto a propriedade “variavel_publica” faz parte do objeto e é de escopo público.

Herança via Object masquerading

É uma estratégia que emula a herança, um construtor associa todas as propriedades e métodos (com o paradigma de declaração de Construtor) usando a keyword “this” para o contexto interno do qual foi referenciado. Porque o construtor é como uma função, voce pode montar o construtor de um objeto “A” dentro de um método de um objeto “B” e chamá-lo. O objeto “B” então recebe as propriedades e métodos definidos no construtor de “A” porque o this agora aponta para o contexto do novo objeto.

Cria o objeto que servirá de base:

function A(sColor) {
    this.color = sColor;
    this.sayColor = function () {
        alert(this.color);
    };
}

Agora eu crio o objeto chamado de “B” que herdará de “A”, quando eu chamo o objeto “A”, ele é referenciado ao contexto interno e o “this” passa a pertencer a “B”:

function B(sColor, sName) {
    this.newMethod = A;
    this.newMethod(sColor);
    delete this.newMethod;
    this.name = sName;
    this.sayName = function () {
        alert(this.name);
    };
}

Ao executar essas sentenças:

var objA = new ClassA('red');
var objB = new ClassB('blue', 'Nicholas');
objA.sayColor(); //outputs 'red'
objB.sayColor(); //outputs 'blue'
objB.sayName(); //outputs 'Nicholas'
alert(objB instanceof A ); //false
alert(objB instanceof B ); //true

Temos as mesmas chamadas de A em B com emulação completa da herança.

Como perceberam, Object Masquerading suporta a implementação de múltipla herança, mas como se trata de uma estratégia de emulação, essa abordagem não define o tipo do objeto que herda semelhante aos tipos herdados e portanto falha ao tentar comparar pelo “instanceof“.

Herança via métodos call() e apply()

Os métodos globais call e apply (que todo objeto herda do objeto Global) são estratégias semelhantes ao “Object Masquerading” e importam o contexto de um objeto ao outro.

call(Objeto, argumento1, argumento2, ...)
apply(Objeto, array-de-argumentos)

Se diferenciam somente no quesito que se refere aos parâmetros passados, onde o método call recebe uma sequencia de parâmetros, enquanto o método apply recebe um array de parâmetros.

function nome(sPrefixo, sSufixo) {
    alert(sPrefixo + this.parametro_interno + sSufixo);
};
var obj = new Object();
obj.parametro_interno = 'Milfont';
nome.call(obj, 'O ', ' é o mais elegante. ');

Observe que nesse exemplo a função “nome” está definida fora do objeto “obj” e associa a propriedade parametro_interno a seu próprio contexto, utilizamos o método call para passar o objeto “obj” ao contexto da função “nome” e a sequência de parâmetros esperados pelo seu construtor.

A função apply se comporta da mesma maneira e difere apenas na execução:

nome.apply(obj, new Array('O ', ' é o mais elegante. '));

Ao invés de passar os parâmetros em sequência, passamos um array com a sequência desses parâmetros.

A vantagem do método apply é que toda função tem uma propriedade chamada arguments que herda do objeto Global e facilita a implementação:

function A(sNome) {
    this.nome = sNome;
    this.digaNome = function () {
        alert(this.nome);
    };
}
 
function B(sNome, sName) {
    A.apply(this, arguments);
    this.sobrenome = sName;
    this.digaSobrenome = function () {
        alert(this.sobrenome);
    };
}

Aqui temos dentro da função “B” a chamada de “A” passando pelo método apply o contexto de “B” para o interior da função “A”, observe que repassa a propriedade arguments que é um array de argumentos recebidos.

Executando, teríamos:

var objA = new A('martins');
var objB = new B('Christiano', 'milfont');
objA.digaNome();  // 'martins'
objB.digaNome();  // 'Christiano'
objB.digaSobrenome(); // 'milfont'

Herança via Prototype

A forma de herança atualmente reconhecida pela especificação é a cadeia de protótipos ou Prototype chaining. Utilizando a propriedade prototype que todos os objetos herdam de Global, voce associa o contexto (métodos e propriedades) a outro objeto e o qualifica a ser do mesmo tipo do objeto que ele está recebendo.

function A() {}
A.prototype.nome = 'red';
A.prototype.digaNome = function () {
    alert(this.nome);
};
function B() {}
B.prototype = new A();

Aqui a função B recebe todos os métodos e propriedades de A e passa a ser do tipo dela, executando teríamos:

var objA = new A();
var objB = new B();
objA.nome = 'martins';
objB.nome = 'Christiano';
objA.digaNome(); // martins
objB.digaNome(); // Christiano
 
alert(objB instanceof A); // true
alert(objB instanceof B); // true

Formas híbridas podem ser usadas, mesclando esses métodos na construção dos objetos.

Multipla herança

Algumas linguagens orientadas a objetos habilitam o suporte à múltipla herança. Que é a capacidade de um objeto herdar as propriedades (métodos e atributos) de mais de um objeto. Além que esse objeto passa a ser da espécie dos objetos que ele herda, como por exemplo:

function Passaro(){
    this.nome = 'papagaio';
}
function Produto(){
    this.valor = 'R$10,00';
}
 
Passaro.prototype = new Produto;
Passaro.prototype.imprimir = function(){
    return this.valor + ' - ' + this.nome;
}

Uma classe PetStore poderia realizar um teste se o periquito é dos tipos Produto e Passaro para aplicar medicamento adequado à espécie por exemplo, esse tipo de construção é comum em linguagens como C, é simulado em Java por meio de interfaces.

var passaro = new Passaro();
alert(passaro instanceof (Produto)); // saida: true
alert(passaro instanceof (Passaro)); // saida: true
alert(passaro.imprimir()); // saida: "R$10,00 - papagaio"

Javascript não suporta múltipla herança pelo método de prototype que é o método que define o tipo do objeto, existe entretanto como contornar isso, um exemplo é a biblioteca zInherit (http://www.nczonline.net/downloads/) de Nicholas C. Zakas (http://www.nczonline.net/writing/), autor dos excelentes livros “Professional Ajax” e “Professional JavaScript for Web Developers”.

Esse script acrescenta os métodos inheritFrom e instanceOf ao objeto nativo Object.

function Biologia(){
    this.reino = 'animal';
}
function Produto(){
    this.valor = 'R$10,00';
}
function Passaro(){
    Produto.apply(this);
    Biologia.apply(this);
    this.nome = 'periquito';
}
 
Passaro.prototype.inheritFrom(Produto);
Passaro.prototype.inheritFrom(Biologia);
Passaro.prototype.imprimir = function(){
    return this.reino + ' - ' + this.valor + ' - ' + this.nome;
}
 
var passaro = new Passaro();
alert(passaro.instanceOf(Produto)); //saida : true
alert(passaro.instanceOf(Biologia)); //saida : true
alert(passaro instanceof (Passaro)); //saida : true
alert(passaro.imprimir()); // saida: "animal - R$10,00 - papagaio"

O metodo apply() habilita a aplicar um método de outro objeto no contexto de um objeto diferente.

Os frameworks modernos como ExtJS e YUI tem suas formas de implementarem a múltipla herança. Uma das formas mais utilizadas pelos Frameworks Ajax é copiarem os métodos e variáveis de um protótipo ao objeto que herdará.

Minhas críticas derivam principalmente da falácia e do sofismo, as pessoas acreditam que possuir um nível superior as credita para a qualificação necessária a uma determinada tarefa simplesmente. Quantos alunos estão se formando esse ano em Ciência da Computação sem a necessária qualificação? A maioria? Todos? Nenhum? Como saber se não existe um mecanismo eficiente de provar isso?

Na ausência de um mecanismo eficiente, o mercado sempre adota pontos factuais para basear suas contratações, e uma delas é o porte de um diploma de curso superior.

Fiz quase todas as cadeiras que envolvem desenvolvimento de software: Estrutura de dados, laboratório 1 e 2, técnicas de programação 1 e 2, lógica matemática, teoria da computação, entre outras que não lembro no momento. Em todas essas cadeiras nunca ouvi o professor(a) sequer mencionar coisas como: Closure, Currying, Continuation, Design By Contract, Actor model, Lazy evaluation, Tail recursion, Quine, Engine, Liskov substitution principle, … mais algumas coisas que não lembrei no momento …

O básico de orientação a objetos é ensinado, o aluno consegue até responder o que é herança e encapsulamento, mas eu nunca vi sequer mencionarem Orientação a Objetos Prototype-based, aí tenho que me deparar com gente dizendo que Javascript ou Lua fede porque simplesmente não entende como funciona os conceitos e acha estranho a sintaxe das linguagens.

Eu mesmo passei a faculdade inteira sem discutir design patterns, com exceção de DAO, que eventualmente pula na frente dos alunos em alguma cadeira obscura de "desenvolvimento web" (sic). Hoje um amigo estava impressionado com as recomendações que o pessoal da SUN passou sobre o GoF na caravana de ontem, e eu falei para ele que isso é naftalina, sério, se em 2007, o GoF é novidade para você, algo de muito sério aconteceu com sua formação.

Tive um professor muito bom, Hélio Moura, que usava na época a primeira edição do livro "Applying UML and Patterns"(que é de 1997 e faz portanto 10 anos) do Craig Larman, referência na época para RUP, e passou alguns princípios legais como GRASP, Law of Demeter, Open/closed principle, entre mais algumas coisas legais que não lembro agora. Mas isso foi uma exceção, e esse professor não ministra mais aulas na faculdade onde estudo. Isso era coisa de 99 ou 2000, início do milênio, vi que os professores de lá ainda usam a mesma versão do livro do Craig. Detalhe, já estamos na terceira edição e com mudanças significativas.

Agora PoEAA do Martin Fowler que é bom, voce vai passar batido, nem tenha esperança de discutir isso em sala de aula.

Domain Model? isso é anos-luz da academia brasiliana, vá estudar que é melhor. Domain Driven Design também é assunto inexistente, procure outra freguesia.

Metodologias ágeis, enquanto a academia está descobrindo XP (timidamente claro), o mercado já discute a fusão entre XP, Scrum, FDD, Crystal, DSDM. Até a Microsoft tem métodos ágeis enquanto a academia consolida UPs como novidade.

A maioria sai da faculdade monoglota, com apenas o conhecimento específico de uma linguagem de programação, enquanto deveriam estudar princípios, estão estudando linguagem. Programação funcional até pode ser vista, talves raramente em uma cadeira de calculo, ou IA (com LISP) se der tempo, alguns confundem sentenças com paradigmas, tinha um professor que falava que por a linguagem ter sentença condicional como um "IF", ela não poderia ser considerada 100% Orientada a objetos, entre outras sandices bizarras. DSL? bah!

Conversando com um amigo dia desses lá na faculdade, entramos no assunto banco de dados, sem querer surgiu no meio da discussão sobre formas normais, para minha surpresa ele disse que não sabia do que eu estava falando, achei estranho porque o professor de banco de dados 1, cadeira responsável por esse conteúdo, é um excelente professor, Fernando Siqueira, e conhecendo ele eu sabia que não passaria ninguém sem ensinar formas normais. Depois esse meu amigo voltou e falou que deu uma "olhada" no livro e "lembrou". Ora, isso me causa apreensão, mesmo eu sabendo que o professor tem a competência sobre uma matéria e tenho certeza que a aplicou, porque um aluno simplesmente esquece o principal conteúdo de uma determinada matéria?

São mistérios, mas mistério mesmo é uma menina que se forma esse ano e não sabe ainda para que serve um banco de dados, mesmo evidentemente ter cursado todas as cadeiras de banco de dados. Isso sim merece estudo, tese, trabalhos científicos e tudo que nós pudessemos descobrir.

Livros

A minha escola real são os livros, tive e tenho alguns bons professores, uns poucos excelentes, mas os autores clássicos são os mestres dos meus mestres. Não procure livro específico, procure autor, e toda a cultura por volta desse autor.

Posso indicar alguns que são a base da carreira de qualquer desenvolvedor que se preze: Alan S. Koch, Alistair Cockburn, Bertrand Meyer, Craig Larman, Eric Evans, Joshua Kerievsky, Kent Beck, Martin Fowler, Rod Johnson, Ron Jeffries, Steve McConnell, Robert C. Martin, … isso só dando uma olhadela aqui na minha "biblioteca". Sei que esqueci nomes importantes, mas se você seguir essa lista, vai acabar caindo neles.

O pior disso tudo é que o pessoal fica empolgado com título aqui, o cara virou doutor já se acha semi-deus, são praticamente inacessíveis, é muito mais facil você falar com Martin Fowler do que falar com um Doutor brasileiro.

Então voce tem duas alternativas, estudar ou frequentar a faculdade, dá para conciliar as duas, mas a preferência será sempre para o estudo, ele que pagará o leite de cada dia, aliás… leite não que esse está matando ultimamente, e ei que pensei que era a cerveja