Is it correct to declare GET / SET methods within a STRATEGY class?

Navigation
4

I was left with a question when I created a design pattern of type Strategy . Is it correct to declare methods GET and SET in a class that implements a Strategy interface? I do not know if I was very clear, follow the example:

Strategy : 

public interface Strategy {
    String getNome();
}

Class Imovel : 

public abstract Imovel {
    protected String nome;

    public String getNome() {
        return nome;
    }

    public void setNome(String nome) {
        this.nome = nome;
    }
}

Class using Factory and Strategy patterns: 

public class Apartamento extends Imovel implements Strategy {

    public Apartamento() {
        tipo = "apartamento";
        status = "disponivel";
    }

    @Override
    public float getNome() {
        //TODO
    }
}
    
asked by anonymous 04.12.2015 / 17:20

1 answer

5

TL; DR

No it is necessary to declare getters and setters for any object, unless you want to use them.

That said, there are several things you need to understand about Java, Object Orientation and the patterns quoted in the question so you can understand the answer to the question.

Problems

Strategy and Factory Patterns

The question example does not implement the Strategy pattern. This pattern is that the superclass implements an algorithm and one or more steps of that algorithm are implemented by the subclasses. Just using an interface is not the same as implementing the design pattern.

An example of Strategy: 

abstract class PizzaMaker {
    public Pizza fazerPizza() {
        Pizza pizza = new Pizza();
        adicionarCobertura(pizza);
        Forno.assar(pizza);
        return pizza;
    }
    abstract void adicionarCobertura(Pizza pizza);
}

So you can implement the different strategies of how to cover a pizza.

Example 

class MussarelaPizzaMaker extends PizzaMaker {
    void adicionarCobertura(Pizza pizza) {
        pizza.add("Molho");
        pizza.add("Mussarela");
        pizza.add("Orégano");
    }
}

As for the Factory default, the query example also does not implement it, as there is no method that returns an object.

In the example I put above, the fazerPizza method is a factory method and you can also consider that this class implements the Factory default because each subclass will return a different type of pizza.

So, this example shows how to use the Strategy and Factory patterns together.

Other problems

In your example there are some errors and problems.

For example, the getNome method in Apartamento tries to overwrite the getNome of Imovel , but the return type changes. This is not possible in Java.

In addition, it does not make sense to override the method in this case since it will already be inherited by the Apartamento class. Unless, of course, there was something different about the new method, which does not seem to be the case.

A conceptual problem with the example is that it does not seem very reasonable to apply the Strategy and Factory defaults to classes that appear to be domain classes, thus generating a hierarchy of types.

It would be better to have your basic types being POJOs, with getters and setters required, then implement other classes to act as factories and still other classes to implement algorithms possibly using different strategies. Of course there is an exception for everything, but this is usually done to avoid classes with multiple responsibilities.

Anyway, domain classes like Imovel do not necessarily need subtypes for each type of property. This can look beautiful on the diagram to show the teacher or client, but in practice it is a maintenance nightmare.

Having a tipo attribute and some optional attributes is usually more than enough to deal with small variations unless in the context of your system each type of property is a first class citizen, that is, it can have rules of businesses and a cycle of their own.

    
07.12.2015 / 04:16
SQL count and sum How to check if my current time is in a time interval?