No post Objetos não são atributos + funções o autor apresenta de uma forma bastante humorada os grandes problemas do ensino da Orientação a Objetos para pessoas que já tiveram experiência em programação procedural. Talvez esse seja um dos principais motivos que fazem com que alguns dos desenvolvedores da linguagem C odeiem a linguagem Java.

Existe também o wiki Evitando VOs e BOs onde existe uma crítica do autor ao modelo de programação OO que foi utilizado inicialmente no desenvolvimento EJB: o "Modelo de Objeto Anêmico". Apesar de todos os problemas encontrados, esse modelo de desenvolvimento Java é utilizado até hoje.

O ensino de Orientação Objetos tem muitas falhas, mas com esses textos é possível perceber se você está ou não no caminho certo.

Este artigo é para quem ainda não sabe nada de OOP (ou POO), como é o caso do colega que o motivou.

Indo direto ao ponto, vamos pegar um "objeto" conhecido e criar uma classe que o represente.

A nossa classe vai contemplar seus atributos e seu comportamento (o que o nosso objeto faz).

Nosso objeto vai ser a tia velha. Seus atributos serão o nome e idade (que faz dela tia velha), além das coisas que ela fala (coisas típicas de tia). Seu comportamento, ou ação, é falar aleatoriamente as coisas que toda tia velha fala.

Repare que o que foi dito sobre a classe "tia velha" se aplica a toda e qualquer tia velha, independente de nome, idade ( pode ter tia velha de vinte e poucos anos, acredite ) ou de quem é o sobrinho.

vamos ao código

[sourcecode language='python']
import random

# inicio da definicao da classe
class TiaVelha:
    def __init__(self, nome, idade):
        """
        inicializador da classe.
        cada tia velha criada
        serah criada por este metodo init
        """

        #definindo os atributos
        self.nome=nome
        self.idade=idade
        self.frases=[]

        #criando o repertorio de frases
        self.frases.append( "Como voce cresceu!" )
        self.frases.append( "Voce precisa arrumar uma namoraaaada!" )
        self.frases.append( "Voce ainda nao arrumou emprego?!!" )
        self.frases.append( "Respeita sua mae, menino!" )
        self.frases.append( "Gracinha!" )

    def falar(self):
        """
        metodo principal da tia velha
        """
        x=len(self.frases)
        n=int(random.random()*x-1)
        print self.frases[n]

    def apresentar_se(self):
        print   """
                Ola.
                Meu nome eh """ + self.nome + """
                e tenho """ + str(self.idade)  + """ anos.
                Sou uma tia velha e o que mais faco eh falar
                """

# o codigo abaixo somente
# sera executado se este
# arquivo for executado
# diretamente.
#
# nao o serah se a classe
# TiaVelha for importada
# para dentro de outro
# programa python
if __name__=='__main__':

    # criando uma 'nova' tia velha
    # com nome 'Odila' e idade 67
    # eh neste momento que __init__()
    # serah chamado
    odila=TiaVelha('Odila',67)

    # executando um metodo
    odila.apresentar_se()

    print
    print
    print

    # fazendo a tia odila falar 15 vezes
    for x in range(15):
        odila.falar()
[/sourcecode]

A linha 1 import random só entrou neste programa porque no método falar(self) foi preciso usar números aleatórios.

Explicar o resto acho que é redundância.

Este artigo teve a intenção de apresentar orientação a objetos a quem ainda nada sabia a respeito.

Pesquisa e treinamento são necessários para se aprofundar no assunto.

Opa, calma pessoal não é o que vocês estão pensando, deixa eu me explicar.

A maioria dos programadores de <? PHP ?> não se preocupam em separar a programacão do design , aliás não só de <? PHP ?>, muitos programadores até pela pressa de acabar um projeto não se preocupam com isso, eu fui um desses... , e quero que todos vocês conheçam o "CÉU" tambem, afinal, Deus disse:

_Amai aos outros como a si mesmo.

A programação é uma arte então cuide dela como se fosse você.

PS: É claro se você não for um suicida, :-D , brincadeirinha.

Estou colocando uma nova apostila de <? PHP ?> Orientado a Objetos, que o pessoal da UNICAMP desenvolveu, é uma ótima forma de começar a se "redimir".

Espero que todos os programadores, tenham essa consciênçia de organização. ;-) .Valeu

Abraço a todos e até a próxima.

Clique aqui para baixar a apostila

Estou finalizando este que é mais um projeto de faculdade chamado GF®  Livros® 2008, uma aplicação que automatiza livrarias.  A aplicação foi desenvolvida usando a linguagem de programação C# e arquivos xml, não consta banco de dados pois o intuito da grade semestral era apresentar a serialização de objetos em arquivos xml fazendo assim  a persistência dos dados. O projeto conta com a junção de quatro matérias que são programação orientada a objetos, algoritmos e programação 3, probabilidade e estatística e estrutura de dados. O projeto terá uma vida de construção por volta de seis meses e teria muito a melhorar  se o mesmo trabalho e empenho continuassem a serem aplicados. A data de lançamento será dia 14/06/08 sem horário definido. Mas nete dia ele será apresentado na faculdade de manhã mostrando pela primeira vez ao mundo sua cara. Ao lado segue duas imagens da aplicação. Uma é a tela de login e a outra a tela de cadastro de livros. Como os projetos da turma ainda estão em fase de construção, não irei liberar muitos detalhes (técnicos) sobre a aplicação. Não que eu não queira ajudar, prefiro ajudar a deixar meu esforço ser colado. :)  

 Neste projeto também vejo um produto que teria como ganhar muito mercado e assim render muita grana, mas antes precisaria de uma pequena injeção de capital para que continuasse a ser desenvolvido. Gosto de brincar com essas idéias de "ver um produto", até porque não subestimo os universitários, são deles e de seus trabalhos que muitas vezes surgem as grandes oportunidades e idéias existentes.

Tópicos que o sistema atende

• Interface amigável
• Acesso a WebServices
• Controle de acesso
• Controle de estoque
• Controle de vendas
• Estatísticas de acessos ao sistema, entrada e saída de produtos são adiquiridas da exportação de valores em arquivos CSV (Comma Separated Values) 
• *O usuário determina qual estrutura de dados a aplicação vai usar entre árvores AVL ou listas ligadas.

O que mais poderia ser implementado?

• Banco de dados (Para funcionar em livrarias de médio porte acima)
• Controle de outros subsistemas a ele ligado (Terminais de consulta sobre livros dentro de uma livraria)
• Design profissional
• Gráficos para mostrar um balanço dos fluxos de caixa amigavél
• Gráficos para mostrar as melhores e piores vendas
• Gráficos para mostrar tendências de maximização dos lucros (A parte que se eu consseguir fazer ficara muito legal onde o objetivo é que o sistema reconheça para onde deve ir o dinheiro investido na livraria, garantindo assim um lucro no mínimo, mínimo, só que previsto antes)
• Opções de customização para o cliente

