Os nomes dos métodos “mais” e “menos” são apropriados?

Java SE 8 vem com um novo mecanismo para datas, introduzindo LocalDate, LocalTimee LocalDateTimeclasses para representar instantes de tempo. Para manipular tais instantes, um conjunto de métodos são dadas: LocalDate.plusDays(...), LocalDate.minusDays(...)e assim por diante.

Sempre achei que a boa prática era nomear métodos após verbos que descrevem seu objetivo, pois métodos são, na verdade, operações a serem executadas, algo que executará uma ação. Só para citar, se você considerar aulas como StringBuilder, por exemplo, os nomes dos métodos são append, insert, delete...

É por isso que, para mim, não parece certo nomear um método plusDaysem vez de sumDays, minusDaysem vez de subtractDays. Só eu acho isso muito chato? O que você acha?

A única razão pela qual consigo pensar é que as datas são objetos imutáveis; portanto, chamando plusDaysvocê não está adicionando dias ao objeto original, mas criando um novo com novas propriedades, mas isso é muito sutil.

java methods naming-standards

— Luigi Cortese
fonte

Eu acho que você está vendo isso muito tecnicamente. O objetivo real dos nomes dos métodos é deixar claro o que faz e torná-lo legível. Acontece que nominá-los com verbos normalmente atinge esses dois objetivos. No entanto, considere um método chamado sqrtque leva a raiz quadrada. Nomear esse método takeSqrtpode parecer fazer sentido de acordo com sua regra, mas nomeá-lo não tornaria o método mais legível nem mais claro.

— Brandin

A programação não é "inglês". Por exemplo, sqrté apenas uma palavra que os programadores devem reconhecer e conhecer. A palavra em inglês é "raiz quadrada" a propósito. Mas nomear as coisas de acordo com o que é natural em inglês não é bom. Tome a palavra "ilícito", por exemplo, uma palavra perfeitamente inglesa. No entanto, se alguém nomear seu método, diga isIllicitque acho que gostaria de arrancar meus olhos toda vez que observasse essa chamada de método. Parece horrível e deve haver uma maneira melhor de expressar a idéia.

— Brandin

sumparece errado neste contexto. Eu prefiro .net's AddDays.

— Junta

@LuigiCortese Os nomes dos métodos são escolhidos para corresponder à ordem de palavras em inglês comum. Math.addExact(1, 2)porque você diz "adicione 1 e 2". tomorrow.plusDays(2)porque você diz "amanhã mais 2 dias". Se addExactfosse um membro de Integeralguma forma, teria sido 1.plusExact(2).

— Tavian Barnes

Pessoalmente, eu esperaria plusDaysretornar uma nova data x número de dias no futuro, enquanto addDayseu poderia esperar que o objeto original fosse alterado. Mas sou apenas eu, não estou tão familiarizado com Java.

— precisa saber é o seguinte

Respostas:

A única razão pela qual consigo pensar é que as datas são objetos imutáveis; portanto, ao chamar plusDays, você não está adicionando dias ao objeto original, mas criando um novo com novas propriedades, mas isso é muito sutil.

Esta é exatamente a razão. Imagine que você tivesse algum tipo de API para manipular intervalos de datas para fins de agendamento. Pode expor métodos que permitem fazer uma declaração como:

var workdaySchedule = initialSchedule.withoutWeekends();

É semelhante à declaração em inglês: "O horário do dia de trabalho é o horário inicial sem fins de semana". Isso não implica alterar o cronograma inicial, implica que o cronograma de trabalho seja uma coisa nova e diferente.

Agora imagine o nome:

var workdaySchedule = initialSchedule.removeWeekends();

Isso é confuso. A programação inicial está sendo modificada? Certamente parece, porque parece que estamos removendo fins de semana. Mas então por que estamos atribuindo isso a uma nova variável? Embora esses dois esquemas de nomeação sejam muito semelhantes, este é muito menos claramente evocativo do que está acontecendo. Isso seria mais apropriado se removeWeekends fez mudar a programação inicial, e voltou void- caso em que withoutWeekendsseria a opção confuso.

