Pesquisar

quarta-feira, 11 de março de 2009

Abordagens e Abordagens

Motivado por uma discussão calorosa sobre meu projeto e o extremismo do OO (no forum WTF daily) o projeto recebeu mais de 500 visitas num só dia, a principal crítica era sobre a quantidade de classes (uma por cada opCode) desnecessárias... o que fez com que os gringos classificassem o projeto como WTF do OO (claro que dentro da discussão haviam aqueles que não achavam que o projeto deveria ganhar esse título também).

Resumidamente o processador do nintendo 8bits é um 6502 modificado, a sua arquitetura conta com 11 meios de se obter os operadores (basicamente em baixo nível você tem uma instrução e os operadores pra mesma), com isso a mesma operação pode ser feita de várias formas...

Exemplo: Para a instrução STA (carregue o registrador Accumulator) existem várias STA's: STA $10, STA ($10),Y , STA $1002 ... (sta direta, sta indexeda por y, sta indireta....)

Logo criou-se a situação de que eu tomei a decisão de uma interface Instrução e criei várias classes abstratas InstrucaoAbsoluta, InstrucaoRelativa, InstrucaoIndexadaY ... e várias subclasses concretas LDAAbsoluta, LDARelativa... (sendo que o trabalho de se obter o operador ficaria a cargo da classe pai).

Com isso tenho REALMENTE MUITAS CLASSES isso foi uma das reclamações. Hoje penso que poderia (e ainda posso mas ando focado no debugger) fazer algo mais ou menos assim.
lda(immediate());
lda(absolute());
sta(immediate());
sta(absolute());
Só isso reduziria e muito o número de classes apenas com a composição correta delas.

A outra indagação é sobre o meio que usei para se interpretar cada opcode. Normalmente um interpretador agi mais ou menos assim:

switch(coisaASerInterpretada){
case 0xFA: fazA();
case 0xFB: fazB();
}

E minha abordagem foi diferente, coloquei todas as "funções" num hashmap generic e apenas executava.

O preenchimento:
hash.add(0xFA,new FazA());
hash.add(0xFB,new FazB());
Quando fosse usar:
hash.get(coisaASerInterpretada).execute();

Eles não discordaram do jeito que fiz as coisas; mas de ter usado HashMap ao invés de um simples array. Acredito que realmente seja verdade, é desperdício usar um HashMap ao invés de um array comum mas nesse caso prefiro correr "esse risco bobo calculado" a ter que declarar uma array maior do que o necessário já que o índice do vetor seria a identificação da operação e aproveitar das facilidades do hashmap (melhor ainda pra buscas...).

Não posso deixar de rir um pouco com as opiniões xiitas mas também não concordo que isso poderia fazer um projeto ser classificado como um WTF (what the f%ck)

2 comentários:

Anônimo disse...

qual projeto você se refere?

leandro disse...

foi mal, estava falando do http://code.google.com/p/jnesbr/ JnesBR