Padr˜ ao Bridge - PADRÕES DE PROJETO EM OOERLANG UNIVERSIDADE DO ESTADO DO AMAZONAS

De acordo com sua defini¸cão, o padrão Bridge tem por finalidade: “Desacoplar uma abstra¸cão de sua implementa¸cão para que os dois possam variar independentemente” [Gamma et al., 1994]. Em situa¸cões nas quais podem existir vários tipos diferentes de abstra¸cões, assim como diversas implementa¸cões, a ado¸cão e aplica¸cão deste padrão facilita a manuten- ¸cão do código-fonte, assim como a extensão, pois facilita o acréscimo de novas abstra¸cões, sem impactar o projeto como um todo.

Quando se necessite, por exemplo, selecionar ou modificar uma implementa¸cão em tempo de execu¸cão, deve ser necessário evitar uma liga¸cão forte entre esta implementa¸cão e sua referente abstra¸cão. Neste caso a utiliza¸cão do padrão Bridge torna-se necessária. Também pode ser verificado que, ao separar uma abstra¸cão de sua implementa¸cão, qualquer mudan¸ca que se fa¸ca na implementa¸cão não irá afetar sua respectiva abstra¸cão, facilitando assim a manuten¸cão do fonte.

4.3.1 Exemplo utilizado para este padr˜ao

Para exemplificar a utiliza¸cão do padrão de projetos Bridge, é utilizado um exemplo retirado de [Kulandai, 2012], no qual é modelada uma fábrica que produz dois tipos principais de meios de transportes: carros e bicicletas. Além destes dois produtos, existem duas formas com as quais é poss´ıvel fabricá-los: produzindo por meio de maquinário fabril e montando de forma manual. Ou seja, existem dois tipos diferentes de produtos e cada produto possui duas formas diferentes de fabrica¸cão.

A classe que representa o produto “carro” possui o nome Car, e a classe que representa o produto “bicicleta” está designada como Bike. A fabrica¸cão por meio de processos automatizados da fábrica possui uma classe com o nome Produce, e a fabrica¸cão manual tem sua classe, chamada Assemble. Além destas classes, o cenário possui uma classe ge- ral dos ve´ıculos, chamada Vehicle, que é herdada por ambos os produtos fabricados. A figura 4.4 mostra um diagrama de classes para melhor entendimento do cenário. As classes sobrepostas possuem implementa¸cão similar às classes que as sobrepõem.

Como pode ser observado, o padrão Bridge já está sendo utilizado. De acordo com este padrão , o objetivo principal é o de separar uma abstra¸cão de sua implementa¸cão. Neste caso espec´ıfico, as abstra¸cões são os tipos de produtos e as implementa¸cões são as formas com as quais cada um desses produtos são fabricados. Existe um desacoplamento entre os produtos e seus tipos de fabrica¸cão.

Caso este padrão não estivesse sendo utilizado, uma solu¸cão que poderia vir a ser usada seria a de criar a classe Vehicle sendo herdada pelos dois tipos de ve´ıculos. Em seguida, cada ve´ıculo estaria associado com ambos os métodos de fabrica¸cão. Desta forma haveria duplica¸cão de códigos, pois para cada ve´ıculo haveriam duas classes Produce e duas classes

Padrão Bridge 70

Figura 4.4: Diagrama de classes do exemplo para o padr˜ao Bridge.

Assemble. As classes estariam fortemente acopladas e se fosse necess´ario incluir um novo tipo de produto, haveria grande impacto e retrabalho no projeto.

Porém, neste caso, foi implementado um desacoplamento entre os tipos de ve´ıculos e suas formas de fabrica¸cão. Por meio da interface Workshop, referente às formas de fabrica¸cão, a duplica¸cão de códigos foi evitada e se for necessário inserir novos ve´ıculos ou novas formas de fabrica¸cão, isto não acarretará grandes problemas ao projeto como um todo.

4.3.2 Compara¸c˜ao das implementa¸c˜oes em Java e ooErlang

As classes mostradas no diagrama referente à figura 4.4 foram todas implementadas em ooErlang, tendo-se em vista que a implementa¸cão em Java foi retirada de [Kulandai, 2012]. Observadas e ressalvadas as relativas peculiaridades na sintaxe de cada uma das linguagens, as implementa¸cões em ooErlang apresentam-se semelhantes às mostradas em Java. Os códigos observados em 4.3.1 e 4.3.2 revelam a implementa¸cão da classe Bike em Java e ooErlang, respectivamente.

1 public class Bike extends Vehicle { 2

3 public Bike(Workshop workShop1, Workshop workShop2) { 4 super(workShop1, workShop2);

5 }

7 public void manufacture() { 8 System.out.print("Bike "); 9 workShop1.work(); 10 workShop2.work(); 11 } 12 13 }

C´odigo 4.3.1: Classe Bike em Java

1 -class(bike). 2 -extends(vehicle). 3 -export([new/2, manufacture/0]). 4 -constructor([new/2]). 5 6 methods. 7 8 new(WorkShop1, WorkShop2) -> 9 self::WorkShop1 = WorkShop1, 10 self::WorkShop2 = WorkShop2. 11 12 manufacture() -> 13 io:format("Bike "), 14 Work1 = self::WorkShop1, 15 Work2 = self::WorkShop2, 16 Work1::work(), 17 Work2::work().

