Continuando com os meus estudos, falo agora de mais um ponto que a certificação Flex 3 vai englobar, as interfaces, falo das “definições de class” como interface.
Na programação Orientada a Objecto, uma interface é um tipo de documento action script que permite declarar (não de definir) os métodos (funções) de algum tipo de class. Este tipo de declarações torna-se muito util já que permite separar a interface da implementação o que em projectos medios-grandes com uma equipa de programadores torna muito versátil as nossas classes.
O principal objectivo das interfaces é permitir ao programador identificar as funções que fazem parte de uma ou mais classes, sendo uma referencia às mesmas.
De uma forma geral, imaginemos que temos 20 funções distribuidas por 3 classes dentro do mesmo package, uma interface vai permitir o seguinte:
- Resumo de todas as funções num unico ficheiro (interface)
- Localização rápida de determinada função na nossa class
- Observação do tipo de parametros recebidos e devolvidos pelas funções
- Facil identificação para um grupo de programadores com vista à implementação dos métodos de uma class/interface.
Uma interface não se comporta como uma class. Sendo identificada pelas seguintes propriedades:
- Usam a palavra interface como declaração em vez da palavra class
- Não permitem a declaração de propriedades
- Os métodos (funções) identificam a assinatura (função) e seus parametros mas não a implementação da mesma
- Declaram apenas a interface como public para implemetação das classes, e por isso as funções declaradas não suportam “modifiers” (public, private, protected, etc…)
As interfaces podem ser usadas para atribuir um tipo de dados a dados existentes, ou seja, podem ser usadas para difinir um tipo de dados de uma variavel. Podem também ser consideradas um “contracto de programação” destinado a impor relações entre varias classes e varios programadores, tomando como exemplo uma equipa de programadores que trabalham em varias classes do mesmo projecto, a interface prédefinida faz com que não exista abstração do código e que todos os programadores, independentes um do outro, tenham conhecimento das varias classes e devidas funções. Toda a class implementada a partir da interface deve indicar as definições para os seus métodos, para que estes dados possam ser enumerados e identificados na interface para conhecimento publico de toda a aplicação e programadores. A interface comporta-se com um protocolo de comunicação a que todas as classes devem aderir e possibilitar a sua enumeração na interface.
Por convenção (não obrigatóriamente) o nome das interfaces começam por letra maiuscula, vejam o exemplo:
public interface IExample {
function a():String;
function b(one:String, two:uint):void;
}
}
Esta estrutura indica que todas as classes que implementem a interface devem obrigatóriamente declarar as funções/métodos a() e b() com as devidas propriedades a():String e b(one:String, two:uint).
Numa implementação desta interface:
import com.example.IExample;
public class Example implements IExample {
public function Example() {
}
public function a():String {
return "a";
}
public function b(one:String, two:uint):void {
trace(one + " " + two);
}
}
}
devem ser definidos os pontos seguintes:
- Package, a que package essa class/interface pertencem
- Importação da interface a implementar ( import com.example.IExample )
- Descrição de acesso ( public class ), nome ( Example ) e declaração de implementação ( implements IExample )
- Construtor e acesso da class ( public function Example() )
- Métodos (funções) nativas da interface ( a() e b() ) com as devidas propriedades identificadas na interface.
- Podem ser declaradas mais funções (métodos) mas os métodos identificados na interface ( a() e b() ) devem sempre ser definidos ou caso contrario será disparado um erro pelo compilador.
Uma interface pode também ser extendida por outra interface, com herança de métodos, vejam:
interface Ia {
public function f1():Void;
public function f2():Void;
}
}
criando uma interface que extende esta anterior:
interface Ib extends Ia {
public function f8():Void;
public function f9():Void;
}
}
No caso de uma class que implemente a interface Ia, já visto em cima o seu funcionamento, mas no caso de uma implementação da interface Ib deve-se ter alguma atenção na implementação, visto que a interface Ib herdou os métodos f1() e f2() sendo que na class devem estar presentes os 4 métodos:
import com.example.Ib;
public class ClassExemplo implements Ib {
public function ClassExemplo() {
}
// métodos f1() e f2() que pertencem á class pai, métodos herdados ao extender a interface Ia
public function f1():Void {
}
public function f2():Void {
}
// métodos f8() e f9() que foram métodos adicionados na inetrface Ib
public function f8():Void {
}
public function f9():Void {
}
}
}
Uma unica class pode extender mais que uma unica interface, sendo que os métodos de ambas devem ser todos enumerados nessa classe, vejam o exemplo da interface IExample e Ia e a class seguinte que implementa ambas:
import com.example.Ib;
public class ClassExemplo implements Ia, IExample {
public function ClassExemplo() {
}
// métodos f1() e f2() que pertencem á interface Ia
public function f1():Void {
}
public function f2():Void {
}
// métodos a() e b() que pertencem é interface IExample
public function a():String {
return "a";
}
public function b(one:String, two:uint):Void {
trace(one + " - " + two);
}
}
}
Como podem ver é bem simples o uso de interfaces, e se em projectos pequenos e com fins pessoais ou apenas com um programador o uso de interfaces pode não fazer sentido, em projectos maiores com uma equipa de programadores é algo imprescindivel para que ninguém se perca no código e que cumpram as estruturas de classes devidamente.
Referencias:
http://flexblog.faratasystems.com/
http://www.adobe.com/devnet/actionscript/
Livros:
o’reilly’s essential actionscript 3.0
Bom, espero que seja util…
Alguém tem algo a acrescentar? deixe um comentário que eu agradeço! :=)
12 Comentários
Bom demais! Valeu!
Grande Mário … legal o post bem interessante mas me diz uma coisa: porque imagens em lugar de código escrito ??
Ps.: vai passar as festas por aqui é ?
Abraço
Valeu Ved!
Villas, está com imagens porque estava testando um plugin do wordpress para código action script do wordpress, mas nada feito… vou continuar com a plugin antiga….
Aí está isso corrigido.
Quanto às ferias, vou mesmo pro brasil!
Mais um excelente tutorial, parabéns.
Mario sobre o código, tenta este plugin (eu gosto !)
http://wordpress.org/extend/plugins/syntaxhighlighter/screenshots/
Abraço
Ola mario, no meu comentario anterior citei o padrão mvp ond um dos principais pontos e o uso d interfaces para a interação enter o controler e a view.
Se seguir este link vera 1 exemplo deste padrão feito por mim baseado num post do Giorgi(US)
Http://189.44.248.77/AgendaMVP
Villas, eu tenho um plugin que suporta actionscript, como pode ver agora pelo códio em cima, foi uma questão de testes, estava a tentar que ao clicar na imagem aparecesse o código…mas acho que vou continuar com essa plugin.
sivoleu, quanto ao mvp, não estou muito familiarizado com ele, mas andei à procura e encontrei um post bem interessante, veja:
http://www.mxml.it/index.php/2008/09/09/introduction-to-mvp-for-flex/
Abraços.
Ola mário, é baseado neste post que fiz meu projeto test, baseado nesse padrão…
corrigindo link:
…AgendaMVP.rar
Caso o link falhe motivo = meu pc desligado, ok?
Bom dia, ótimo artigo para quem queria conhecer sobre Interfaces.
Eu tenho um problema caso você consiga uma solução seria de grande valia.
Trabalhando com orientação a eventos, imagina eu ter 3 telas abertas que seriam “alimentadas” por uma consulta comum. Gostaria de criar um evento de disparo que alimentasse as 3 telas. Em java fazemos isso usando interface e passando a referencia das classes “ouvintes” para uma de controle. Como você trataria tal situação?
Walber, uma das (a mais facil) será você criar uma class singlton que guarda os dados dessa consulta comun, declarando a variavel com os seus dados como [Bindable], sendo que depois nas suas 3 telas basta importar a instancia da class singleton e usar os dados.
Veja os posts aqui do blog:
http://msdevstudio.com/blog/2009/02/25/as3-singleton-conceito-e-exemplo/
http://msdevstudio.com/blog/2009/03/02/as3-dynamic-singleton-classes-dinamicas/
Vai facilmente encontrar a sua solução.
Abraço.
Muito bacana a abordagem de interfaces, parabéns pelo artigo.
Tutorial mais claro que esse ainda não achei, me corrija(m) se eu estiver errado, as Interfaces então servem “apenas” para uma documentação, uma forma de organizar os pacores e classes… ou tem algo nelas que podem ir além disso?