Existem quaisquer situações em que um efeito colateral de uma operação de "pegar" ou "calcular" é legítimo?

votos
4

Acabei de terminar uma sessão de depuração seis horas para um efeito UI estranho onde eu achei que a implementação do meu quadro favorito de uma função de interface chamada getVisibleRegion desativada alguma característica UI (e aparentemente esqueceu de restaurá-lo).

Eu já entrou com um bug com o quadro, mas isso me fez pensar sobre o design adequado: em que condições é legítimo ter quaisquer efeitos secundários em uma operação com um nome que implica um mero cálculo / ficando operação?

Para aqueles interessados nos detalhes reais: Eu tive um relatório sobre um bug onde o meu plug-in ficava quebrando o desdobramento de código do Eclipse para que a barra de dobramento desapareceu e era impossível desdobrar ou ver código dobrado. Eu segui-lo para baixo para uma chamada para getVisibleRegion () em um ITextViewer cujo tipo representa um visualizador de código fonte. Agora, a documentação do ITextViewer se afirmar que Os espectadores execução ITextViewerExtension5 pode ser forçado a mudar as frações do documento de entrada que são mostrados, a fim de cumprir esse contrato. A implementação real, no entanto, levou isso um pouco demais projeção liberalmente e apenas pessoas com deficiência (dobrar) permanentemente, para nunca mais trazê-lo de volta.

Publicado 10/12/2008 em 02:57
fonte usuário
Em outras línguas...                            


5 respostas

votos
5

A maior razão que eu posso pensar é resultado de cache.

Respondeu 10/12/2008 em 03:08
fonte usuário

votos
3

Eu diria Nenhum.

Respondeu 10/12/2008 em 02:58
fonte usuário

votos
2

Eu diria que só se for muito óbvio que o efeito colateral ocorrerá. Aqui está um exemplo rápido:

  MakeMyLifeEasyObject mmleo = new MakeMyLifeEasyObject(x, y, z, default, 12, something);

  Object uniqueObjectOne = mmleo.getNewUniqueObject();
  Object uniqueObjectTwo = mmleo.getNewUniqueObject();

  System.out.println(uniqueObjectOne.getId() == uniqueObjectTwo.getId()); // Prints "false"

Agora, na minha teoria aqui, o MakeMyLifeEasyObject tem algum contador interno (como uma chave primária em uma tabela DB). Há um efeito colateral do get. Eu também pode vir até com a idéia de algo como isto:

  Object thing = list.getNextObjectAndRemoveFromList();

Isso faria sentido também.

Agora, a ressalva delas é que em ambos os casos, é apenas melhor para mudar o nome do método .

O primeiro deles provavelmente seria melhor como createNewUniqueObject (), enquanto no segundo um nome diferente (neste caso, pop ()) seria melhor.

Quando não é algum exemplo semi-artificial como eu dei acima, eu diria que os efeitos secundários só que deve estar acontecendo é a criação / atualização de alguns cache se o valor leva um longo tempo para criar ou pode ser usado um pouco e necessidades para ser acelerado.

Um exemplo disso seria um objeto que contém um monte de cordas. Você tem um método, getThingToPrint () que precisa concatenar um monte juntos. Você poderia criar um cache quando que é chamado, e que seria um efeito colateral. Quando você atualizar uma das cordas que as coisas são baseados em, o conjunto iria invalidar o cache (ou atualizá-lo).

Algo como o que você descreveu? Definitivamente soa como um bug. Eu não consigo pensar em uma situação onde isso seria uma boa idéia. Se isso é um comportamento desejado e não um bug, então ele deve ser renomeado para algo mais (ou seja disableThingAndGetVisibleRegion ()).

Respondeu 10/12/2008 em 03:17
fonte usuário

votos
2

Este pode ser um tal caso extremo que ele mesmo não se qualifica como um efeito lateral, mas, se o resultado do cálculo é armazenada no objecto, então que seria aceitável. Mesmo assim, ele não deve fazer a diferença para o chamador.

Respondeu 10/12/2008 em 03:07
fonte usuário

votos
0

obj.getBusyDoingStuff ()

Respondeu 10/12/2008 em 03:02
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more