Orientação a Objeto

...

Proteção Modular

Um método satisfaz a proteção modular se certas arquiteturas são gerados em que o efeito de uma condição excepcional, o erro, o que ocorreu em tempo de execução, só afeta o módulo onde ela ocorre, ou apenas se espalha para os módulos vizinhos.

A modularidade: 5 Princípios

Cinco princípios resultam dos critérios anteriores que devem ser seguidas para garantir a modularidade:

- Unidades Modulares Linguísticos

- Poucas conexões entre módulos

- Troca de informações intermodulação mínima.

- Conexões explícitas

- Informações esconderijo

Unidades Modulares Linguísticos

Os módulos devem corresponder a unidades sintáticas na língua utilizada. Esta pode ser uma linguagem de programação, uma linguagem de design, uma linguagem de especificação, etc.

Quanto às linguagens de programação, os módulos devem ser compilados separadamente.

Este princípio trata dos critérios de continuidade, a composição, decomposição e proteção modular antes mencionados.

Algumas Interfaces

Cada módulo deve comunicar-se, tanto quanto possível, com o menor número de módulos.

Este princípio trata dos critérios de continuidade e de proteção.

Pequenas Interfaces

Se dois módulos de comunicar uns com os outros, eles devem trocar a menor quantidade de informação.

Este princípio trata dos critérios de continuidade e proteção.

Interfaces Explícito

Quando dois módulos se comunicam entre si, isso deve ser explicitado no texto de qualquer um deles, ou ambos.

Por trás desse princípio, podemos encontrar a decomposição modular e os critérios de composição: se um módulo de quebra nos outros, ou que é feito por outros, qualquer interligação devem ser claramente identificados. Ele também vem a partir dos critérios de continuidade e compreensibilidade.

[pic 3]

Ocultação de informações

A informação relativa a um módulo deve ser restrito ao módulo a menos que você queira que para torná-lo público.

---------------------------------------------------------------

Assunto 2

Módulo 1: Objetos e Classes

Objetos e classes estão intimamente relacionados, mas eles não são os mesmos. Cada objeto é uma instância de uma classe, de modo que poderíamos considerar uma classe como um tipo de dados (por exemplo, int), e um objeto como uma variável desse tipo (por exemplo, int i). Por outro lado, poderíamos dizer que uma classe é a que descreve o estado e o comportamento de cada um dos objetos desse tipo (classe).

Objetos

O conceito de objetos de software surge da necessidade para modelar objetos no mundo real. Um objeto é um "pacote" de procedimentos e dados. No desenvolvimento OOP os procedimentos têm um nome especial: métodos. Mantendo a terminologia tradicional, os dados são chamadas de variáveis ​​(ou atributos), porque o seu valor pode mudar ao longo do tempo.

[pic 4]

Como exemplo, podemos pensar em uma maneira de modelar um veículo em uma fábrica simulado. O veículo pode ter uma variedade de comportamentos, tais como o movimento de um lugar para outro, upload e download de seu conteúdo, etc.

Da mesma forma, deve manter informações sobre suas características inerentes (velocidade máxima, o volume do cilindro do motor, capacidade de bagagem, etc) e seu estado atual (conteúdo, localização, orientação, velocidade, etc).

A fim de apresentar o veículo como um objeto, seu comportamento pode ser descrito como um método e suas características como variáveis. Durante a simulação, os métodos de agir sobre as variáveis ​​mudam o seu conteúdo, uma vez que o comportamento de um objeto muda o seu estado. Por exemplo, se o veículo muda de posição, as variáveis ​​que se referem a posição (x, y) pode variar.

O conceito de objeto é simples, mas poderosa. Objetos construir módulos de software ideais, porque eles podem definir e manter a independência de cada outro. O conhecimento de cada objeto é expressa em suas variáveis ​​e tudo o que pode fazer é expressa em seus métodos.

Mensagens

Os objetos do mundo real pode executar uma variedade infinita de efeitos: criar, destruir, enviar, compartilhar, etc. A questão é: como podemos representar todos esses diferentes tipos de interações no software?

O autor do SIMULA encontra uma solução elegante para este problema: as mensagens. A maneira na qual os objetos interagem um com o outro está a enviar mensagens para executar métodos. A mensagem é simplesmente o nome de um objeto, seguido do nome do método de objeto que deseja executar. Se um método requer informações adicionais para esclarecer o que fazer, a mensagem inclui as informações necessárias, isto é conhecido como parâmetros do método. O objeto a enviar a mensagem é chamado emissor, e o que recebe é o receptor.

Retomando nosso exemplo, de um carro para se deslocar de um lugar para outro, um objeto pode enviar a seguinte mensagem:

Veículo A MoveA Localização

No nosso exemplo, um veículo é o nome do receptor e MoveA é o método executado. Localização é um parâmetro que recebe o método para saber para onde ir.

[pic 5]

Uma simulação orientada a objetos é uma interação entre os objetos que enviam mensagens uns aos outros. Tudo que um objeto pode fazer é expressa por mensagens, é um mecanismo simples, mas ele suporta todas as possíveis interações entre objetos.

Para um objeto para fazer algo que enviar um pedido