curso-lpoo.blogspot.com

Existem tantas maneiras de desenvolver software quanto existem desenvolvedores. Entretanto, uma equipe de desenvolvimento de software precisa de uma estratégia unificada para desenvolver software. Nada será feito, se cada desenvolvedor fizer sua própria atividade. As metodologias de software definem uma maneira comum de encarar o desenvolvimento de software. Uma metodologia frequentemente conterá uma linguagem de modelagem (como a UML) e um processo. Novo Termo Um processo de software mostra os vários estágios do desenvolvimento de software. Um exemplo familiar de processo de software é o processo de cascata Figura 9.1       O processo de cascata.  Conforme a Figura 9.1 ilustra, o processo de cascata é sequencial e unidirecional. O processo é constituído de quatro estágios distintos:  1. Análise de requisitos  2. Projeto  3. Implementação  4. Teste Quando segue o processo de cascata, você vai de um estágio para o próximo. Entretanto, uma vez ...

Imagine que você está construindo uma casa. Antes de começar a assentar os tijolos ou escolher a cor da tinta, é preciso entender muito bem como a casa será usada: quantos quartos são necessários, onde ficará a cozinha, como a luz do sol entra pela janela pela manhã. Na programação, acontece algo parecido. A Análise Orientada a Objetos (AOO) é justamente essa etapa de "planejamento da casa": é o processo de entender profundamente o problema que queremos resolver antes de começar a escrever qualquer código. Muitas vezes, na ansiedade de colocar a mão na massa, os desenvolvedores pulam essa etapa e partem diretamente para a programação. O resultado pode ser um software que até funciona, mas que não atende direito às necessidades reais dos usuários, como uma casa com a porta principal abrindo para a parede. A AOO existe para evitar isso. Ela nos força a fazer as perguntas certas, a conversar com as pessoas que usarão o sistema e a compreender as regras do "mundo real" ...

Hoje vamos mergulhar um pouco mais no mundo das classes, construindo sobre o que já aprendemos anteriormente. Imagine que uma classe é como uma planta baixa para criar objetos - ela define como algo deve ser construído e como vai se comportar. Pense em uma classe como uma receita de bolo. A receita em si não é o bolo, mas nos diz exatamente quais ingredientes usar e como misturá-los para criar deliciosos bolos. Da mesma forma, uma classe descreve que atributos (ingredientes) e métodos (ações) nossos objetos terão. Um conceito importante que vamos explorar são os construtores. Eles são como os primeiros passos na preparação do nosso bolo. Temos dois tipos principais: os construtores que não recebem ingredientes especiais (chamados de "noargs") e aqueles que já começam com ingredientes específicos. Por exemplo, se pensarmos em uma classe "Café", um construtor sem argumentos poderia criar um café padrão, enquanto um construtor com argumentos poderia especificar se quer...

Antes de colocarmos a mão na massa e começarmos a programar, precisamos preparar o nosso "ambiente de trabalho". Pense nisso como um pintor preparando sua tela e suas tintas, ou um chef organizando seus ingredientes e facas. Para criar programas em Java, a nossa "tinta" e o nosso "ingrediente" principal é o Kit de Desenvolvimento Java, também conhecido como JDK. Não se preocupe com os nomes técnicos. O JDK é simplesmente um pacote de ferramentas que instalamos no computador para que ele entenda e execute comandos escritos em Java. Para todos os exercícios e para o projeto final que faremos juntos, vamos usar a linguagem Java. A versão mínima que precisamos é a 1.2, mas, como sempre queremos o melhor e mais atualizado, é recomendável baixar a versão mais recente disponível. O local mais comum para conseguir o JDK é diretamente do site da Oracle (que herdou o projeto da Sun Microsystems). Você pode encontrá-lo facilmente fazendo uma busca na internet por ...

