Diário de estudos - SCJP

Utilizando as Interfaces

2008-02-12T15:43:00.000-08:00

Saudações, meus amigos.
Aqui vou eu, seguindo com meus estudos e também com os meus posts!

Agora falaremos sobre as Interfaces em Java.

As interfaces são considerados "contratos" que dizem "o que" a classe pode fazer, mas não mostra "como" fazer. Esquisito, né?! :). Pois é, este é um conceito que demorei muito para entender, a princípio eu não entendia o funcionamento das mesmas. Depois, quando entendi como elas funcionavam comecei a me questionar o por que da utilização das mesmas. Hoje em dia tenho consciência de que as interfaces são muito úteis.

Sendo considerada como sendo "uma classe 100% abstrata, uma interface só pode possuir métodos abstratos e públicos, sem nenhuma implementação. As interfaces podem ter modificadores de acesso public e default (ou ausência de modificador). Os métodos têm modificadores public e abstract implícitos, não sendo necessário digitá-los. Podemos ter atributos dentro de uma interface, porém, todos eles devem ser constantes (public static final, para os íntimos). Porém, não é necessário a declaração das constantes desta maneira, elas são consideradas assim por padrão. Portanto, não se pode alterar o valor de um atributo de uma interface, pois se tratarem de constantes que foram criadas na mesma, e tiveram seu valor atribuído para garantir que todas as classes que a implementarem tenham acesso ao mesmo valor.

As interfaces só podem estender (herdar) outras interfaces, garantindo assim que elas somente terão métodos abstract.

Abaixo alguns exemplos de utilização de interfaces:

Flyable.java - Interface com o modificador de acesso default

package com.blogspot.diarioscjp.terceiropost;

interface Flyable {

int maxHeight = 200;

void fly();
}

Duck.java - Classe que implementa a Interface Flyable

package com.blogspot.diarioscjp.terceiropost;

public class Duck implements Flyable {//Consegue implementar pois estão no mesmo pacote.

public void fly() {
for(int h=0; h <= maxHeight; h++)
System.out.println("Pato voando. Altura: " + h + " metros.");
}

}

Abaixo um exemplo de código de uma classe que não compilaria, se estivesse fora do mesmo pacote da interface:

StrangeDuck.java

package com.blogspot.diarioscjp.naocompila;

public class StrangeDuck implements Flyable {
//se você utiliza o Eclipse como IDE, ele vai te avisar de que a Flyable
//não pode ser resolvido como um tipo, porque este pacote não conhece a interface.
}

Se modificarmos a nossa interface para public, conseguiremos implementá-la:

package com.blogspot.diarioscjp.terceiropost;

public interface Flyable {

int maxHeight = 200;

void fly();
}

StrangeDuck.java - Classe que implementa a interface, fora do pacote

package com.blogspot.diarioscjp.naocompila;

import com.blogspot.diarioscjp.terceiropost.Flyable;
//Reparem que a classe precisou fazer o import da interface, por não conhecer este tipo no pacote.

public class StrangeDuck implements Flyable {

public void fly() {
for(int h=0; h <= maxHeight; h++)
System.out.println("Pato voando. Altura não pode ser determinada");
//Para demonstrar que as classes implementam as interfaces de maneira
//diferente, esta classe sabe voar, mas não sabe determinar a altura.
}

}

Bom pessoal, por hoje é só!

Espero que estejam gostando do meu blog, e que ele sirva de ajuda para alguém!

Um abraço a todos.

Classes e seus Modificadores

2008-02-12T11:03:00.000-08:00

Buenas pessoal!

Eu nem sei bem como começar este post, então na verdade vou dizer a verdade, nada mais que a verdade: Eu vou direto ao assunto.

Meu livro Certificação Sun para Programador Java 5 - 2a Edição Revisada chegou e comecei a estudar.

As impressões sobre o Livro não poderiam ser melhores. Cada parte é muito bem explicada, deixando bem claro aonde os autores querem chegar.

O primeiro capítulo se chama "Declarações e Controle de Acesso" e trata os seguintes objetivos da certificação:

1.1 Desenvolver código que declare classes (incluindo classes abstract e todas as formas de classes aninhadas), interfaces e enums, e inclua o uso apropriado de declarações package e import (incluindo importações estáticas).

1.2 Desenvolver código que declare uma interface. Desenvolver código que implemente ou estenda uma ou mais interfaces. Desenvolver código que declare uma classe abstract. Desenvolver código que estenda uma classe abstract.

1.3 Desenvolver código que declare, inicialize e use primitivos, arrays, enums e objetos como variáveis static, de instâncias e locais. Além disso, usar identificadores legais para os nomes de variáveis.

1.4 Desenvolver código que declare métodos static e não-static e, se apropriado, usar nomes de métodos que obedeçam aos padrões de nomeação JavaBeans. Além disso, desenvolver código que declare e use uma lista de argumentos de extensão variável.

