Criação de campos de Status

Artigo que apresenta uma abordagem sobre como proceder com a criação de campos de status em modelagens de estruturas de dados.

Introdução

Campos de "status" são campos que guardam a situação de determinada entidade em determinado contexto. Eles são muito comuns em modelagens de bancos de dados e estruturas de dados em geral para ajudar a arquitetar soluções e processos computacionais. Embora pareça algo muito simples, existem alguns problemas e observações que podem ser feitas sobre o assunto. Neste artigo vamos ver sobre elas.

Contextualização

A maioria dos sistemas possuem entidades com status, que representa a situação delas em determinado momento para determinado contexto. É comum, por exemplo, se guardar um status para os usuários do sistema para determinar quais estão ativos ou inativos e aplicar uma regra específica para cada uma das situações (não permitir a autenticação, por exemplo).

Possíveis problemas

Um dos maiores problemas relacionados a campos de status é o seu uso indiscriminado com a criação de novos possíveis valores sem planejamento.

Vamos a um exemplo: você começa a montar um sistema simples, onde os usuários podiam ter apenas as situações: "pendente", "ativo" e "inativo". Tudo está funcionando lindamente e existem vários pontos do sistema em que você precisa checar o status do usuário para bloquear ou permitir determinadas ações, ou então checar o status para gerar relatórios, etc. Em determinado momento, surge um nova demanda e você pensa imediatamente em adicionar o novo status "ativo pagante". Talvez você até consiga ajustar todos pontos do sistema que utilize o status naquele momento, que pode dar um trabalhão, mas o problema maior é outro. No futuro, sempre que você precisar fazer qualquer ferramenta que tenha influência do status, vai ter que tratar os vários possíveis valores que aquele campo pode assumir. Ou seja, onde antes você só precisava checar se o usuário está "ativo" ou não, agora vai precisar checar se ele está "ativo" ou "ativo pagante".

Note que este exemplo é um que pode causar problemas futuros. Porém, cada caso deve ser analisado individualmente. Podem existir situações em que a criação de novos possíveis valores não impacte em nada no sistema pois não se trata de um campo muito usado.

Soluções

Agora que entendemos o problema da criação de novos valores para campos de status, vamos ver algumas soluções.

Opção 1: Defina um contexto bem definido

Criar contextos bem definidos para os campos de status é uma solução que prioriza manter os campos de status com o menor número de possíveis valores, de forma que atendam a um contexto bem definido.

No exemplo que vimos acima, ao criar a situação "ativa pagante" estamos misturando dois contextos: (1) a situação de atividade do usuário e (2) o tipo de conta do usuário (pagante ou gratuito).

Ou seja, para solucionar o problema do exemplo, criaríamos dois campos distintos, cada um resolvendo um contexto: um para o status de atividade e outro para o tipo de conta (pagante ou gratuita). Observe que, ao fazer isso, você não precisa mudar todo o sistema. Basta que as ferramentas que precisem saber sobre o tipo de conta consultem o campo apropriado, enquanto as outras ferramentas que precisem saber sobre o status de atividade do usuário consultem o outro campo mais apropriado.

Pelas minhas experiências pessoais, creio que esta seja a solução mais adequada para a maioria dos casos.

Opção 2: Encapsule as lógicas de negócio

Esta solução consiste em encapsular as lógicas de negócio para que sejam modificadas em um único ponto do sistema. No exemplo citado, poderia ser criado um método "usuarioAtivo", que inicialmente só retornaria se o usuário possui o status "ativo" ou não. Com a criação de novos valores possíveis para o status, o método seria alterado para retornar true se o usuário é "ativo" ou "ativo pagante". Desta forma, se todos pontos do sistema utilizarem corretamente o método, apenas um local do sistema será alterado.

Esta solução, embora resolva bem a maioria dos casos, não me parece a ideal, pois ainda estariam sendo armazenadas duas ou mais informações em um único campo.

Opção 3: Utilize máscaras binárias

Já falamos no blog sobre Máscaras Binárias. A solução de criação de status com máscaras binárias é definindo conjuntos de valores que utilizam um bit comum.

No caso do exemplo acima, poderíamos reservar o 4º bit como sendo uma flag que indica se o usuário é pagante ou não, então teríamos os possíveis valores:

Tabela de valores para o campo status
Valor Descrição Binário
1 Ativo 00000001
2 Pendente 00000010
4 Inativo 00000100
9 Ativo/Pagante 00001001
10 Pendente/Pagante 00001010
12 Inativo/Pagante 00001100

Para checar se um usuário é "Ativo" (independente se é pagante ou não), basta usar o operador "E" binário:

define('STATUS_ATIVO',    1);
define('STATUS_PENDENTE', 2);
define('STATUS_INATIVO',  4);
define('STATUS_PAGANTE',  8);

if ($status & STATUS_ATIVO) {
    ...
}

Uma forma simples de checar se o usuário é "Ativo" e também "Pagante" seria assim:

if (($status & STATUS_ATIVO) && ($status & STATUS_PAGANTE)) {
    ...
}

Soluções usando máscaras binárias são mais indicadas quando a quantidade de campos não pode ser aumentada por algum motivo forte. Porém, ela exige maior planejamento.

5 comentários

Rubens Takiguti Ribeiro (autor do blog) disse...

Olá, Beatriz
Para criar círculos, o princípio é colocar border-radius 50%, conforme mostrado neste artigo:
http://rubsphp.blogspot.com.br/2014/04/criando-bolas-e-circulos-com-css.html

Rubens Takiguti Ribeiro (autor do blog) disse...

Olá, Beatriz
Não entendi o que quis dizer com slide. Você se refere ao efeito ao parar o mouse sobre uma imagem? Se for isso, basta usar CSS transitions:
http://rubsphp.blogspot.com.br/2011/03/css-transitions.html