*Obs: A estrutura de dados também foi construida, ou seja não foi usada estruturas de dados prontas como LinkedList em C#.

Então lembre-se dia 14/06/08 é o lançamento.

UltraG

A única constante real no desenvolvimento de software é a sua continua MUDANÇA. Uma das melhores maneiras de se verificar se um software foi bem projetado é medindo o grau de dificuldade de alterar ou adicionar novos requisitos.

Um software que não é bem projetado desaba nos primeiros sinais de mudança, em contra partida, um grande software pode ser facilmente alterado.

Um software altamente flexível não é criado da noite para o dia, os princípios de projetos OO devem ser aplicados à arquitetura do sistema de forma iterativa visando este objetivo. Mesmo após a arquitetura do sistema estabelecida, nunca tenha medo de aperfeiçoá-las, mesmo que isso signifique retroceder, uma vez que isto resultara em uma significativa economia a longo prazo.

AGREGAÇÃO SIMPLES E POR COMPOSIÇÃO

- Fundamento mais básico da programação OOP, sendo que um modelo de domínio OO (Domain Model) é elaborado e construído com único objetivo fazer os objetos existentes se relacionar para promover um serviço maior.

- É a forma mais simples e utilizada para relacionados dos objetos de um sistema.

- Agregação simples é quando um objeto é usado como parte de outro objeto, mas ainda sim ele existe, sobrevive e pode ser usada fora do objeto encapsulador.

- Agregação por composição é quando um objeto é criado e usado somente como parte de outro objeto maior. O objeto parte não pode sobreviver ou ser utilizada sem o objeto parte agregador.

HERANÇA COM CLASSES ABSTRATAS OU CONCRETAS

- Utilizadas para agrupar características e comportamentos concretos ou abstratos de inúmeros tipos semelhantes.

- Utilizados unicamente para agregar características e/ou comportamentos semelhantes encontrados em vários objetos diferentes com o objetivo de evitar duplicação de código na codificação dos mesmos.

- Muito conhecido como principio de projeto “Aberto-Fechado” que significa que a classe esta fechada para alteração, uma vez ela foi implementada e testada, mas que pode ser facilmente estendida por classes filhas e alteradas via métodos subscritos usando chamadas de métodos polimórficos.

- A referencia do pai deve ser capaz de apontar para o filho e executar as mesmas operações polimorficas semanticamente equivalentes (IS A), se caso isso não acontecer, o caso não é de herança.

ENCAPSUALMENTO

- Colocar em um lugar único os códigos duplicados existentes.

- Ajuda a proteger suas classes de alterações necessárias.

- Responsável pela prevenção de problemas de manutenção de qualquer outro principio OOP.

- Localiza a alterações necessárias ao comportamento de um objeto na qual ele possa variar.

- Pode ser usado como:

1. Override de métodos herdados, cada classe anula o do pai, alterando dentro do próprio objeto como lhe é devido.

2. Criando uma outra classe semanticamente correta que agrege o determinado comportamento, criando agregações em outras classes.

- Muito conhecido como principio de projeto “Dry” utilizado para ter cada informação e seus comportamentos em um lugar único e sensato lugar dentro da aplicação, fazendo com que os requisitos sejem implementados somente uma vez.

CODIFICANDO PARA INTERFACES

- Codificar para interface ao invés de implementação (classes) é utilizado quando se precise implementar algo com tarefa dupla:

1. Definir comportamento semelhante para vários tipos diferentes.

2. Ser utilizado como foco principal de outras classes que usam esses tipos (ponteiros polimórficos)

- Torna o código totalmente flexível muito mais fácil de estender.

- Funcionara com todas as subclasses da interface, até mesmo com aquelas que ainda não foram criadas.

- Sempre use preferencialmente parâmetros e agregações simples ou por composição para objetos polimórficos, sendo ponteiros para interfaces, classes abstratas ou até superclasses concretas.

DELEGAÇÃO

- È o ato de um objeto encaminhar para outro objeto a responsabilidade da implementação de uma operação que deveria ser executada pelo primeiro. O equals() é um exemplo comum de delegação......Por que outros objetos podem precisar identificar se um determinado objeto é igual ao outro, mas quem faz isso é o próprio objeto comparado e não aquele que deseja saber a resposta (que deveria ser o cara que deveria implementar isso.).

- È utilizado para implementar aplicações 'livremente unidas'.

- É outra opção comparada com a herança. Uma classe não precisa herdar de outra, ele pode simplesmente agregar objeto e delegar as funções a ele.

- Usado em casos nos quais uma classe precisa apresentar os mesmos comportamentos de uma família de classes, porém ela não pode ser herdada da classe pai pelo fato dela não pertencer à hierarquia de classes.

- Usado em casos onde uma classe necessite usar uma funcionalidade de outra classe com algumas modificações, mas que não deseje alterá-la por outras dependências. Considere uso de delegação, crie uma classe terceira, agrege objeto da classe com a funcionalidade e acrescente nesta classe a terceira o comportamento diferencial.

PROPRIEDADES DINÂMICAS

- Quando existir a necessidade de criar varias sub-classes por causa de propriedades altamente dinâmicas, pode user usado uma coleção Map para implementar este comportamento. Isso evitara alterações e refatorações no projeto quando existir a necessidade de adicionar novos tipos com novos conjuntos de propriedades.

UM MOTIVO PARA MUDAR (Coesão)

- Uma classe deve ser implementada com apenas um único objetivo – Representar a implementação de uma abstração do mundo real.

- Quando uma classe possui mais que um motivo para ser alterada é por que provavelmente ela esta fazendo mais coisas do que devida, ou seja, ela esta agregando mais de um objetivo.

- Analise bem e divida em varias classes diferentes de forma que cada classe tenha apenas um motivo para ser alterada. Isso estará minimizando as chances de que uma classe tenha mudar ao reduzir o numero de coisas de possa causar sua alteração.

- Muito conhecido como principio da responsabilidade única (SRP ou Coesão) e esta intimamente relacionado com o principio Dry.

COESÃO

- A coesão mede o grau de conectividade entre os elementos de único modulo, classe ou objeto. Quanto maior a coesão de seu software, mais bem definidas e relacionadas serão as responsabilidades de cada classe individual da aplicação. Cada classe possui um conjunto especifico de ações que devem ser executadas por ela que é única razão de sua existência.

