Java - Declarações e Modificadores de Classes - Declaração para Arquivos-Fontes

Os modificadores se dividem em duas categorias: “Modificadores de acesso” e “Modificadores que não se referem a acesso”.

1) Modificadores de acesso

Servem para você poder restringir ou permitir acesso a uma classe que você está criando (ou partes dessa classe). Ou seja, definem o escopo de visivilidade de uma classe. Os escopos devisibilidade definido pelos modificadores de acesso são: Público, Protegido e Privado.
Eles são definidos em código através do emprego das palavras reservadas: “public” (Escopo de visibilidade público), protected (Escopo de visibilidade protegido), private (Escopo de visibilidade privado).
É importante notar que, embora existam quatro controles de acesso (que funcionam como níveis de acesso), os modificadores de acesso são apenas três (public, protected, private). O quarto nível de controle de acesso (chamado de acesso “default” ou "de pacote") é o que você obtém quando não usa nenhum dos três modificadores de acesso na declaração realizada durante a codificação de uma classe. Ou seja, toda classe, método, ou/e variável de instância que você declarar possui um controle de acesso, independentemente disso ser declarado explicitamente ou não.
Todos os quatro controles de acesso são adequados para as declarações de métodos e variáveis. Contudo, para classses, somente dois deles são válidos: público ou default . Uma classe só pode ser declarada como pública ou default, os outros dois níveis de controle de acesso não se aplicam para classes.
Os modificadores de acesso são os responsáveis por outra característica fundamental para a O.O. o “encapsulamento”

1.1) Acesso a Classes

O termo aceeso a classes refere-se ao fenômeno que através de um método próprio, uma classe (classe “ZnX”) acessar outra (classe “ZnY”). Isso significa que a classe “ZnX” pode fazer uma das seguintes coisas:

1) Criar uma instancia da classe “ZnY”.
2) Estender a classe “ZnY” (ou seja, tornar-se uma subclasse da classe “ZnY”).
3) Acessar certos métodos e variáveis dentro da classe “ZnY”, dependendo do controle de acesso desses métodos e variáveis.


Definindo Controle de Acesso em Classes

Na prática, acesso significa visibilidade. Suponha que temos duas classes: classe “ZnX” e classe “ZnY”. Se a classe “ZnX” não puder ver a classe “ZnY”, o nível de acesso dos métodos e variáveis dentro da classe “ZnY” não fará diferença. A classe“ZnX” não terá como acessar os métodos e propriedades de “ZnY”.

Acesso Default: Uma classe cujo modificador de acesso é o chamado “default”, é a quela que não tem nenhum modificador precedendo na sua declaração. Esse é o controle de acesso que você obtém quando não digita um modificador na declaração da classe. Pense no acesso defaultcomo um acesso de nível de pacote, porque a classe com acesso default só pode ser vista por classes de dentro do mesmo pacote. Por exemplo: Se a classe “ZnX” e a classe “ZnY” estiverem em pacotes diferentes, e a classe “ZnX” tiver acesso default, a classe “ZnY” não será capaz de criar uma instância da classe “ZnX”. Nem mesmo, se quer, declarar uma variável ou tipo de retorno da classe “ZnX”. Fataliticamente, para a classe “ZnY” a classe “ZnX” nem sequer existe. Do contrário, o compilador irá reclamar caso isso não seja repeitado. Observe o seguinte arquivo-fonte:

package fermentadosZN;

class VinhoZn { }

Agora observe o segundo arquivo-fonte:

package destiladosZN;

import fermentadosZN.VinhoZn;

class ConhacZn extends VinhoZn { }

Observe, nos trechos de código ilustrados acima que, a superclasse “VinhoZn” está em um pacote diferente da subclasse “ConhacZn”. Veja na linha 3 a declaração “import” possibilitando a package “destiladosZN” importar a classe “VinhoZn” para a ser usado n apackage “destiladosZN”. Supondo que tentássemos compilar, o arquivo “fermentadosZN” compilará sem problemas, contudo, quando tentamos compilar o arquivo “destiladosZN”, receberemos uma mensagem de exceção semelhante do tipo:

  Can't access class destiladosZN. Class or interface must be public, in same package,or an  
  accessible member class.
  import destiladosZN;

