How to program according to good OO design practices?

Asked

Viewed 143 times

2

I did this program, simple and nothing complicated. My problem is that although this is doing exactly what I want, it does not follow correct patterns of object-oriented design. What should I do to, for example, end variable statics, extends, gets and sets...?

This is the code I have.

package com.mycompany.exerciciocontadores;

public abstract class Contador {

private String cliente;
private String id;
private double consumo;

private static String CLIENTE_POR_OMISSAO = "sem cliente";
private static String ID_POR_OMISSAO = "sem ID";
private static double CONSUMO_POR_OMISSAO = 0;

public Contador(String cliente, String id, double consumo) {
    this.cliente = cliente;
    this.id = id;
    this.consumo = consumo;
}

public Contador() {
    cliente = CLIENTE_POR_OMISSAO;
    id = ID_POR_OMISSAO;
    consumo = CONSUMO_POR_OMISSAO;
}

public String getCliente() {
    return cliente;
}

public String getId() {
    return id;
}

public double getConsumo() {
    return consumo;
}

public void setCliente(String cliente) {
    this.cliente = cliente;
}

public void setId(String id) {
    this.id = id;
}

public void setConsumo(double consumo) {
    this.consumo = consumo;
}

@Override
public String toString() {
    return "Contador{" + "cliente=" + cliente + ", id=" + id + ", consumo=" + consumo + '}';
}

public abstract double calcularCusto();

}

The subclass:

package com.mycompany.exerciciocontadores;

public class ContadorGas extends Contador {

private static final String PREFIXO = "GAS-";
private static int contador = 0;
private double custoUnitario = 0.8;

public ContadorGas(String cliente, double consumo) {
    super(cliente, PREFIXO + (++contador), consumo);
}

public static int getContador() {
    return contador;
}

public double getCustoUnitario() {
    return custoUnitario;
}

public static void setContador(int contador) {
    ContadorGas.contador = contador;
}

public void setCustoUnitario(double custoUnitario) {
    this.custoUnitario = custoUnitario;
}

@Override
public double calcularCusto() {
    return getConsumo() * custoUnitario;
}

}
  • 6

    And what’s the problem with using static variables, using inheritance, getters and settter? If the resource exists in the language, it is because it can be used, what it cannot use is not knowing what it is doing.

  • @Articuno no problem. if it is a language resource, it should be used but does not follow correct patterns of object-oriented design. , for example, gets and sets in many cases are unnecessaries extends can seriously affect ease of code maintenance

  • 4

    https://answall.com/questions/tagged/orienta%C3%A7%C3%a3o-objetos? Sort=votes&pageSize=50

  • 1

    Where did you read that it doesn’t follow the right standards? Can you show? I’ve never heard anything about it.

  • http://www.oodesign.com/ Here for example or here http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/

  • It doesn’t make much sense to say that gets and sets are not good OO practice, since without them all variables would be public, without encapsulation, this could be a bad practice

  • 2

    @Guilhermecostamilam The question of get and set is the incorrect use of them. Many developers often create get/set methods for all class attributes which is the same as leaving public attributes only using a longer path.

  • 1

    @skidils I think you’ve taken principles to the extreme. Static variables, inheritance and gets/sets are not a bad practice. What the SOLID principles say is that you should consider when using them. Simply removing them from your code will not leave your code with a better design. You have to understand why and in which situations these approaches are not interesting.

  • 2

    Tips: It’s interesting to note that you are returning String for getCliente() instead of returning an object Cliente; you’re also using double to calculate money instead of BigDecimal, and I’m not sure, but it looks like you’re using strings in that code Model that will end up in the GUI. Also put validation code to ensure that the set values will be intact, as @Rogi93 said. Finally, review the Encapsulation (try not to let an external code use the Counter as "puppet", let the Counter itself take care of its logic, operation and integrity).

Show 4 more comments

2 answers

3

The basic part you’ve already done. You can think about whether to use get and set in all attributes because there are things the class shouldn’t change. You may ask why to change the counter id, if you cannot change, you cannot have a set.

Another thing that can change and have a method that increases and maybe one that lowers the counter. Can you let me touch the counter anyway? Can you reset, can you put a high number? And can have a validation as the friend above wrote.

You might want to make consumption protected so you wouldn’t have to call getConsumo.

Ah I remembered that the costUnitario should be Static too.

0

Maybe it’s not exactly what you’re looking for, but a good practice is to use the set method to control the consistency of the data and prevent negative values from being saved where they shouldn’t.

Rather:

public void setConsumo(double consumo) 
{
    this.consumo = consumo;
}

That:

public void setConsumo(double consumoCliente )

     {
         if(consumoCliente >= 0.0)
            consumo = consumoCliente;
         else
           consumo = 0.0;
    }

And about the use of inheritance in your code, honestly I do not see anything out of rule, alias is an excellent practice. An alternative to inheritance would be composition, but there will be repetition of code that is not a good practice.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.