Esta é essencialmente uma distinção declarativa x imperativa. Estamos declarando que isso workdayScheduleé uma coisa específica ou estamos executando uma lista de instruções imperativas (como "remover") para fazer essa coisa em particular? Geralmente, a nomeação imperativa faz mais sentido quando você está alterando valores, e declarativa faz mais sentido com valores imutáveis, como o exemplo acima demonstra.

No seu caso, você tem exatamente a mesma coisa. Se eu visse:, tomorrow.plusDayseu não imaginaria que isso tomorrowestava sendo modificado, enquanto tomorrow.addDayseu acho que poderia estar. Isso é um tanto sutil - mas não necessariamente de uma maneira ruim. Sem ter que pensar muito sobre isso, essa nomeação naturalmente define o seu pensamento na linha certa em termos de se você está ou não mudando. Para tornar mais clara essa distinção entre esses estilos imperativo e declarativo: "adicionar" (e "remover") são verbos , enquanto "mais" (e "sem") são preposições .

— Ben Aaronson
fonte

Na verdade, eu tive um problema com addDaysrelação plusDaysontem! No .NET, a DateTimeclasse possui métodos chamados addDays, addMonthse addYears. Criei um método para analisar uma data relativa (1 ano, 2 meses, 3 dias atrás) e chamei os métodos mencionados pensando que estavam modificando o DateTimeobjeto atual . Todas as datas no banco de dados terminavam em 8 de junho de 2015. "Isso é engraçado", pensei. Foi quando me lembrei que addDaysnão modifica o DateTimeobjeto, ele retorna um novo . Então, +1 está ao redor para esta pergunta.

— Greg Burghardt

@GregBurghardt Como usuário do .NET, tenho exatamente expectativas opostas. Eu acho que isso significa apenas que "mais" e "adicionar" são intercambiáveis, não mapeamentos diretos para +e+=

— Agent_L

@Agent_L Isso é interessante. Convenções .NET à parte, "adicionar" e "mais" não são intercambiáveis em inglês.

— Ben Aaronson

Além disso, para datas e horas, é comum falar de D + 1, H + 12 e assim por diante para referenciar o tempo relativo a uma origem específica (também, para o vôo espacial T-10, T-9, etc.). Geralmente, isso é lido como D-mais-1, H-mais-12, T-menos-10. Talvez centrado nos EUA, mas é assim que me parece.

— Kristian H

Você pode achar interessante essa velha questão StackOverflow de Jon Skeet: Qual é o melhor nome para um método “add” não mutante em uma coleção imutável? .

— MicSim

No .NET, a nomeação é diferente, embora o resultado seja exatamente o mesmo. Ao invés de:

tomorrow = LocalDateTime.plusDays(1);

Há sim:

tomorrow = DateTime.Now.AddDays(1);

Isso significa apenas que as diferenças entre a compreensão de "mais" e "adicionar" acabaram sendo uma questão de opinião pessoal. Anime-se, você não está sozinho, pelo menos você pode escolher o idioma que mais lhe agrada:)

— Agent_L
fonte

-1

Provavelmente, este é um artefato de Java usado .Methodpara todos os métodos, tanto os que modificam o objeto quanto os que não.

Imagine uma linguagem que também tenha uma object=>methodsintaxe, que daria methoduma cópia do objeto no qual trabalhar. Agora, nesse idioma, startDate=>plusDays(5)é claramente inequívoco. Leva a data original e cria uma nova data que é 5 dias depois.

Em uma nota sumDaysnão relacionada, não faz sentido aqui. LocalDateé um ponto no tempo , não uma duração . Você pode somar qualquer número de durações (e o resultado é outra duração) e adicionar um ponto no tempo e uma duração (o resultado é outro ponto no tempo), mas não é possível somar pontos no tempo.

— MSalters
fonte