“destiladosZN” não compila porque a sua superclasse, “VinhoZn”, tem acesso default e está em um pacote diferente. Existem duas coisas que podemos pode fazer para nosso problema hipotético:

1) Poderiamos colocar ambas as classes no mesmo pacote,
2) Ou. poderiamos declarar “VinhoZn” como public. Exemplo:

Esse tipo de situação/problema costuma ser usado em prova de certificação. Portanto, quando você vir uma questão com lógica complexa, certifique-se de olhar os modificadores de acesso antes de qualquer coisa. Assim, caso identifique uma violação de acesso (por exemplo, uma classe do pacote “X” tentando acessar uma classe default do pacote “Y”), você saberá que o código não vai compilar, portanto não precisa nem se dar ao trabalho de tentar entender a suposta lógica complexa da questão. A qual está lá justamente para desviar sua atenção indizindo você ao erro. Além de economizar tempo e stress.

Acesso Público: Uma declaração de classe com a palavra reservada public torna ela visivél a todas as classes, de todos os pacotes. Todas as classes do Universo Java (JU) têm acesso a uma classe pública. Contudo, não se esqueça que mesmo sendo pública, uma classe para ser usada, se estiver em um pacote diferente, será obrigatório importar-lá.

2) Outros Modificadores de Classes (Não-referentes a Acesso)

Além dos modificadores vistos anteriormente ainda existem mais três, os quais são definidos pelas palavras reservadas “final”, “abstract” e “strictfp”. Esses modificadores existem em adição a qualquer controle de acesso existente na classe. Logo poderiamos, por exemplo, declarar uma classe como “public” e “final” ao mesmo tempo.
Todavia, isso não é adequado para todas as situações. Não é sempre que podemos misturar modificadores não-referentes a acesso. Por exemplo: É possível usar “strictfp” em combinação com “final”, contudo nunca (jamais, em tempo algum) marcar uma classe como “final” e “abstract” ao mesmo tempo.
Imagino que isso possa parecer óbvio demais para quem já conhece bem orientação a objetos. Entretando, muitos aprendem java sem necessáriamente aprofundar sobre OO. Quase sempre por isso, sentirá dificuldade em aprender e aplicar certos pontos sobre Java que estiver nesta situação.

Vejamos então sobre estes últimos modificadores ....

“strictfp”: Palavra reservada que pode ser usada para modificar uma classeou um método, mas nunca uma variável. Marcar uma classe como “strictfp” significa que qualquer código de método na classe será compatível com às regras do padrão IEEE 754 para pontos flutuantes. Sem esse modificador, os pontos flutuantes usados nos métodos poderão se comportar de forma variante conforme a plataforma. Se não declarar a classe como strictfp, ainda assim você poderá obter um comportamento strictfp para métodos específicos, declarando o método como strictfp.

“final”: Define as “Classes Finais” - a palavra-chave “final” significa que a classe em questão não pode ser subclassificada. Ou seja não pode ser estendida, herdada por nenhuma outra. Nenhuma outra classe jamais poderá estender uma classe final. Caso alguém tente fazê-Io receberá um erro de compilação.
Tenha cuiadado ao usar esse tipo de modificados, você só deve marcar uma classe como final se possuir certeza absoluta de que numca vai precisar especializá-la. Nunca nenhum dos métodos dessa classe jamais vai ser sobrescrito.
Por que, então, precisamos marcar uma classe como “final”. Visto que, isso restringe aplicação do conceito de herança presente nas linguagens orientadas a objetos? Suponhamos que o comportamento de sua classe seja profundamente dependente da implementação de certos métodos. Por isso você considere que se esses, certos, métodos forem alterados seja impossível garantir um comportamento adequado a classe. Logo, marcá-la como “final” lhe dará a segurança de que ninguém poderá modificar a implementação dos mesmos sem você saber.
Note que muitas classes das bibliotecas fundamentais Java são declaradas como “final”. Por exemplo, a classe String não pode ser estendida. Não é difícil considerar os riscos caso você não pudesse garantir a forma como um objeto String funcionaria em qualquer sistema que executasse a sua aplicação. Você concorda comigo que, se os programadores tivessem a liberdade de estender a classe String (e assim colocar as suas novas instâncias da subclasse String onde esperam-se instâncias de java.lang.String), dar manutenção em muitos sistemas Java seria a principal causa dos picicóticos maniácos depressivos internados nos centros psquiátricos da vida?
Portanto, use final para segurança, mas apenas quando tiver certeza de que a sua classe final de fato já disse tudo o que precisa ser dito nos seus métodos. Marcar uma classe como final significa, na prática,que a sua classe nunca será especializada para uso mais específico.