C´odigo 4.3.2: Classe Bike em ooErlang

implementa¸cões da classe Car, por isso apenas o fonte da classe Bike é mostrado. Deve-se observar que cada objeto da classe Bike recebe como parâmetro duas formas de fabrica¸cão, referente às duas maneiras com que pode ser produzido. Assim como a classe Car, a classe Bike herda os atributos e métodos da classe Vehicle.

Analisando os códigos da classe Assemble, mostrados em 4.3.3 e 4.3.4 (Java e ooErlang respectivamente), pode-se notar que esta classe implementa o método work(), presente na interface Workshop. Isto ocorre de forma semelhante com o fonte da classe Produce. A utiliza¸cão da interface Workshop é o ponto fundamental de aplica¸cão do padrão Bridge neste exemplo, possibilitando separar os objetos de suas relativas formas de fabrica¸cão.

Padrão Bridge 72

1 public class Assemble implements Workshop { 2

3 public void work() {

4 System.out.println(" Assembled.");

5 }

6 }

C´odigo 4.3.3: Classe Assemble em Java

1 -class(assemble). 2 -implements(workshop). 3 -export([work/0]). 4 5 methods. 6 7 work() -> 8 io:format(" Assembled. ~n").

C´odigo 4.3.4: Classe Assemble em ooErlang

A classe Vehicle possui dois atributos, relacionados com os dois tipos de fabrica¸cão dos ve´ıculos da fábrica utilizada no exemplo. Os métodos desta classe são um construtor, que apenas instancia um objeto, dependendo da classe principal (BridgePattern) e o método abstrato manufacture(), que é implementado nas classes Bike e Car.

Em rela¸cão à classe principal, BridgePattern, para testar a utiliza¸cão do padrão Bridge, são instanciados dois objetos, um do tipo Car e outro do tipo Bike. Para cada um destes, ´

e passado como parâmetro de constru¸cão os dois distintos modos de fabrica¸cão de um ve´ıculo. Em seguida é utilizado o método manufacture(), que é implementado em cada um dos ve´ıculos, e realiza a fabrica¸cão do ve´ıculo das duas formas existentes. A implementa¸cão desta classe está mostrada nos códigos em 4.3.5 e 4.3.6.

1 public class BridgePattern { 2

3 public static void main(String[] args) { 4

5 Vehicle vehicle1 = new Car(new Produce(), new Assemble()); 6 vehicle1.manufacture();

7 Vehicle vehicle2 = new Bike(new Produce(), new Assemble()); 8 vehicle2.manufacture();

9 }

10 }

1 -class(bridgePattern). 2 -export([main/0]). 3 4 class_methods. 5 6 main() ->

7 Vehicle1 = car::new(produce::new_(), assemble::new_()), 8 Vehicle1::manufacture(),

10 Vehicle2 = bike::new(produce::new_(), assemble::new_()), 11 Vehicle2::manufacture().

C´odigo 4.3.6: Classe principal BridgePattern em ooErlang

Assim para ambos os ve´ıculos, os dois métodos de fabrica¸cão são testados. Percebe-se assim que, dependendo da necessidade do sistema, poderiam ser inclu´ıdos novos ve´ıculos e eles já poderiam possuir as duas formas de fabrica¸cão que já existem, sem necessidade de alterar nenhum código em qualquer outra classe de ve´ıculos. O mesmo é valido em uma situa¸cão em que fosse necessário retirar de fabrica¸cão algum tipo de ve´ıculo. As figuras 4.5 e 4.6 mostram a execu¸cão deste exemplo em Java e ooErlang.

A extensão do Erlang para orienta¸cão à objetos, ooErlang, mostrou poder ser utilizada na implementa¸cão de fontes similares aos fontes utilizados no exemplo mostrado para o padrão Bridge. Este padrão estrutural é bem aplicado em situa¸cões onde seja necessário variar as implementa¸cões distintamente de suas abstra¸cões.

Com a aplica¸cão deste padrão de projeto, é poss´ıvel perceber que a inser¸cão e/ou exclusão de novos ve´ıculos na fábrica utilizada neste exemplo, não iria ocasionar um grande impacto no projeto como um todo. Similarmente, se fosse necessário incluir novas formas de fabrica¸cão de ve´ıculos, ou retirar alguma forma já existente, também não haveriam impactos no projeto inteiro.

As principais consequencias provindas da utiliza¸cão deste padrão de projetos podem ser citadas como sendo o desacoplamento de uma interface com uma implementa¸cão (elimi- nando dependências), melhoramento da extensibilidade do fonte em rela¸cão às hierarquias de abstra¸cão e implementa¸cão (tornam-se independentes), e a caracter´ıstica de encapsula- mento deste padrão, que não mostra ao usuário detalhes da implementa¸cão que não são do interesse do mesmo.

Padrão Composite 74

Figura 4.5: Execu¸c˜ao do exemplo para o padr˜ao Bridge em Java.

No documento PADRÕES DE PROJETO EM OOERLANG UNIVERSIDADE DO ESTADO DO AMAZONAS - UEA. Manaus ESCOLA SUPERIOR DE TECNOLOGIA ENGENHARIA DE COMPUTAÇÃO (páginas 88-94)