O encapsulamento é um dos conceitos mais importantes da programação orientada a objetos e pode ser entendido como a ideia de “esconder o que não é necessário e mostrar apenas o que importa”. Para os alunos que estão começando, pense em uma televisão: você não precisa saber como todos os circuitos funcionam por dentro para usá-la, basta apertar os botões do controle remoto. O funcionamento interno fica escondido (encapsulado), e você só tem acesso ao que realmente precisa. Esse conceito traz várias vantagens. A primeira delas é que ele nos ajuda a pensar nos problemas de maneira natural. Quando estamos modelando um programa, conseguimos separar responsabilidades e criar classes que representem as coisas do mundo real. Isso torna o raciocínio mais simples, porque podemos focar no problema em si e não nos detalhes técnicos da implementação. Outra vantagem é a confiabilidade. Quando cada parte do programa tem responsabilidades bem definidas e sua implementação fica escondida, fica mais f...

Quando falamos em ocultação da implementação, estamos nos referindo a um dos princípios mais importantes da programação orientada a objetos. Decidir o que deve ser exposto em uma interface e o que precisa permanecer oculto nem sempre é simples, mas existem orientações que ajudam a tornar essa escolha mais clara. O ponto central é entender que apenas os métodos destinados ao uso por outros devem compor a interface pública, enquanto aqueles que servem apenas para o funcionamento interno da classe devem permanecer ocultos. Outro aspecto essencial é o tratamento das variáveis internas. Elas devem sempre ser escondidas, exceto quando se tratarem de constantes. Mais do que ocultas, recomenda-se que estejam acessíveis somente dentro da própria classe, garantindo maior segurança e evitando que detalhes internos de implementação sejam expostos de forma desnecessária. Esse é um conceito que será explorado de maneira mais aprofundada nas próximas aulas, mas desde já é importante compreender que ...

É natural que, ao aprender sobre Tipos Abstratos de Dados (TADs), você comece a fazer a conexão com classes, um dos pilares da Programação Orientada a Objetos. E você está no caminho certo! A transformação de um TAD em uma classe concreta é, de fato, um passo importante, mas é preciso entender que essa transição possui nuances específicas de cada linguagem de programação. No entanto, por trás dessa diversidade, existem princípios universais que podemos observar. A grande maioria das linguagens OO já vem equipada com palavras-chave e estruturas pensadas justamente para ajudá-lo a construir classes bem encapsuladas, que é a essência de um bom TAD. O primeiro e mais fundamental desses recursos é a própria definição da classe. Pense nela como a evolução natural do conceito de TAD, mas agora turboalimentada com funcionalidades poderosas que você vai explorar e dominar ao longo desta jornada de aprendizado. Dentro do escopo de uma classe, organizamos a realidade do nosso objeto. Lá dentro, e...

Ao escrever uma classe, você pode ter problemas, se tentar trabalhar de forma abstrata demais. É impossível escrever uma classe que satisfaça todos os usuários e cada situação. Imagine que você tivesse de escrever um objeto pessoa para um sistema de folha de pagamento de uma empresa. Esse objeto pessoa vai ser muito diferente de um objeto pessoa no simulador de fluxo de tráfego que discutimos anteriormente. A abstração pode ser perigosa. Mesmo que você tenha abstraído algum elemento, ele poderá não funcionar em todos os casos. É muito difícil escrever uma classe que satisfaça as necessidades de todos os usuários. Não caia na fixação da abstração — resolva seus problemas primeiro! Tudo se resume a fazer o suficiente para resolver o problema imediato. Incluir todos os detalhes necessários para o objeto pessoa funcionar nos dois contextos seria muito dispendioso. Isso pode provocar todos os problemas que você viu hoje, devido à responsabilidade embaralhada. Embora você possa ligar seu obj...

 A ocultação da implementação evolui naturalmente para uma discussão sobre a divisão da responsabilidade. Na seção anterior, você viu como poderia desacoplar código ocultando detalhes da implementação. A ocultação da implementação é apenas um passo na direção da escrita de código fracamente acoplado. Para ter realmente código fracamente acoplado, você também deve ter uma divisão da responsabilidade correta. Divisão da responsabilidade correta significa que cada objeto deve executar uma função — sua responsabilidade — e executá-la bem. A divisão da responsabilidade correta também significa que o objeto é coesivo. Em outras palavras, não faz sentido encapsular muitas funções aleatórias e variáveis. Elas precisam ter um forte vínculo conceituai entre si. Todas as funções devem trabalhar no sentido de uma responsabilidade comum. A ocultação da implementação e a responsabilidade andam lado a lado. Sem ocultação da implementação, a responsabilidade pode faltar em um objeto. É de responsa...