Asseguir vamos modificar nosso exemplo anterior colocando a palavra reservada “final” na declaração:

package fermentadosZN;

public final class VinhoZn {
   
     public void fermentar(){}
}

Ok, supondo que tentassemos compilar a subclasse ConhacZn:

package destiladosZN;

import fermentadosZN.VinhoZn;

class ConhacZn extends VinhoZn { }

Então, receberemos um erro tipo:

  Can't subclass final classes: class
  fermentadosZN.VinhoZn class ConhacZn extends VinhoZn{
  1 error}

OBS:

É de extrema importância entender que marcar uma classe como “final” elimina um benefício fundamental da orientação a objeto, a estensibilidade (herança). No dia-a-dia, tipo vida real, você raramente precisará criar uma classe final. Portanto, exceto que você tenha uma séria e justificada razão, presuma sempre que algum dia, em algum momento, outro desenvolvedor poderá precisar estender a sua classe.

abstract: Palavra reservado para marcar classes como “Abstratas”. Uma classe marcada com “abstract” não pode ser instanciada nunca. Isso é a primeira coisa mais importante que você precisa saber sobre classes abstratas. A segunda coisa mais importante sobre elas é que, o seu único propósito, sua principal missão no universo, é ser estendida (Herdada, especialisada, em algumas literaturas encontraremos o termo “subclassificada”). Imagino que alguém possa estar se perguntando: Se posso fazer herança a partir de qualquer classe (exceto as marcadas como “final”), por que preciso de uma classe abstrata? A resposta consiste na mesma idéia envolvida quando, por exemplo, ao nos referirmos sobre um determinado veículo o fazemos usando o termo "Automóvel".
Uma classe abstrata pode ser executada, mas não podemos criar uma instância dela. Caso essa explicação tenha deixado dúvidas procure ler outros artigos onde eu e Felipe explicamos sobre herança.

Outras questões sobre classes abstratas

Repare que você pode compilar e executar uma classe abstrata, desde que não tente criar uma instância dela. Por que criar uma classe se você não pode criar (instanciar) objetos dela? Antes de respondermos, gostaria de chamar a atenção que este entendimento é um elemento chave para quem pretende usar OO em seus projetos. Não acho fácil responder essa pergunta, mesmo assim tentarei apresentar uma linha de raciocínio que possa trazer mais luz sobre essa questão.
Pois bem, prossigamos: Considere um fenômeno comum o qual aplicamos recorrente mente no cotidiano em diversas situações. Esse fenômeno a que me refiro, consiste na capacidade que temos de abstrair ou especializar significados quando estamos nos relacionando com o mundo exterior: Ao tentarmos comunicar alguma mensagem, ou quando estamos do outro lado, interpretando um conteúdo comunicado, ou quando estamos construindo uma idéia sobre alguma coisa e precisamos fazer avaliações e comparações. Entendo que o grande benefício da utilização de classes abstratas, é permitir que possamos “importar” essa flexibilização para perceber significados, usada nos processos cognitivos (construção e interpretação de informações) para a computação (especificamente na construção de programas).
Analisemos uma situação hipotética, um exemplo: Num dado momento ao falar sobre música, uma pessoa, usa o termo “composições” para abstrair detalhes sobre autor, estilo, ou versão:

“Gostaria de conhecer mais sobre as composições musicais no século passado”.

