Já que o Ano Novo tá ae,...

... eu tô cheio de recessos no trabalho e ainda se bateu um desespero programístico sobre mim, resolvi implementar uma série de padrões de projeto com uma visão bem voltada para os jogos. Não vou colocar nada aqui ainda, pois estou trabalhando em outras pequenas surpresas que podem vir a aparecer ainda em Janeiro.

O ano vai começar com artigos no ritmo do artigo sobre o Singleton e o MVC: explicação do conceito + Diagramação UML + Código + comentários. Deixa só passar o ressacão do Reveillon prá gente sacudir isso aqui.

"Boas festas"; "se forem dirigir, não bebam", "Feliz Natal" e todos os outros clichês que estão nos dizendo. Aguardem o novo ano que vamos ter coisas boas por aqui! Até lá!

P.S.: Esqueci de dizer: caso alguém queira um padrão específico, pode pedir aí. Não garanto que eu consiga trazê-lo pro blog, mas vou fazer de tudo para dissecar o menino!

Casos de Uso? Mas hein?

Tá, tá, foi vacilo meu, mas é que eu nem me toquei que o termo Casos de Uso pudesse significar interrogações pra vários de vocês. Pra resolver isso, ta aí: uma explicação sobre os Casos de Uso!

Esses tais Casos de Uso (CdUs daqui pra frente) não são nada mais que cada uma das diversas interações que o usuário vai ter com o seu programa. Na maioria das vezes, cada tela ou janela diferente significa um CdU diferente, mas como jogos são muito mais complexos, várias vezes tempos diversos CdUs na mesma janela. “Andar com o personagem”, “utilizar magia”, “selecionar alvo”, “pegar item” e “conversar” são diversos CdU que você realiza na mesma tela: a tela de jogo.

Devido à troca de endereço, a continuação desse artigo pode ser encontrada no endereço http://nusseagora.blog.br/casos-de-uso-mas-hein/

Singleton: Limitando e Distribuindo

O nosso Jogo tem uma característica muito especial: ele é traduzido dinamicamente, sem a necessidade de recompilação. Para isso, estamos colocando todo o texto em uma classe especial, a TIdioma. O problema é que, se nós estivéssemos utilizando um objeto simples, a cada “new” que déssemos, teríamos uma cópia inútil do objeto ocupando espaço inutilmente. Dessa forma, se tivéssemos 500k de texto, poderíamos estar ocupando vários megas da memória.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/singleton-limitando-e-distribuindo/

Orientação a Objetos: Q raios é isso!? (parte 3)

Voltemos ao exemplo anterior dos contêineres. Como vocês se lembram, quando eu joguei o método fechar() na classe Mãe, eu fiz com que ele fosse acessado por todas as classes filhas, por herança. “Claro, senão você não vai poder fechar nada” você diz. Concordo plenamente com essa observação, mas vamos parar pra pensar no seguinte: será que uma caixa, uma bolsa, uma garrafa e uma mala são fechadas da mesma forma?

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/orientacao-a-objetos-q-raios-e-isso-parte-3/

Orientação a Objetos: Q raios é isso!? (parte 2)

Continuando o artigo anterior, o básico da Orientação a Objetos pode ser entendido como um conjunto de classes e objetos que se relacionam. Hoje vou definir essas relações, começando pelo mais importante de tudo:

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/orientacao-a-objetos-q-raios-e-isso-parte-2/

Orientação a Objetos: Q raios é isso!? (parte 1)

Hoje eu vou falar do paradigma de programação que escolhemos para fazer o Jogo, a Orientação a Objetos. Ela começou lá pela década de 60 acompanhando uma tal Engenharia de Software, que falava, na época, sobre os problemas que os programadores teriam com a crescente complexidade dos programas.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/orientacao-a-objetos-q-raios-e-isso-parte-1/