- Uma classe coesiva faz apenas “uma coisa bem feita” e não tenta fazer ou ser alguma outra coisa ao mesmo tempo. Classes coesivas se concentram em tarefas específicas, não assumindo ou fazendo papeis de outros. Quanto mais coesivas são suas classes, mais livre será a união entre as classes.

- Sempre que existir a necessidade de alteração no software dentro do ciclo de vida, sempre caminhe no sentido de aumentar a coesão das classes do projeto.

OBSERVAÇÔES

A herança, agregação e composição são técnicas que permitem a reutilização de código. Entretanto, escolha a DELEGAÇÃO e COMPOSIÇÃO ao invés da HERANÇA que a arquitetura será bem mais flexível, fácil de manter, estender e reutilizar.

Espero ter contribuído para um mundo OO melhor.

Abraço a todos.

Python na Prática: Um curso objetivo de programação em Python

Vantagens da linguagem python

1. Simples. Python é fácil de aprender a usar.
2. Diversos frameworks web para facilitar a sua vida.
3. Reutilização de código.
4. Multiparadigma: funciona como uma linguagem estruturada, orientada a objetos ou ainda como uma linguagem funcional.
5. Documentação. Python é extensamente documentada.
6. Portabilidade. Python roda em Windows, Linux, Mac e até em celulares!
7. IDEs livres. Python pode rodar através da IDE do Netbeans, do Eclipse e muitas outras.
8. Multiplataforma. Escreva um aplicativo, gráfico inclusive, em Linux e rode-o em Windows e Mac sem alterar o código.
9. Legibilidade do código. Programadores python são fanáticos por boas práticas de programação e a linguagem também força uma escrita de seus programas de uma forma limpa, clara e elegante.
10. Diversos módulos com muita coisa pronta.

Mas virei "omi", botei as "cara" e resolvi aprender esse tal de objetos. Comecei mexendo com Java para me obrigar a programar OO. Dai passei para o PHP, foi uma maravilha, varias classes, métodos, atributos, carro liga, carro desliga, carro é do tipo automóvel e a moto também é. Mas ainda assim eu fazia muitas coisas estruturadas. Então aprendi um pouco sobre UML, opa ai o negócio ficou mais bunitinho. 'Deseinhos' antes de escrever uma linha de código, coisa fina. Meus código estruturados foram desaparencendo.

E também surgiu na minha vida os Padrões de Projetos (Designers Patterns). Também de inicio foi meio complicado de enteder que diabos era isso, na verdade eu achava que era um treco muito foda por isso não entendia. Mas é algo teóricamente simples, não tem segredos. Assim meus códigos foram evoluindos e prova disso foi exatamente hoje.

Tive que incluir um campo em uma tabela de um sistema, só que esta tabela é básicamente a principal do sistema, entao fiquei algumas horas pensando a melhor maneira de inserir esse campo, e não foi tão dificil assim, além de incluir na tabela fiz o mesmo no mapeamento, mexi em 3 métodos de classes diferentes e vuala, funcionando perfeitamente. Viva a orientação a objetos :)

Por isso vou contribuir com links interessantes sobre Orientação a Objetos:
unicamp: Bom tutorial sobre OO.
PHP Programando com Orientação a Objetos : Esse eu tenho e recomendo.
MundoOO : Tudo sobre Orientação a Objetos.

Essa semana na faculdade, vou iniciar um "curso" sobre como utilizar o PHP Orientado a Objetos para alguns alunos do curso que precisam dela para seus trabalhos de diplomação.

Resolvi procurar um livro na Biblioteca sobre PHP, e achei esse, PHP: Programando com orientação a objetos.

Olhei alguns topicos do livro, ele é simples, de linguagem simples, mas com um ótimo conteudo. Recomendo o livro para quem nunca iniciou contato com PHP, e já queira ótimas referencias sobre orientação a objetos.

Vou me basear nesse livro para ministrar esse "curso".

Até a proxima!

A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de Orientação a Objetos. Essa linguagem se tornou, nos últimos anos, a linguagem-padrão de modelagem de software adotada internacionalmente pela indústria de Engenharia de Software.

Deve ficar bem claro, no entanto, que a UML não é uma linguagem de programação, mas uma linguagem de modelagem, cujo objetivo é auxiliar os engenheiros de software a definir as características do software, tais como seus requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos e até mesmo suas necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado. Todas essas características são definidas por meio da UML antes de o software começar a ser realmente desenvolvido.

Vamos tomar como exemplo um ComboBox: Você adiciona o componente no Stage e insere os dados no mesmo (label, data, etc), certo? O componente é responsável por exibí-los. Assim, podemos dizer que você usa um ComboBox e tem acesso às propriedades necessárias para personalizá-lo ao seu modo (Talvez o combo do flash não seja o melhor exemplo de personalização, mas essa é outra história, rss). Já pensou se você precisasse programar um código para que depois de um numero x de elementos fosse inserida uma rolagem no combo? Felizmente, neste conceito (e no do flash, graças a Deus!), você não precisa. O combo é responsável pelos seus estados (lembre dessa palavra! Vamos lá, repita comigo:estado, estado, estado...), e é ele quem deve cuidar da sua rolagem independente do número de itens que possua.

Vamos supor que o nosso combo possua uma variável estática (que consequentemente tem o mesmo valor para todos os combos - ou em se tratando de OO propriamente dita, para todas as instâncias do objeto) chamada MIN_ELEMENTS, que é responsável por armazenar o número mínimo de elementos visíveis, cuja declaração seria a seguinte:

public static var MIM_ELEMENTS:Number = 1;

Então, por descuido ou qualquer outro motivo alguém resolve escrever o código:

ComboBox.MIM_ELEMENTS = -10;

A variável é publica e pode ser acessada de qualquer lugar. Mas me diga, é possível renderizar -10 itens? Você acha possível que a alteração de um atributo como este poderia afetar o funcionamento do combo? É provável que sim. Não precisamos ter acesso a atributos deste gênero para utilizar o nosso objeto combo, mas é um dado importante dentro do mesmo. Assim a declaração correta seria:

private static var MIM_ELEMENTS:Number = 1;

Agora esse atributo só é visível dentro da classe e só pode ser alterado internamente.

Vamos a outro exemplo. Temos uma classe Pessoa e um de seus atributos é sexo e seu conteúdo pode ser feminino ou masculino.

class Pessoa{
	public var sexo:String;
	// continua o codigo
	//  ...
}

var p:Pessoa = new Pessoa();
p.sexo = "Maria";
 