Esse tipo de construção permitiu um grau de abstração grande sobre o significado “Música”. Isso lhe foi bastante útil porque ela poder expressar de forma eficaz seu desejo em conhecer qualquer estilo de música que tenha sido composta no século passado. Entretanto, se ela falar especificamente numa música o termo genérico não encontra significância. Ou seja, não é possível apresentar nenhum exemplo de música onde os detalhes sobre o estilo, gênero, autor, versão sejam ausentes. Por exemplo, em resposta a pergunta sobre uma música que atenda o critério de “composição do século passado” alguém cante “Born to Be Wild”, a resposta traz intrínseca as informações sobre os detalhes que a identificam univocamente como tal.

Outro exemplo, supondo que alguém cite genericamente o significado “veículo”. Logo, podemos presumir podermos contar com alguma outras coisas (atributos e ações), genéricas, comuns a todos os veículos. Como no mundo real não conseguimos encontrar um exemplo qualquer de veículo, pois, seguindo o raciocínio anterior, ao citar o exemplo pedido imediatamente os detalhes sobre ele se revelam exaurindo a generalização embutida na palavra “veículo”, trazendo a existência uma instância detalhada do significado pedido. Portanto, da mesma forma quando programando, definimos uma classe “Veiculo” ela não deve permitir ser instanciada. Pois, definitivamente não desejamos que alguém de fato crie um objeto “Veiculo” genérico. Caso isso não fosse respeitado o primeiro e principal problema encontrado é justamente que o mecanismo de generalização descrito na parágrafo anterior seria perdido. Conseqüentemente teríamos alguns problemas: Como inicializar o seu estado deste objeto “Veiculo”? De que cor ele seria? Quantos assentos? Potência do motor? Direção hidráulica ou não? Ainda, de que forma ele se comportaria? Como os métodos seriam implementados?
Isso demandaria um esforço considerável, o que tornaria o desenvolvimento do seu módulo bastante suscetível implementações confusas. Quando na verdade que você precisa é as instancias de sua classe “Veiculo”sejam tipos reais de carros, como BMW Boxster, ou Nisan 350Z. Observe a seguinte classe abstrata:

abstract class vehicle {
  private double price;
  private String model;
  private String year;
  private String manufacturer;
  public abstract void goFast ();
  public abstract void goUpHill ();
  public abstract void impressNeighbors ();
 // codificar o resto do código importante aqui

}

3)Regras de Declaração para Arquivos-Fontes

Já que estamos tratando de declarações e controles de acesso de classes, julgo então que este é um momento propício para fazermos uma breve revisão das regras pertinentes a declaração de classes, declarações import e declarações de package em um arquivo fonte:

1° - Só pode haver uma classe com escopo de visibilisdade “public” em cada arquivo de código-fonte.

2° - Os comentários podem aparecer no início ou no fim de qualquer linha no arquivo do código-fonte. Eles são independentes de qualquer das regras de posicionamento.

3° - Se houver uma classe pública em um arquivo, o nome do arquivo deve ser o mesmo desta classe . Por exemplo, uma classe declarada como “public class ZnVinho { }” precisa estar em um arquivo de código-fonte chamado “ZnVinho. java.”

4° - Se a classe fizer parte de um pacote, a declaração package deve estar na primeira linha do arquivo do código-fonte, antes de quaisquer declarações import que estejam presentes.

5° - Se houver declarações “import”, elas devem ficar entre a declaração package (se houver) e a declaração da classe. Se não houver uma declaração package, então a(s) declaração(ões) “import” deve(m) estar na(s) primeira(s) linha(s) do arquivo fonte. Se não houver declarações package nem import, então a declaração da classe deve estar na primeira linha do arquivo do fonte.

6° - As declarações import e package aplicam-se a todas as classes dentro de um arquivo fonte. Ou seja, não é possível declarar múltiplas classes em um arquivo e tê-la sem diferentes pacotes, ou usar diferentes importações.

7° - Um arquivo pode ter mais de uma classe não-pública.

8° - Arquivos que não tenham classes públicas podem ter um nome que não seja o mesmo de nenhuma das classesdo arquivo.

Posteriormente, aprofundaremos mais sobre as regras envolvidas com a declaração e o uso de importações, pacotes. Além disso, pretendo falar embreve sobre importações estáticas.

Referência:
SCJP: Certificação Sun para Programador Java 5 - Guia de Estudo