Mostrando postagens com marcador Programação Orientada a Objetos. Mostrar todas as postagens
Mostrando postagens com marcador Programação Orientada a Objetos. Mostrar todas as postagens

terça-feira, 22 de dezembro de 2015

O que são os Princípios SOLID?

Robert C. Martin, por volta dos anos 90, compilou cinco princípios da orientação a objetos que visam nos ajudar com a tarefa de obter um código mais sólido (S.O.L.I.D.). Já a criação do acrônimo S.O.L.I.D. propriamente dito, foi introduzida por Michael Feathers, igualmente integrante da Object Mentor Inc. e autor do livro Working Effectively with Legacy Code. Feathers, na busca por facilitar a absorção da ideia, percebeu que a junção das cinco letras iniciais dos princípios, a saber: Single Responsability PrincipleOpen Closed PrincipleLiskov Substitution PrincipleInterface Segregation Principle e Dependency Inversion Principle, formavam a palavra Solid, que nos remete aos objetivos implícitos dos princípios, isto é, um desenvolvimento mais sólido.

Os cinco princípios da OO:
  • Single Responsibility Principle (SRP), ou, Princípio da Responsabilidade Única. Esse princípio diz que as classes devem ser coesas, ou seja, terem uma única responsabilidade. Classes assim tendem a ser mais reutilizáveis, mais simples, e propagam menos mudanças para o resto do sistema.
  • Open Closed Principle (OCP), ou Princípio do Aberto Fechado. Diz que as classes devem poder ter seu comportamento facilmente estendidas quando necessário, por meio de herança, interface e composição. Ao mesmo tempo, não deve ser necessário abrir a própria classe para realizar pequenas mudanças. No fim, o princípio diz que devemos ter boas abstrações espalhadas pelo sistema.
  • Liskov Substitution Principle (LSP), ou Príncipio da Substituição de Liskov. Esse princípio diz que precisamos ter cuidado para usar herança. Herança é um mecanismo poderoso, mas deve ser usado com parcimônia, evitando os casos de Gato-estende-Cachorro, apenas por possuírem algo em comum.
  • Interface Segregation Principle (ISP), ou Princípio da Segregação de Interfaces. Esse princípio diz que nossos módulos devem ser enxutos, ou seja, devem ter poucos comportamentos. Interfaces que tem muitos comportamentos geralmente acabam se espalhando por todo o sistema, dificultando manutenção.
  • Dependency Inversion Principle (DIP), ou Princípio da Inversão de Dependências. Esse princípio diz que devemos sempre depender de abstrações, afinal abstrações mudam menos e facilitam a mudança de comportamento e as futuras evoluções do código.

quarta-feira, 6 de maio de 2015

Fatorial Java

Disponibilizando aqui (Github) um programinha para calcular o Fatorial de um numero, as vezes pedem em testes de entrevistas.
  • Calculo do fatorial de um numero de maneira simples imprimindo no console;
  • Calculo do fatorial de um numero inteiro recursivamente imprimindo no console;
  • Calculo do fatorial de um numero inteiro recursivamente com Caixas de Diálogo (JOptionPane);


terça-feira, 2 de dezembro de 2014

Desbravando Java e Orientação a Objetos

Olá Pessoal. Essa semana a Casa do Código lançou um novo livro de Java e Orientação a Objetos, Desbravando Java e Orientação a Objetos: Um guia para o iniciante da linguagem do Rodrigo Turini. Para quem está começando agora, a leitura pode ser bem interessante. O que achei bem legal no livro é que desde o inicio se trabalha com uma IDE e é abordado alguns pontos sobre o Java 8. Assim em poucas horas já se é possível rodar o seu primeiro programa. 

"O livro explora importantes conceitos da orientação a objetos como encapsulamento, herança e polimorfismo. Sempre com exemplos mão na massa, pensados para que você saiba exatamente quando e como utilizá-los. Além disso, serão ensinadas boas práticas de programação e recursos essenciais que com certeza farão parte de sua rotina, dos mais tradicionais aos mais novos introduzidos no Java 8. É sua vez de desbravar o mundo Java!"

O E-book está custando R$ 29,90 um bom investimento para quem quer iniciar seus estudos/carreira na linguagem.  


Melissa Lobo.

terça-feira, 25 de novembro de 2014

Porque programar em Java?

A tecnologia Java esta presente em mais de 4,5 bilhões de dispositivos e é utilizada em todos os principais segmentos da indústria, estando presente em uma ampla gama de dispositivos, computadores e redes. Sua versatilidade, eficiência, portabilidade de plataforma e segurança fazem dela a tecnologia ideal para soluções corporativas integradas. A tecnologia Java está em todo lugar! Ela pode ser encontrada em laptops, datacenters, consoles de jogo, supercomputadores científicos, telefones celulares, smartphones, tablets, TVs, cartões inteligentes e até na Internet. Alguns números publicados no www.java.com são:
  • Mais de 800 milhões de PCs
  • 2,1 bilhões de telefones celulares e outros dispositivos portáteis
  • 3,5 bilhões de cartões inteligentes
  • Além de set-top boxes(TV), impressoras, webcams, jogos, sistemas de navegação para automóveis, terminais lotéricos, dispositivos médicos, guichês de pagamento de estacionamento etc.