A variável sexo é pública e do tipo String portanto poderia aceitar tranquilamente a String "Maria", entretanto, isso pode - e provavelmente irá - comprometer o funcionamento do nosso objeto, tendo em vista que o sexo "Maria" definitivamente não existe. Assim, utilizamos recursos de encapsulamento de OO para proteger o nosso objeto. Os getters e os setters.

class Pessoa{
	private var _sexo: String;

	public function get sexo():String{
		return _sexo;
	}

	public function ser sexo(sexo:String){
		sexo = sexo.toLowerCase();
		if (sexo == "feminino" or sexo="masculino")
			_sexo = sexo;

		// caso nao fosse atribuido poderia ser disparado um evento,
		// ser gerada uma excessao,
		// exibir uma mensagem de erro e por ai vai.

	}

}
 

No exemplo acima, garantimos que será inserido apenas um dado válido. E o getter? Bom, se você restringe o acesso a um dado e ele precise ser visto fora do objeto, é necessário disponibilizá-lo (se e somente se ele realmente precisa ser visto de fora). Mas não confunda! O getter pode conter outras coisas além do retorno do atributo.

Geralmente quando se começa a aprender POO (seja para criar o hábito, começar a identificar necessidades, ou qualquer outra coisa que se possa querer com isso) se indica utilizar atributos privados para tudo (ou quase) e a criação de getters/setters de todos eles. Isso porque quando se vem de uma linguagem procedural se pode fazer tudo com todos os atributos, não existe encapsulamento e literalmente "todo mundo é de todo mundo". Então tenta-se a criar (ou modificar) uma cultura. Se isso é certo ou não... é um jeito (e a maioria dos programadores em algum momento passam por essa fase, depois passamos a fase de nos livrar do hábito do excesso).

A identificação das necessidade da utilização desses metodozinhos vem com a experiência em POO. É preciso saber identificar quando o usuário pode inserir um dado diretamente, quando ele pode ver um dado, quando ele pode inserir algum dado mas com restrições, quando você precisa saber se um dado é inserido, etc... Uma forma de saber isso antes de colocar a mão na massa é a modelagem. O código abaixo por exemplo é uma maneira mais burocrática de "gerar uma variável pública".



private var _sexo: String; 

public function get sexo():String{
	return _sexo;
}

public function set sexo(sexo:String){
	_sexo = sexo;
}

Então... Vamos modelar, modelar e modelar? Ok! Você "não tem tempo pra isso" ou "não gosta de fazer isso" ou qualquer outro "ou". Neste caso, eu simplesmente aconselho que comece com todas os atributos privados e vá filtrando conforme desenvolve a classe (dentre os males, penso que este é o menor), mas acredite: modelar é mais rápido.

A idea básica é voce definir a execução do jogo em X ticks por segundo - assim garantindo que o jogo roda na mesma velocidade em todas as máquinas, e deixando a velocidade independente do FPS (frames per second - frames por segundo). A lógica é simples - voce tem uma variável que define quantos milisegundos cada tick tem para executar, e só executa o próximo tick após esse tempo mínimo ter passado:

[sourcecode language='cpp']

// alguns typesdefs - padrao q geralmente gosto de usar
typedef unsigned int dword;
typedef unsigned char byte;

// definicao de uma lista de objetos
typedef vector VetorDeObjetos;

// variável q vai guardar o tempo dos ticks - em milisegundos
//     neste caso, 34milisegundos significa 30 updates por segundo
dword msTick = 34;
// variável q guarda o tempo do update anterior
dword msLastUpdate = 0;

// funcao de execução chamada dentro do loop de jogo
void rodaTick()
{
   // estou usando SDL para facilitar o exemplo
   //    esta funcao do SDL retorna o numero de milisegundos
   //    desde o inicio do programa
   dword msTempo = SDL_GetTicks();

   // devo executar o tick?
   if ( msTempo >= (msLastUpdate + msTick) )
   {
      // seta o valor de ultima atualizaçao
      msLastUpdate = msTempo;

      // chama funcao update() de todos os objetos do jogo
      for ( VetorDeObjetos::iterator it = objetos.begin(); it != objetos.end(); it++ )
         it->update(msTempo);
   }
   // agora manda desenhar todos os objetos
   for ( VetorDeObjetos::iterator it = objetos.begin(); it != objetos.end(); it++ )
      it->draw();
}

[/sourcecode]

Como disse, bem simples. O update eh feito periodicamente baseado no valor de msTick, mas o draw() é chamado todas as vezes. Assim voce garante o maior FPS possivel, mas a velocidade de execução do jogo se mantem igual,

Mas e se a máquina por acaso engasga por algum tempo (mesmo q minusculo)? Como garantir que a lógica do jogo nao fique defasada?
Podemos colocar uma verificação extra para que, em vez de executar cada tick se o tempo passou do estimado, ele executar todos os ticks até que o tempo de execução esteja correto em relação ao tempo de aplicação. Vamos alterar nossa funcao um pouco para criar esse efeito:

[sourcecode language='cpp']

void rodaTick()
{
   // estou usando SDL para facilitar o exemplo
   //    esta funcao do SDL retorna o numero de milisegundos
   //    desde o inicio do programa
   dword msTempo = SDL_GetTicks();

   // devo executar o tick?
   while ( msTempo >= (msLastUpdate + msTick) )
   {
      // seta o valor de ultima atualizaçao
      msLastUpdate += msTick;

      // chama funcao update() de todos os objetos do jogo
      for ( VetorDeObjetos::iterator it = objetos.begin(); it != objetos.end(); it++ )
         it->update(msTempo);
   }
   // agora manda desenhar todos os objetos
   for ( VetorDeObjetos::iterator it = objetos.begin(); it != objetos.end(); it++ )
      it->draw();
}

[/sourcecode]

Com o while, todos os ticks serão executados corretamente até se atingir o tempo atual de execução, mesmo que a máquina engasgue por alguns ticks.

Mas podemos melhorar ainda mais este sistema. Imagine por um instante que temos na nossa engine vários sistemas - tais como IA, física, etc. Podemos querer atualizar a IA com metade da frequencia de que atualizamos o movimento e física. Para isso, vamos implementar o suporte a multiplos ticks, mas antes vamos olhar um esqueleto da classe objeto:

[sourcecode language='cpp']

class Objeto
{
protected:
   dword _tickMascara;

   // outros membros protected e private

public:
   // construtores/destrutores

   // outros métodos

   // métodos de tick
   inline bool verificaTick(const dword tick)
   {
      return ( _tickMascara & tick );
   }

   // métodos de update e desenho
   virtual void update(const dword tick, const dword msTempo) = 0;
   virtual void draw() = 0;
};

[/sourcecode]