Bom, está longe das minhas pretensões ENSINAR JAVA para as pessoas, estou somente dando o meu testemunho e citando as coisas que eu julguei importantes durante meus estudos. Basicamente eu postarei aqui os assuntos relacionados às coisas que fiz algum tipo de anotação durante a leitura. Se fosse para falar sobre TUDO que tem no livro, seria mais fácil recomendar que todos o comprassem. E realmente eu recomendo isso!

O primeiro assunto a ser tratado é justamente a declaração de classes em Java. Quantas noites perdidas criando classes e mais classes? (não muitas, ainda), mas nunca é tarde para começar! A primeira coisa que devemos saber é que somente dois modificadores de acesso podem ser atribuídos à classes: default (ou ausência de modificadores) e public. No acesso default (podemos considerar nível de pacote), somente disponibiliza a classe e seus membros para as classes e membros que estiverem no mesmo pacote da classe em questão. Quem estiver fora do pacote não tem acesso a essa classe, nem mesmo através de um import. Já quando definimos a classe como sendo public, então estamos dizendo que todas as classes de todos os pacotes do Universo Java (gostei disso, os autores falam em Java Universe). Abaixo, exemplos de declarações de classes com acesso default e public.

Blog.java - Classe com acesso default

package com.blogspot.diarioscjp;

class Blog {//Ausência de modificador = default
//código importante da classe
}

OtherBlog.java - Classe com acesso public

package com.blogspot.diarioscjp;

public class OtherBlog {
//código importante da classe
}

Até agora vimos então como se declara uma classe e quais são os modificadores de acesso pertinentes a elas. Agora veremos a seguir os outros modificadores de classes, mas estes não levam em conta os níveis de acesso. São eles: final, abstract e strictfp (embora não vamos falar sobre o último agora)

Classes final são aquelas que não podem ser estendidas, ou seja, essa classe nunca vai poder ter sub-classes. Mas qual é a vantagem disso? Acabamos com um dos maiores princípios da Orientação a Objetos, a herança. Também teremos o problema (ou não, dependendo do caso) de que nenhum dos métodos dessa classe irão poder sofrer alterações em sua implementação. Por outro lado, quando temos uma classe não-final, temos a possibilidade de estende-la e alterar seus comportamentos quando for pertinente. Mesmo quando não possuímos os fontes da classe. Isso é um ótimo recurso da Orientação a Objetos (que a partir de agora ganhou o apelido de O.O) nos meus posts.

Do outro lado temos as classes abstract. Essas sim podem ser estendidas, mas em compensação, não podem ser instanciadas. Não conseguiremos declarar uma instância de uma classe abstract e usá-la em outras classes. As classes abstract precisam ser estendidas por outras classes - mais pra frente entraremos em mais detalhes - para poderem ser instanciadas. Mais especificamente, só podemos instanciar uma classe concreta (não-abstrata). Numa classe onde temos um método abstract, existe a obrigação da mesma ser abstrata. Os métodos abstratos não possuem implementações. Eles terminam com ; na sua linha de declaração.

Vale lembrar que podemos ter algumas combinações de modificadores para uma classe, com modificadores de acesso e outros. Mas muito cuidado! Uma classe nunca pode ser abstract e final ao mesmo tempo. Pensando melhor sobre isso, não teria sentido mesmo, não é?! Se uma classe abstract exige que implementemos seu métodos nas sub-classes, seria no mínimo esquisito colocar também o modificador final, que justamente pelo contrário, preza pela preservação dos métodos e atributos da classe.

Essas foram as minhas observações sobre as Classes e seus Modificadores.

No mais, estou indo embora! Um abraço a todos e até o próximo post.

A compra do Livro...

2008-01-31T04:33:00.000-08:00

Eis que paira no ar a notícia de que: mais um maluco vai estudar para ser um profissional certificado na linguagem Java. Mais especificamente vou começar os meus estudos para obter a certificação: Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0 (CX-310-055). A partir de agora, este blog será a minha segunda casa e uma área onde escreverei sobre as coisas que achar interessante nos meus estudos, dicas para quem também está estudando, dúvidas, discussões sobre algum tópico em específico, etc.

Conversa vai, conversa vem, e eu esqueci de me apresentar. Sou Felipe Zanardo Affonso, mais conhecido como Batata. Sou bacharel em Ciência da Computação pela Universidade Metodista de São Paulo (São Bernardo do Campo) e atualmente estou trabalhando como consultor no mesmo lugar onde me formei, com muito orgulho.
Trabalho com Java há menos de 1 ano, mas com experiências anteriores com C# eu acabei me virando. Agora estou no caminho para fazer a prova e virar um profissional certificado pela Sun.

Para começar meus estudos, comprei ontem o livro Certificação Sun para Programador Java 5 - 2a Edição Revisada dos autores Kathy Sierra e Bert Bates. Um grande amigo, Renan Rodrigues, e mais N pessoas que andei pesquisando pelo fórum do GUJ (Grupo de Usuários de Java) recomendam este livro para ser o guia de estudos. Então vamos lá!

Para o primeiro post é só! Espero que este blog seja útil para mais alguém além de mim!

Um abraço a todos.