Model Locator Contra a OOP

O Cairngorm é saudado como o principal Framework para as RIAs feitas em Flex. Mas todo Framework tem seu lado bom e ruim. O lado bom é a produtividade e a flexibilidade; o lado ruim é a dependência e má utilização de alguns Patterns. O presente texto pretende mostrar como o Model Locator (um dos Patterns do Cairngorm) pode levar a um projeto que viola dois princípios chave da Orientação a Objetos: Encapsulamento e Divisão de Responsabilidade. A sua tarefa é desenvolver um Shopping Virtual em Flex. O usuário poderá adicionar produtos em sua Wish List. Então, você cria uma variável wishItens no Model Locator e mais três métodos para controlar os itens da sua lista.

class MyModelLocator implements ModelLocator {public static var wishItens :Array;public static function addToWisthList(item:Object): Void {

// adiciona se ele ainda não estiver na lista
var index:Number = searchItem(item);
if (index == -1) {
wishItens.addItemAt(0, item);
}

}

public static function removeFromWisthList(index:Number): Void {

// remove o item se ele estiver na lista
var index:Number = searchItem(item);
if (index == -1) {
wishItens.removeItemAt(index);
}

}

public static function searchItem(item:Object): Void {
// retorna o indíce o item caso ele seja encontrado ou // -1 caso contrário }

}

O primeiro grande erro é criar métodos no Model Locator. O Model Locator deve ser apenas um ponto de acesso em comum para o seu aplicativo. No Flex isto pode ser muito útil devido à possibilidade de usar o Data Binding nos Views de modo que qualquer alteração no Model Locator possa ser refletida automaticamente. O grande problema é que o Model Locator é a mesma coisa que as várias globais da programação procedural e, como tal, possui um grande potencial para destruir o encapsulamento e prejudicar a divisão de responsabilidade. No exemplo acima, o Model Locator, que deveria ser apenas um ponto de acesso em comum, é responsável por controlar os itens da Wish List. Se você está achando o exemplo obvio demais (ninguém faria isto?) imagine que no mesmo Shopping Virtual você precisa oferecer alguma espécie de paginação para os produtos. Então, a primeira coisa que vem a sua cabeça é usar o Model Locator para controlar a paginação.

class MyModelLocator implements ModelLocator {public static var currentPage:Number=0;public static function nextPage(): Void {
currentPage++;
}

public static function prevPage(index:Number): Void {
currentPage–;
}

}

Olha o Model Locator novamente fazendo mais coisa do que deve. Quem disse que é responsabilidade do Model Locator controlar a paginação? Onde está especificado isto na motivação do Pattern? Portanto, como regra geral NÃO crie métodos no Model Locator. Se você cria um método para a funcionalidade A no Model Locator, depois provavelmente criará para a funcionalidade B e assim por diante. O que é isto? Mistura de reponsabildade. O Model Locator é responsável pela funcionalidade A, B, C, etc. Um exemplo menos gritante desta mistura de responsabilidade ocorreria se você apenas definisse a variável “currentPage” no Model Locator e incrementasse e decrementasse o seu valor a partir de outras classes no seu código. Isto levaria, do mesmo modo, a um projeto com má divisão de responsabilidade e mal encapsulado – porque estas outras classes teriam que saber como incrementar e decrementar o valor de “currentPage”. Além disso, o Model Locator inerentemente já prejudica o encapsulamento devido ao extenso uso que faz de propriedades públicas estáticas. Portanto, tente manter o seu Model Locator o menor possível. A solução para estes exemplos de má utilização do Model Locator é aplicar a Refatoração Extract Class.

É preciso tomar muito cuidado também para não sobrevalorizar o Cairngorm. Vale lembrar sempre que esta foi a primeira boa iniciativa para definir uma Micro-Arquitetura para as Rich Internet Applications feitas em Flex.

Model Locator Contra a OOP

Deixe Seu Comentário