DEV Community

Gustavo Inocencio
Gustavo Inocencio

Posted on

Pontos sobre orientação a objeto em Delphi

Abaixo segue alguns pontos úteis em relação ao Delphi.
Mas como o Delphi, derivado do Pascal é uma boa linguagem para aprender o básico de OOP, os pontos podem ser transportados para outras linguagens:

  • Interface é o segredo para alta coesão;

  • Em Delphi, o assigned só enxerga o ponteiro. Por isso quando ocorre Free ele acha que ainda existe o objeto instanciado. Pois o Free só apaga o objeto, mas não o Ponteiro. Nil por sua vez só apaga o ponteiro, mas o objeto permanece, ai tem leak de memória. Usar FreeAndNil.

  • Sobrecarga (overload): os métodos de uma mesma classe devem ter assinaturas diferentes. (Números diferentes de parâmetros ou parâmetros de tipos diferentes)

  • Para fazer sobreescrita, deve utilizar palavra reservada virtual no método da classe pai e palavra reservada override nas filhas. Se alguma não tiver override é executada a sua rotina.

  • Métodos no delphi por padrão são estáticos

  • Caso não seja definido o escopo de visibilidade é publica por padrão

  • RTTI lê qualquer escopo de visibilidade a partir do delphi 2010. Antes era apenas escopo PUBLISHED

  • Classes amigas são duas classes declaradas na mesma unit e que conseguem acessar as propriedades e métodos privados e protegidos uma da outra.

  • strict private:
    só a própria classe acessa seus métodos e propriedades. Nem a classe amiga consegue acessar

  • strict protected:
    só a própria classe ou sua herdada acessa seus métodos e propriedades. Nem a classe amiga consegue acessar

  • Encapsulamento: a mágica está no que o seu objeto pode ver. Quanto menos melhor, porque o objetivo é baixo acoplamento. Porque caso seja necessário mudança será menos dolorosa. Proteger o que varia. Fugir do Ctrl+C e Ctrl+V. Se vai copiar, encapsula e usa nos vários lugares

  • Associação é um canal de comunicação entre os objetos. 
    A herança é um tipo de associação vertical
    Existe a possibilidade da associação horizontal

4 tipos de associação:

  • Simples
  • Agregação
  • Composição
  • Herança

  • Associação simples é um objeto fazendo uso do outro, mas não necessariamente para criar uma estrutura maior.

  • Agregação e composição fazem uma relação todo-parte. 

  • Na agregação a parte é um objeto independente. Pode viver fora do todo.

  • Na composição a parte é um objeto dependente do todo. Não pode viver fora do todo. 
     

  • No diagrama, o diamante (vazado na agregação e cheio na composição) fica no lado do todo

Ex: Todo-> reunião
    Parte -> sala
(Agregação)
             
pauta = Composição

  • Composição: no construtor do todo vc constrói as partes. No destrutor vc destrói todas as partes. (Property)

  • Agregação: nem sempre é necessário criar as partes. Normalmente o objeto já vem pronto. (Listas de objeto)

  • Construtor de TObject é estático. Nunca sobreescreva (override)

  • Destrutor de Tobject é dinâmico. Sempre sobreescreva (override)

  • Coesão: uma classe, uma responsabilidade
    Buscar a eficácia e não apenas a eficiência. Não adianta ser bonito se não traz o resultado 

  • Formulário é uma classe e só serve pra apresentação

  • Camada de apresentação não deve ter regras de negócio

  • Acoplamento é a dependência entre as classes
    Baixo acoplamento significa não ter um problema, um efeito colateral quando é realizada uma mudança

Arquitetura baseada em abstração:

  • Coesão: Camadas claramente definidas;
  • Interfaces formais e explicitas entre as camadas
  • Detalhes ocultos e protegidos dentro de cada camada. (Encapsulamento)

  • Interface: Declara o quê (cabeçalho)
    define o que vai ser feito

Declaração com regras do que vai ser feito

Contrato de uma grande obra

Não tem field em interface, tem que declarar get e set quando declara uma propriedade

Interface que não herda de ninguém está herdando de IInterface

Interface não tem escopo de visibilidade
Todos os métodos e propriedades são públicos

Toda interface tem que ser assinada com um GUID

Classe concreta define o como vai ser feito

Padrões de Projeto:

  • Criacionais Resolver problemas de criação de objetos  * Singleton  * Factory  * Builder
  • Comportamentais
  • Estruturais

Padrão Observer:
1 observado para 1 ou vários observadores
O observado não muda nada do observador. Dá só uma notificação e o observador decide o que faz com aquilo, porque cada observador pode fazer algo diferente.
Observado:
Attach
Detach
Notify

Observador:
Update

MVC não tem persistência. É outra coisa:

  • Model: tem métodos e propriedades
  • View: camada de apresentação onde estão as interações com usuário
  • Controller: fica no meio do caminho fazendo a ligação do view e model

DAO:

Resolver impedância entre objeto e SQL
DAOConnection Camada que gerencia a conexão
DAO Camada que converte o modelo para instrução SQL (ou txt......)
Uma classe de negócio, uma classe de persistência

RTTI é capacidade de extrair informações do objeto em tempo de execução

Criar uma rotina para diversas situações para ser usada de acordo com as informações que são extraídas do objeto 

Uma classe para cada informação que se quer extrair. Fields, properties....

Todos são arrays dinâmicos. Uso de for in

Atributos customizados:
Informações adicionais do objeto sem alterar o objeto
declara entre colchetes []  em cima do elemento a ser atribuida a informação

Discussion (0)