O que você acha que deixa as pessoas mais impacientes quando assumem o controle do código legado? UML extremamente complexo? Eu não acho. Minha resposta é, se tiver mais de dois outros, ou mudar com mais de dois casos. Mas é normal usar muito if else e trocar casos no seu código? errado! A maioria dos casos if else e switch com mais de duas ramificações não devem aparecer em formato codificado.
De onde vêm as ramificações complexas?
Em primeiro lugar, a primeira questão que queremos discutir é por que muitas vezes existem tantas ramificações complexas no código legado. Essas ramificações complexas muitas vezes não existem na primeira versão do código. Supondo que o designer ainda tenha alguma experiência, ele deverá prever áreas que possam precisar ser expandidas no futuro e reservar interfaces abstratas .
Porém, após o código passar por diversas iterações, principalmente após diversos ajustes nos detalhes dos requisitos, surgirão ramificações complexas. Ajustes detalhados nos requisitos muitas vezes não são refletidos na UML, mas diretamente no código. Por exemplo, as mensagens foram originalmente divididas em duas categorias: mensagens de chat e mensagens do sistema. Durante o design, estas foram naturalmente concebidas como duas subcategorias da categoria de mensagens. Mas então, um dia, os requisitos são ajustados em detalhes. Algumas das mensagens do sistema são importantes e seus títulos devem ser exibidos em vermelho. Nesse momento, os programadores costumam fazer as seguintes modificações:
Adicione um atributo importante à classe de mensagem do sistema
Adicione uma ramificação sobre o atributo importante no método de renderização correspondente para controlar a cor do título. Por que o programador faria tal alteração? Talvez seja porque ele não percebeu que deveria ser abstrato. Como o requisito diz que "algumas das mensagens do sistema são importantes", para programadores que receberam mais treinamento em linguagens de programação imperativas, a primeira coisa que eles podem pensar é no bit de sinalização - um bit de sinalização pode distinguir entre importantes e não importantes. . importante. Ele não esperava que esse requisito pudesse ser interpretado de outra forma: “As mensagens do sistema são divididas em duas categorias: importantes e sem importância”. Interpretando desta forma, ele sabia que as mensagens do sistema deveriam ser abstraídas.
É possível, claro, que o programador saiba que a abstração é possível, mas por algum motivo opte por não fazê-lo. Uma situação muito comum é alguém forçar os programadores a sacrificar a qualidade do código em troca da velocidade do progresso do projeto - adicionar uma propriedade e uma ramificação é muito mais simples do que refatorar abstratamente. Se você quiser fazer 10 deste formulário Modificar, é mais rápido fazer 10. ramos ou 10 abstrações? A diferença é óbvia.
É claro que, se houver muitos if elses, algumas pessoas inteligentes se levantarão e dirão: "Por que não mudamos para um switch case?" Em alguns casos, isso pode melhorar a legibilidade do código, assumindo que cada ramificação seja mutuamente exclusiva. Mas quando o número de casos de troca aumentar, o código também se tornará ilegível.
Quais são as desvantagens de filiais complexas?
Quais são as desvantagens de filiais complexas? Deixe-me pegar uma seção do código antigo da versão web do Baidu Hi como exemplo.
mudar (json.resultado) {
caso "ok":
mudar (json.command) {
caso "mensagem":
caso "mensagem do sistema":
if (json.content.from == ""
&& json.content.content == "chutado") {
/* desconecta */
} else if (json.command == "systemmessage"
|| json.content.type == "sysmsg") {
/* renderiza mensagem do sistema */
} outro {
/* renderiza mensagem de bate-papo */
}
quebrar;
}
quebrar;