A nossa classe Objeto tem um membro protegido, _tickMascara, que define uma mascara 32bits - essa máscara iremos usar para definir se este objeto responde, ou não, ao nosso tick. Deste jeito, podemos ter até 32 ticks diferentes, cada um correspondendo a 1 bit da mascara. O método verificaTick é usado para verificar se o tick definido no parametro é aceito pelo objeto. Mudei também o método update para que receba o tick que estamos atualizando, evitando assim a necessidade de chamar dois métodos diferentes sempre que precisamos atualizar.

Vamos agora olhar a definição da nossa variável que controla o tempo do tick:

[sourcecode language='cpp']

// máximo de ticks suportados
#define MAX_TICKS 32

// definimos para q serve cada tick - define o indice e a máscara de cada tick
#define TICK_IA_INDICE        0
#define TICK_IA_MASK        0x001;
#define TICK_MOV_INDICE     1
#define TICK_MOV_MASK         0x002;

// como precisamos manter até 32 ticks, o formato é diferente
struct tickInfo_t
{
   dword numTicks;
   dword msLastUpdate[MAX_TICKS];
   dword msTick[MAX_TICKS];
} tickInfo;

// vamos usar esta funcao para inicializar os ticks
void tickInit()
{
   // estamos usando 2 ticks neste exemplo
   tickInfo.numTicks = 2;

   // IA atualiza 15 vezes por segundo
   tickInfo.msTick[TICK_IA_INDICE] = 67;
   // moviemento 30 vezes por segundo
   tickInfo.msTick[TICK_MOV_INDICE] = 34;

   // zerar os contadores de tempo de cada tick
   for ( int i = 0; i < tickInfo.numTicks; i++ )
      tickInfo.msLastUpdate[i] = 0;
}

// e agora, nossa funcao rodaTick()
void rodaTick()
{
   // estou usando SDL para facilitar o exemplo
   //    esta funcao do SDL retorna o numero de milisegundos
   //    desde o inicio do programa
   dword msTempo = SDL_GetTicks();

   // temos q passar por todos os ticks agora
   dword tickAtual = 1;
   for ( int i = 0; i < tickInfo.numTicks; i++ )
   {
      // devo executar o tick?
      while ( msTempo >= (tickInfo.msLastUpdate[i] + tickInfo.msTick[i]) )
      {
         // seta o valor de ultima atualizaçao
         tickInfo.msLastUpdate[i] += tickInfo.msTick[i];

         // chama funcao update() de todos os objetos do jogo
         // repare que agora estamos passando a mascara do tick juntamente com o tempo
         for ( VetorDeObjetos::iterator it = objetos.begin(); it != objetos.end(); it++ )
            it->update(tickAtual, msTempo);
      }
      // passamos para o próximo tick usando shift
      //     para quem nao conhece, este operador vai fazer com q todos os bits
      //     andem 1 casa para a esquerda
      tickAtual <<= 1;
   }
   // agora manda desenhar todos os objetos
   for ( VetorDeObjetos::iterator it = objetos.begin(); it != objetos.end(); it++ )
      it->draw();
}

[/sourcecode]

Agora temos diversos ticks funcionando em tempos diferentes. Vamos olhar um exemplo de um objeto que responde a esses dois ticks que definimos:

[sourcecode language='cpp']

class Pessoa : Objeto
{
private:
   // membros privados

public:
   // no construtor definimos os ticks aceites por este objeto
   Pessoa() : _tickMascara( TICK_IA_MASK | TICK_MOV_MASK ) {}
   virtual ~Pessoa() {}

   // metodo update
   virtual void update(const dword tick, const dword msTempo)
   {
      // vamos atualizar
      if ( tick & TICK_IA_MASK )
         updateIA(msTempo);
      if ( tick & TICK_MOV_MASK )
         updateMovimento(msTempo);
   }

   // os metodos de atualizaçao de ia e movimento
   void updateIA ( const dword msTempo ) {}
   void updateMovimento ( const dword msTempo ) {}

   // metodo draw...
};

[/sourcecode]

Ao definir _tickMascara com os 2 tipos de tick, o metodo update será chamada a cada update dos ticks IA e MOV. Se removermos um dos ticks da definição no construtor, o metodo irá fazer nada com esse tick. Podemos melhorar consideravelmente a performance deste sistema verificando se o objeto responde ao tick especificado verificando o método verificaTick() anteriormente a chamar o método update().

Este código necessita no entanto que voce tenha na sua engine de jogo alguns requesitos necessários:

- Um passo de inicialização, onde voce pode inicializar os ticks;
- Um repositório central com todos os objetos do jogo - em formato lista, arvore, etc;

Quaisquer dúvidas ou sujestões são sempre benvindas - espero ter sido util com este artigo. Abraços e até mais!

O que é programar Orientado a Objetos?

Programar Orientado a Objetos é pensar em como criar seu código como você pensa na vida real. É você abstrair os objetos da vida real e leva-los para as linhas de código como eles são - com suas características, que são os atributos e suas ações, que são os métodos. Todo objeto tem características e ações.

A POO foi criada com o intuito de resolver os problemas da programação estruturada. A idéia era resolver problemas o mais rápido possivel e com a segurança que funcionaria em qualquer lugar a mesma solução. A grande vantagem disso é o reaproveitamento de código, isso traz uma redução no tempo que uma solução pode ser gerada. Tempo em programação pode ser muito caro, por isso a POO é tão bem aceita!

O que é um Objeto?

Um objeto é um elemento computacional que representa, no domínio da solução, alguma entidade (abstrata ou concreta) de interesse do sistema sob análise. Objetos similares são agrupados em classes. No paradigma da orientação a objetos, tudo pode ser potencialmente representado como um objeto. Sob o ponto de vista da programação, um objeto não é muito diferente de uma variável no paradigma de programação convencional.

Quando se define uma variável em Java, essa variável terá:

• Um espaço em memória para registrar o seu estado atual (um valor)

• Um conjunto de operações associadas que podem ser aplicadas a ela, através dos operadores definidos na linguagem que podem ser aplicados a valores inteiros (soma, subtração, inversão de sinal, multiplicação, divisão inteira, resto da divisão inteira, incremento, decremento).

Da mesma forma, quando se cria um objeto, esse objeto adiquire um espaço em memória para armazenar seu estado (os valores de seu conjunto de atributos, definidos pela classe) e um conjunto de operações que podem ser aplicadas ao objeto (o conjunto de métodos definidos pela classe).

Portanto um programa orientado a objetos é composto por um conjunto de objetos que interagem através de "trocas de mensagens" entre eles. Na prática, essa troca de mensagem traduz-se na chamada de métodos (funções) entre objetos.

Exemplo de um objeto:

Um Jaguar é um objeto. Ele tem como características a cor, peso, quantidade de portas, modelo, ano, etc. Também tem ações como frear, buzinar, acelerar, abrir os vidros, trocar de marchas, etc. Portanto programar Orientado a Objetos é você fazer essa abstração do mundo real e transforma-la em código. Mais adiante mostrarei um exemplo de código Orientado a Objetos.

A POO tem quatro pilares que a sustenta, seguindo:

Abstração:

É a capacidade de você pensar nos objetos da vida real e classifica-los. É o processo pelo qual modelamos sistemas reais ou imaginários, extraindo do seu contexto os seus principais elementos "Objetos", e descrevemos cada objeto, com suas principais "características" de dados e funcionalidades.

Uma Ferrari por exemplo tem as mesmas características do objeto Jaguar citado acima, possui até mais, mas eles tem algo em comum, ou seja, ambos são carros, logo pertencem a classe carro. A Ferrari é um tipo de carro e o Jaguar também, mas cada um com suas características e ações particulares e comuns.

Programar Orientado a Objetos é fácil, o difícil é programar Orientado a Objetos bem. Pois se programando bem, você pode tirar proveito de todas as vantagens que a POO possui e para se programar bem Orientado a Objetos a principal característica que o programador deve ter é uma boa abstração do mundo real.

Encapsulamento:

Os objetos como dito acima contém atributos e métodos. O encapsulamento trata de dar alguma segurança aos objetos. Explico:

Um objeto Cliente por exemplo tem atributos como qualquer outro e estes não podem ser acessados por qualquer outro objeto diretamente. Existem dois tipos de atributos, os privados e os publicos. Em UML e OO (orientação a objetos) é definido que para atributos privados usa-se o sinal de "-" antes do nome e para atributos publicos usa-se o sinal de "+" antes do nome.

Exemplo:

Para que o encapsulamento exista é preciso deixar os atributos privados e os métodos públicos, assim está sendo garantido que os valores atribuídos aos atributos serão sempre respeitados pelas regras existentes.

Exemplo:

O atributo cpf deve sempre ter 11 números, se o atributo não for privado, ele perde essa regra (11 números) pois alguém poderia acessar e colocar 12 ou 9 números tornando-o inválido.

Como os atributos privados não podem ser acessados diretamente por outros objetos, existem os métodos publicos que são os responsáveis em acessar os atributos e trazer ou levar algum dado para o objeto respeitando as regras.

Idéia de encapsulamento:

Herança:

O que torna a orientação a objetos única é o conceito de herança que no inglês significa inheritence.

Herança é um mecanismo que permite que características comuns a diversas classes com comportamentos comuns ou parecidos, sejam abstraídas e centralizadas em uma classe base, ou superclasse. Tem uma relação "É um".

Exemplo:

Um Jaguar "é um" carro. Logo ele foi herdado da classe carro, pois contém as características comuns de um carro.

A partir dessa superclasse outras classes podem ser especificadas. Portanto uma subclasse que é uma classe herdada da superclasse recebe sem codificação extra as características da superclasse. Ainda podemos adicionar elementos particulares a está subclasse.

Na linguagem Java uma subclasse somente pode herdar uma única superclasse diretamente.

Exemplo:

Polimorfismo:

Analisando a palavra Polimorfismo, ela significa muitas formas. Ou seja, para uma árvore de herança, temos muitas formas de objetos e métodos a partir de uma superclasse e suas subclasses. Polimorfismo é o princípio pelo qual usamos objetos construídos a partir de uma árvore de herança, através de referências do tipo de uma superclasse da hierarquia.

Formas de polimorfismo:

• Subclasses;
• Sobrescrita de método;
• Sobrecarga de método ou construtor

Sobrescrita de métodos - Overriding

Esta utilidade nos permite escrever numa subclasse um ou mais métodos presentes numa das superclasses podendo alterar o comportamento da superclasse.

Exemplo:

Quando numa subclasse reescrevemos um método já existente numa superclasse, chamamos de sobreescrita de método ou reescrita de método mas o termo técnico é Method Overriding. Lembrando que a sobrescretica de métodos só é valida quando o método reescrevido na subclasse tem exatamente a mesma identificação (nome, tipos, etc.) do método da superclasse.

Sobrecarga de métodos - Overloading

O Polimorfismo ainda permite que numa mesma classe tenhamos métodos com o mesmo nome, desde que o número ou tipos de parâmetros passados sejam diferentes.

Exemplo:

A sobrecarga de métodos é uma ferramenta poderosa, pois nos permite criar vários métodos com o mesmo nome, isso facilita o entendimento de problemas mais complexos, pois não é necessária a criação de nomes de funcionalidades sem sentido aparente.

Classes

Entendido todos os conceitos acima fica fácil entender o que é uma classe. Como na vida real existem diversos objetos do mesmo tipo, nos softwares também é assim. Imagine o sistema de gerenciamento de veículos do Detran. Quantos objetos do tipo carro este sistema deve manipular por dia? Se fosse feita uma descrição para cada um, o sistema jamais iria funcionar.

Assim, podemos descrever um mesmo tipo de objetos uma única vez e cada vez que um novo objeto precise ser criado, é só utilizar a mesma fôrma. Esta fôrma é chamada classe.

Pense em uma padaria, quando você vai escolher bolos se depara com muitos bolos idênticos. Ai você se pergunta, seria o padeiro capaz de produzir tantos bolos com a mesma forma apenas usando as mãos?NÃO! Ele usou uma fôrma para fazer estes bolos, a fôrma foi o molde que ele queria para seus bolos. Com os objetos não é diferente, as classes são os moldes (modelos, fôrmas, plantas) para criação dos os objetos em tempo de execução dos programas.

Ainda tem mais, uma classe é a descrição de um conjunto de objetos que possuem os mesmos atributos, operação e semântica. Dizemos que um objeto é uma instância de uma classe, quando ele é criado a partir dela, seguindo sua especificação.

Ainda existe a diferença entre abstração e instância

A abstração denota a essência ideal de uma coisa; a instância denota uma manifestação concreta.

Poderíamos também dizer que, na codificação existem somente as classes, não os objetos. Já em tempo de execução, o que existe são os objetos e não as classes. Também dizemos que uma variável é de um determinado tipo (inteiro, booleano, real, etc.) numa linguagem de programação, então dizemos que um objeto é de uma determinada classe.

Uma classe é a reunião de objetos idênticos por meio de atributos e métodos.

Neste post existe muitas possibilidades de assuntos mais profundos, mas eu tentei focar somente em OO.

Vou ficando por aqui e até o próximo post sobre Probabilidade e Estatística.

UltraG