O Java foi testado, refinado, ampliado e experimentado por uma comunidade dedicada. E, com mais de 6,5 milhões de desenvolvedores, é a tecnologia mais ampla e ativa do planeta. Com sua versatilidade, eficiência e portabilidade, o Java tem valor inestimável para desenvolvedores, pois permite:
  • Criar um software em uma plataforma e executá-lo em praticamente qualquer outra, desde que seja habilitado com Java.
  • Desenvolver soluções para serem executadas em estações de trabalho (desktop), servidores de grande porte (High End Servers), navegadores de internet W3C, diversos dispositivos móveis da atualidade, todos eles 100% integrados usando web services.
  • Combinar aplicativos ou serviços para criar soluções ou serviços altamente personalizados.
  • Versatilidade de selecionar ou combinar diferentes tipos de linguagens de programação (Atualmente com mais de 240 diferentes linguagens).
  • Independência de fornecedores na utilização de produtos tecnológicos de terceiros através das especificações JCP.
  • Integração total entre as partes da soluções sendo simultaneamente executadas nos diferentes estilos e diferentes plataformas da necessidades do mercado atual.
Além de ser uma das linguagens mais procuradas e bem pagas no mercado de trabalho. 

quarta-feira, 20 de agosto de 2014

O que é um construtor?

Um construtor contem o código que será executado quando você instanciar um objeto. Em outras palavras, o código que será executado quando você escrever new em um tipo de classe.
Ex: Adicao adicao = new Adicao ();
Um construtor deve ter o mesmo nome que a classe, e o mesmo não tem nenhum tipo de retorno (nunca).Ex:


public Adicao (int size) { }
 

Toda classe que for criada terá um construtor, até mesmo quando não o escrevemos, quando isso acontece o compilador cria um construtor. (o construtor criado pelo compilador não tem nenhum tipo de argumento).Ex: 

public Adicao () { }


Porém o compilador só irá criar o construtor se você não informar absolutamente nada sobre eles. Se você criar um construtor o compilador entende que você é o responsável por eles e não irá se interferir.
Quando há mais de um construtor em uma classe eles são chamados de construtores sobrecarregados, porém cada construtor terá que ter uma lista de argumentos diferente. Uma lista de argumentos inclui a ordem e o tipo dos argumentos.


O que diferencia um construtor de um método, é que todo método deve ter um tipo de retorno, e os construtores não, eles nunca retornam nada.

Pra não esquecer:
Um construtor é o código que é executado quando escrevemos new em um tipo de classe, ou seja, instanciar a classe que foi definida;


Melissa Lobo.

segunda-feira, 11 de agosto de 2014

O que é MVC?

MVC (Model-View-Controller) é um padrão de projeto arquitetural criado com o objetivo de separar a lógica de negócios da camada de apresentação.

Porque utilizar o MVC?
Com o aumento da complexidade das aplicações desenvolvidas, sempre visando a programação orientada a objeto, torna-se relevante a separação entre os dados e a apresentação das aplicações. Desta forma, alterações feitas no layout não afetam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout.
Esse padrão resolve este problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interação com o utilizador, introduzindo um componente entre os dois: o controlador.
Como funciona?
 O MVC guia o desenvolvedor na tentativa de organizar a aplicação de forma que tenhamos três papéis bem definidos, onde o MODEL (modelo) é responsável por todo o processamento da aplicação (regras de negócio e acesso ao banco de dados), o VIEW (visão) serve apenas para apresentação de resultados como também entrada de informações e o CONTROLLER (controlador) faz a comunicação entre o MODEL e o VIEW.

MODEL, VIEW e CONTROLLER

Além de dividir a aplicação em três tipos de componentes, o desenho MVC define as interações entre eles.
  • Um controller (controlador) pode enviar comandos para sua visão associada para alterar a apresentação da visão do modelo (por exemplo, percorrendo um documento). Ele também pode enviar comandos para o modelo para atualizar o estado do modelo (por exemplo, editando um documento).
  • Um model (modelo) notifica suas visões e controladores associados quando há uma mudança em seu estado. Esta notificação permite que as visões produzam saídas atualizadas e que os controladores alterem o conjunto de comandos disponíveis. Uma implementação passiva do MVC monta estas notificações, devido a aplicação não necessitar delas ou a plataforma de software não suportá-las.
  • view (visão) solicita do modelo a informação que ela necessita para gerar uma representação de saída.

E assim esses três formam o padrão arquitetural chamado de MVC, ou Model View Controller. Lembrando que ele pode sofrer variações de diversas maneiras. E o que o MVC garante é a separação de tarefas, facilitando assim a reescrita de alguma parte, e a manutenção do código.