R.Campo

O R.Campo é uma aplicação desenvolvida pela Ruralbit que permite registar dados no campo e posteriormente fazer a sua sincronização com várias plataformas. – Site Oficial R.Campo

Fui responsável pela desenvolvimento duma aplicação Web RCampo-BO que contém as seguintes funcionalidades:

  1. gestão de entidades, tipo de registos, utilizadores, validações e planos
  2. criação de relatório de dados usando a filtragem e agrupamento de campos pretendidos tais como mês, ano, exploração, utilizador, criador e tipo.

Strategy Pattern

Strategy – defines a family of algorithms, encapsulates each one, and makes them intercangeable. Strategy lets the algorithm vary independently from clients that use it. – Page 24, Chapter 1, Head First Design Patterns

Em português, Strategy Pattern define uma família de algoritmos, encapsulando cada um deles e tornado-os permutáveis. Este design pattern permite variar o algoritmo independentemente das classes que usam-o.

Strategy Pattern
Strategy Pattern

Para compreender melhor a interpretação do diagrama de classes, considere as seguintes exposições:

  • Strategy: declara uma interface comum para todos os algoritmos. A classe Context usa esta interface para chamar o algoritmo definido por um ConcreteStrategy.
  • ConcreteStrategy: implementa o algoritmo usando a interface Strategy.
  • Context: é configurado com um objecto ConcreteStrategy. Mantém a referência para um objecto Strategy e deve definir métodos para permitir Strategy aceder aos seus dados.

Amostra de código da classe “Strategy”
Nota: Tanto pode ser uma interface como uma classe abstracta com método(s) abstracto(s)

public interface FlyBehavior {
    public void fly();
}

Amostra de código da classe “ConcreteStrategy”

public class FlyRocketPowered implements FlyBehavior{

    public void fly() {
        System.out.println("I am flying with a rocket!");
    }

}

Amostra de código da classe “Context”

public class DuckTestDrive {
    public static void main(String[] args) {
        
        Duck model = new ModelDuck();
        model.display();
        model.performFly();
        model.setFlyBehavior(new FlyRocketPowered());
        model.performFly();
    }
}

Quando se deve usar a Strategy Pattern?

  1. Quando muitas classes diferem apenas no seu comportamento. Assim este design pattern fornece uma maneira de programar uma classe com vários tipos de comportamento.
  2. Quando se pretende evitar expor algoritmos complexos e/ou dados sensíveis à estrutura da classe.
  3. quando se pretende evitar o uso excessivo das declarações condicionais (if…else ou switch)

As conclusões que eu retiro deste design pattern são:

  • A herança oferece uma maneira de suportar um variedade de algoritmos ou comportamentos. Mas, ao criar subclasses Context, torna-se mais difícil de trabalhar porque mistura os algoritmos das superclasses e das subclasses e não há hipótese de variar algoritmos dinamicamente. Encapsular o algoritmo na classes Strategy, separadamente, permite modificar o algoritmo independentemente da classe Context, tornado-se assim mais fácil de mudar, compreender e criar subclasses.
  • Oferece alternativa às declarações condicionais (if…else e/ou switch) ao escolher um determinado comportamento.
  • Strategy Pattern pode oferecer diferentes implementações para o mesmo comportamento.

Design Patterns

Design Patterns são as soluções optimizadas e reutilizáveis para os problemas de programação que surge no nosso dia de trabalho.

Um design pattern é um caminho especifico para a resolução dum determinado problema. Não se trata da reutilização de código mas sim da reutilização de ideias; são mais abstractos e generalizados.

Revisão de Programação Orientada por Objectos

Fazendo a revisão do estudo dos conceitos de Programação Orientada por Objectos, posso concluir:

  1. A diferença entre uma interface e uma classe é o facto da interface não possuir código executável e a classe possuir código executável;
  2. A diferença entre classe abstracta e concreta é o facto da classe abstracta de ter alguns métodos que não possuem código executável;
  3. A diferença entre classe abstracta e interface é o facto da interface de todos os seus métodos não possuem código executável e além disto, a interface usa a keyword implements e a classe abstracta usa a keyword extends;
  4. A finalidade duma classe abstracta é reduzir a redundância de código que é comum a todas subclasses.