var a:String = new String("string");
var b:String = new String("string");
var c:String = "string";
var d:String = "string";
Então:

1) a == b ?

2) a === b?

3) c == a?

4) c === a?

5) c == d?

6) c === d?

Respostas (publicado em 03/02/08):

Começando pela diferença entre os operadores de igualdade.

O operador de igualdade estrita (===) é como o operador de igualdade, com uma diferença importante: o operador de igualdade estrita não executa a conversão de tipo. Se os dois operandos forem de tipos diferentes, o operador de igualdade estrita retornará false (MACROMEDIA, Guia de Referência do ActionScript Flash MX 2004, pag. 44).

A variável a, assim como a variável b são objetos do tipo String. Ao serem comparadas com operador estrito ou não, sempre retornarão false.

1) a == b // false
2) a === b // false

Isso porque a e b são objetos diferentes. Mesmo sendo instâncias da mesma classe e contendo atributos iguais, eles possuem identidade diferentes, são armazenados em lugares diferentes da memória, assim as variáveis a e b são referências a objetos String e contém o endereço de memória de cada um dos objetos criados. Dessa forma podemos concluir que, quando comparamos a e b, sempre será false, pois em seu conteúdo não constam valores literais, mas distintos endereços de memória.

Então, como comparar os seus conteúdos?

a.valueOf() === b.valueOf() ou a.valueOf() == b.valueOf()

Mais uma consulta ao help do flash e temos, valueOf - Método; retorna o valor primitivo do objeto especificado. Se o objeto não tiver um valor primitivo, o objeto é retornado.

Já as variáveis c e d são tipos primitivos e possuem em seu conteúdo um valor literal que lhes foi atribuído. Veja mais um trecho do Guia de Referência AS:

Os tipos de dados descrevem que tipos de informações um elemento do ActionScript ou variável pode conter. Existem dois tipos de dados internos no Flash: primitivo e referência. Os dados do tipo primitivo — String, Number e Boolean — têm um valor constante e, portanto, podem manter o valor real do elemento que representam. Os de referência— MovieClip e Object — têm valores que podem ser alterados e, portanto, contêm referências ao valor real do elemento.

Assim, considerando que c e d armazenam um conteúdo e não uma referência a uma posição de memória, podemos afirmar que:

5) c == d // true
6) c === d //true

Com base em tudo isso, podemos concluir também que:

4) c === a // false

Considerando que estamos comparando uma referência de memória com um tipo primitivo.

Já no caso:

3) c== a // true

É verdadeiro porque o operador de igualdade (==) analisa conteúdos e faz a conversão de tipo. Como o conteúdo é idêntico, o resultado é verdadeiro, independente de serem valores literais, variáveis ou referências. Então você me pergunta, porque a== b não é verdadeiro então? E a resposta é... Como o operador de igualdade considera que c == a e String(a) == b são verdadeiros?

Manipulando objetos

Quando declara-se uma variável cujo tipo é o nome de uma classe, como em:

var nome:String;

não está se criando um objeto dessa classe, mas simplesmente uma referência para um objeto da classe String, a qual inicialmente não faz referência a nenhum objeto válido:

Quando um objeto dessa classe é criado, obtém-se uma referência válida, que é armazenada na variável. Por exemplo:

   Nome = new String(“Nova instância”);

Nome é uma variável que armazena uma referência para um objeto específico da classe String, cujo conteúdo é "Nova instância":

A variável nome mantém apenas a referência para o objeto e não o objeto em si. Assim, uma atribuição como

   var Nome2:String = Nome;

não cria outro objeto, mas simplesmente uma outra referência para o mesmo objeto

Referência:
http://www.dca.fee.unicamp.br/cursos/PooJava/objetos/manipul.html
O link acima está com explicações e exemplo de codigos para Java.

Como falei no post anterior, um ponteiro para um método de uma classe tem uma sintaxe estranha e que pode facilmente complicar códigos, e além disso necessitamos de uma referência ao objeto do qual esse método será executado. Para facilita então o uso desses ponteiros especiais, vamos criar um conjunto simples de classes que encapsulam a funcionalidade de um ponteiro para método - esse conceito é chamado de Functor.

Para que a classe seja genérica, necessitaremos utilizar templates. Mas, como um template na prática gera uma classe diferente para cada tipo, necessitamos criar uma classe-base para que nossos functors possam ser tratados por código genérico. E aqui está o código da classe:

[sourcecode language='cpp']

class Functor
{
public:
    virtual void operator() () = 0;
};

[/sourcecode]

É uma classe abstrata bem simples - com apenas um operador virtual, o operador (). Isso nos permite fazer algo do tipo:

[sourcecode language='cpp']

void funcao(Functor &func)
{
    // chama funcao encapsulada pelo functor
    func();
}

[/sourcecode]

É logico q a classe Functor apenas nao resolve nada, então vamos olhar agora o código da classe que realmente faz a diferença - TemplateFunctor

[sourcecode language='cpp']

template
class TemplateFunctor : public Functor
{
protected:
    // definindo o tipo do ponteiro
    typedef void (T::*metodo)();
    // o ponteiro para o objeto em questao
    T *_pObj;
    // o ponteiro para o método
    metodo _fpMetodo;
public:
    // construtor
    TemplateFunctor ( T *o, metodo m ) : _pObj(o),_fpMetodo(m) {}

    // operador de chamada de funcao ()
    void operator() ()
    {
        (_pObj->*_fpMetodo) ();
    }
};

[/sourcecode]

Agora sim, temos um functor funcionando. A classe é relativamente simples - temos a definição do tipo do ponteiro, a definição dos ponteiros para o objeto e para o método, um construtor que garante a construção apropriada do functor, e o operador () q nos permite chamar o método através deste functor como se o objeto fosse o próprio método. Vamos exemplificar a seguir:

[sourcecode language='cpp']

// uma classe qualquer
class A
{
public:
    A() {}

    void metodoQualquer() { /*faz algo*/ }
};

// nao podemos ter um functor sem um objeto
A a();
// criando o functor - passando objeto e método
TemplateFunctor aFunc(&a, &A::metodoQualquer);
// chamando o método através do functor
aFunc();

Sei que falei que iria falar da classe BaseGame da engine, mas decidi passar pra algo mais pratico. Várias pessoas nas ultimas semanas vieram conversar comigo sobre gerenciamento de telas em engines de jogos. Aqui na Tecnodata, desenvolvemos uma solução bem elegante e de conceito simples - uma pilha.

