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

Question

I was left with a question when I went to create a project pattern of the type Strategy. It is correct to declare methods GET and SET in a class that implements an interface Strategy? I do not know if I was 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 standards Factory and Strategy:

public class Apartamento extends Imovel implements Strategy {

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

    @Override
    public float getNome() {
        //TODO
    }
}

Answer 1

TL;DR

Not it is necessary to declare getters and setters for no object unless you intend to use them.

That being said, there are several things you need to understand about Java, Object Orientation and the patterns cited in the question in order to understand the answer to the question.

Problems

Strategy and Factory Standards

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

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);
}

Then 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");
    }
}

And as for the Factory pattern, the question example also does not implement it, because there is no method that returns an object.

In the example I put above, the method fazerPizza is a Factory method and it can also be considered that this class implements the Factory standard 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 method getNome in Apartamento tries to overwrite the getNome of Imovel, but the return type changes. This is not possible in Java.

Besides, it doesn’t make much sense to overwrite the method in this case and it will already be inherited by the class Apartamento. Unless, of course, there was something different in the new method, which doesn’t 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 standards in classes that appear to be domain classes, thus generating a hierarchy of types.

It would be better to have its basic types being Pojos, with getters and setters needed, then implement other classes to act as factories and yet other classes to implement algorithms possibly using different strategies. Of course there is an exception for everything, but in general this is how it is done to avoid classes with multiple responsibilities.

Finally, domain classes like Imovel does not necessarily need subtypes for each type of property. This might look nice on the diagram to show the teacher or client, but in practice it’s a maintenance nightmare.

Have an attribute tipo and some optional attributes are usually more than enough to handle small variations unless in the context of your system each type of property is a first-class citizen, that is, it can have distinct business rules and its own track cycle.