O que é mais apropriado: getters e setters ou funções?

Question

É sempre apropriado para abandonar o "getMyValue ()" e "setMyValue ()" padrão de getters e setters se nomes de funções alternativas fazer a API mais óbvio?

Por exemplo, imagine eu tenho essa classe em C ++:

public class SomeClass {
private:
    bool mIsVisible;

public:
    void draw();
    void erase();
}

Eu poderia adicionar funções para obter / set "mIsVisible" como esta:

bool getVisible() { return mIsVisible; };


void setVisible(bool visible) { 
    if (!mIsVisible && visible) {
        draw();
    } else if (mIsVisible && !visible) {
        erase();
    }

mIsVisible = visible;


}

No entanto, seria igualmente possível utilizar os seguintes métodos em vez disso:

bool isVisible() { return mIsVisible; };

void show() { 
    if (!mIsVisible) {
        mIsVisible = true;
        draw();
    }
}

void hide() {
    if (mIsVisible) {
        mIsVisible = false;
        erase();
    }
}

Em resumo, é melhor ter um "setVisible (bool)" método único, ou um par de "show ()" e "hide ()" métodos? Existe uma convenção, ou é puramente uma coisa subjetiva?

Answer 1

Ter uma leitura do artigo " Diga, não pergunte " sobre a Pragmatic Programmers web site e eu acho que você verá que o segundo exemplo é o caminho a percorrer.

Basicamente, você não deve estar se espalhando a lógica por meio de seu código que está implícito com o primeiro exemplo, a saber:

1. obter o valor de visibilidade atual,
2. fazer a decisão com base no valor,
3. atualização objeto.

Answer 2

No exemplo que você deu, show() e hide() fazer um monte de sentido, pelo menos para mim.

Por outro lado, se você tivesse um skinPigment propriedade e você decidiu fazer funções chamado tanMe() e makeAlbino() que seria realmente uma má escolha, não óbvia.

É subjetivo, você tem que tentar pensar a maneira que seus usuários (as pessoas que utilizam esta classe) pensar. Independentemente da forma como você decidir, deve ser óbvio para eles, e bem documentado.

Answer 3

Eu iria com o isVisible () / show () / hide () set.

setVisible () implica que tudo o que isso muda a variável interna. show () e hide () fazer os efeitos colaterais claro.

Por outro lado, se tudo getVisible () / setVisible () fez foi para alterar a variável interna, então você apenas mudou notavelmente pouco de tê-los como campos públicos.

Answer 4

setters realmente tem muito pouco a ver com a orientação a objetos, que é a linguagem de programação aplicada no exemplo. getters são marginalmente melhor, mas pode ser vivida sem em muitos casos. Se tudo pode ser obtido e definir, qual é o ponto de ter um objeto? As operações devem ser chamados em objetos para realizar coisas, mudando o estado interno é apenas um efeito colateral deste. A única coisa ruim sobre um setter na presença de polimorfismo - um dos pilares de OO - é que você forçar cada classe derivada de ter um setter. E se o objeto em questão tem nenhuma necessidade para um estado interno chamado mIsVisible? Claro que ele pode ignorar a chamada e implementar como vazio, mas então você é deixado com uma operação sem sentido. OTOH, operações como show e esconder pode ser facilmente substituído com diferentes implementações, sem revelar nada sobre o estado interno.

Answer 5

Em geral, eu acho que setters / getters só deve definir os valores das propriedades. No seu exemplo, você também está realizando uma ação com base no valor da propriedade isVisible. Neste caso, eu diria que o uso de funções para executar a ação e atualizar o estado é melhor do que ter um setter / getter que realiza uma ação como um efeito colateral de atualizar a propriedade.

Answer 6

Se a mudança mIsVisible realmente transforma a visibilidade do objeto ligado e desligado imediatamente, do que o uso do show / hide cenário. Se ele vai ficar no estado de idade um pouco mais (por exemplo, até que alguma outra coisa desencadeia um redesenho), então o set / get cenário seria o caminho a percorrer.

Answer 7

Eu prefiro o show () e hide () métodos porque eles explicitamente dizer o que você está indo. faz o setVisible (boolean) não lhe dizer se o método vai mostrar / tirar imediatamente. Além disso show () e hide () são método para uma interface (IMHO) melhor-nomeado.

Answer 8

Implicitamente, o 'show' e funções 'esconder' você lista são os dois setters

Para booleans, eu acho que uma única ferramenta como você mostrou seria bom. No entanto, uma função .mostrar e .hide também olhar como comandos, e não funções que alteram o estado do objeto.

Answer 9

No caso você realmente tem que escrever código como

if (shouldBeShowingAccordingToBusinessLogic()) w.show();
else w.hide();

em todo o lugar, que você pode ser melhor fora com

w.showIfAndOnlyIf(shouldBeShowingAccordingToBusinessLogic())

Ou, para casos verdadeiramente bizarro, quando a sua lógica não pode decidir se quer dhow ou não até o final de algum trecho de código, você pode tentar

w.setPostponedVisibility(shouldBeShowingAccordingToBusinessLogic());
...
w.realizeVisibility();

(não fiz eu digo que é bizarro?)

Answer 10

Uma motivação adicional para ir para a exibição / ocultar a solução é que, como um setter,

o método setVisible tem um 'efeito colateral', em que ele também exibe ou oculta SomeClass. As display / ocultar métodos melhor transmitir a intenção do que acontece.