A engine tem, internamente, uma pilha controlada por um gerenciador de telas. Esse gerenciador contem os metodos de push() e pop(), assim como metodos para acessar a tela no topo da pilha ( topScreen() ), e delegar as chamadas dos metodos Update() e Draw() à tela mais visivel. Para que isso seja viável, uma tela é um conceito encapsulado em uma classe Tela. Vamos ver um exemplo de código de como isso poderia funcionar em C++. O esqueleto da classe Tela:
[sourcecode language='cpp']

class Tela
{
public:
virtual void update(dword msTime) = 0;
virtual void draw(dword msTime) = 0;
};

[/sourcecode]
A classe Tela é bem simples, basicamente apenas declarando uma interface minima que todas as telas devem ter para que possam ser gerenciadas. (nota: o tipo de dados dword é simplesmente um valor 32bits sem sinal - ou seja - um unsigned int numa maquina 32bits).Agora vamos ver o esqueleto do gerenciador:
[sourcecode language='cpp']

class GerenciadorTelas
{
private:
stack _pilha;

public:
// construtor/destrutor omitidos

void push(Tela *tela);
Tela* pop();
Tela* telaAtual();

void update(dword msTime);
void draw(dword msTime);
};

[/sourcecode]
Como eu tinha dito, o gerenciador internamente trabalha com uma pilha de telas. Para adicionar uma nova tela visivel no jogo, basta criar o objeto dessa tela (ie. Tela *t = new TelaQualquer() ) e adicionar na pilha. Desse jeito, no proximo frame da engine, a tela irá trocar automaticamente da tela anterior para a nova, pois estará chamando update e draw na nova tela.

O interessante é que, como estamos falando de pilha, a tela anterior ainda existe, entao voltar para a tela anterior é tao simples quanto dar um pop() no gerenciador. Isso garante que voce possa ter uma hierarquia de telas no seu jogo faceis de gerenciar e navegar.O exemplo mostrado aqui é extremamente simples, apenas para demonstrar a idea básica. Porém, no nosso sistema, telas incluem máquina de estados, serialização e transparência (caso uma tela tenha uma transparência inferior a 1.0, a tela abaixo dela na pilha também é visivel e, portanto, também recebe chamadas a update() e draw() ).

O gerenciador de telas não apenas gerencia a pilha, como também tem opções específicas para transição entre-telas (não apenas troca), acesso a telas por índice e por tipo (não apenas ao topo da pilha), e tem todos seus métodos como virtuais, possibilitando sua extensão fácil caso necessário.
Leitura extra

Um artigo bem interessante sobre organização de telas em classes pode ser lido neste post do blog Ponto V. Nao deixem de visitar.

Uma excelente opção para quem está desenvolvendo um sistema de pequeno porte e utilizando orientação à objetos. O DB4O faz a persistência baseando-se em suas classes objeto, dispensando todo e qualquer mapeamento necessário como quando utilizamos banco de dados relacionais, e com apenas uma linha de código salva os dados desejados em banco.

Exemplo:

public void store(Car car){
ObjectContainer db =
Db4o.openFile("car.yap");
db.set(car);
db.commit();
db.close();
}

Como podem ver neste trecho de código, a sua utilização é bem simples precisando apenas passar ao método, a classe que será salva e o arquivo do banco onde os dados serão persistidos. Todo o resto é feito pelo banco de dados.

Disponível tanto para Java quanto para .Net, este banco de dados diz rodar até 55 vezes mais rápido do que sistemas convencionais, o que é bem significante considerando-se que o que todo desenvolvedor busca na maioria de suas aplicações além da qualidade é a velocidade de resposta.

Para visualizar os dados persistidos no banco é utilzada uma ferramenta chamada Object Manager, também muito simples de se utilizar.

Para se aprofundar mais sobre a tecnologia utilizada por este software, ou mesmo fazer o download do jar/dll, visite o site do DB4O.

Eu recomendo e já encomendei o meu. :)

Um vídeo de 35 minutos com Robert C. Martin e Chad Fowler no JAOO 2007.

Aqui está disponível uma pequena entrevista com 11 minutos, onde ele fala que atualmente ainda existe *muita* coisa horrível sendo produzida, códigos que não deveriam ser escritos. São práticas que são conhecidas a muito tempo como sendo práticas ruins e mesmo assim continuam sendo utilizadas.

Depois ele fala sua opinião sobre desenvolvimento de software ser um engenharia, segue falando sobre TDD, um pouco sobre como Java, .NET e Ruby e como os códigos desenvolvidos nessas linguagens são/podem ser mais fluentes/expressivos... e por aí vai, é uma entrevista curta mas com bastante conteúdo :)

Tentarei trazer dicas de orientação a objeto e boas práticas de programação, utilizando exemplos simples para o fácil entendimento. No momento estou bem ocupado, então posso demorar para postar coisas novas! ;)

Então...

Notem este código:
public class Motor {

}

public class Carro {
private Motor motor = new Motor();

     //construtora
public Carro(Motor motor) {
this.motor = motor;
}
}

Um exemplo muito simples, com dois objeto (Carro e Motor);

Agora, notem...
- A contrutora da classe "Carro", informa (obriga) que um "Carro" tenha um "Motor".
- Então antes de instanciar um carro, eu preciso instanciar um motor (motor pode ser "null", nulo).
- Quando eu contruir um carro, eu incluo o motor no carro, mas notem a linha 2:
private Motor motor = new Motor();
- Se a construtora de "Carro" me obriga ter um "Motor", por que diabo ela já tem um motor construído?

É mais ou menos como: "Vou contruir um carro 2.0, mas o carro já possuí um motor 1.0, então terei que tirar o motor 1.0, e substituir pelo 2.0"
(No mundo real isso é bom, já que eu teria um motor sobrando, mas ... na programação há disperdício de processamento e memória para criar o motor 1.0, já que foi contruído e não foi utilizado)

- Agora você deve se perguntar, grande coisa... Não vai fazer muita diferença.
- Para um exemplo simples como esse sim, mas imagine um sistema complexo, com classe gigantes e complexas

Agora olhem a classe abaixo:

public class Carro {
private Motor motor = null;

    //construtora
public Carro(Motor motor) {
this.motor = motor;
}
}

No carro eu "declarei" mas não "instanciei" o Motor.
É mais ou menos como: "tenho um carro, agora só falta o motor (reservei espaço para o Motor)"

Uma outra Boa Prática de Programação (BPP) é, sempre informar o valor da variável ao declará-la.
Como no exemplo abaixo

Exemplo de utilização:

Motor motor_1; //não recomendado
Motor motor_2 = null; //OK
Motor motor_3 = new Motor(); //OK

motor_1 = new Motor();
motor_2 = new Motor();

Carro corsa = new Carro(motor_1);
Carro corsa_sedan = new Carro(motor_2);

Até a próxima ;)