Se vc ler com calma este meu comentário, vai entender que no fundo vc implementou o strategy (usou um comportamento diferente em runtime, de acordo com determinados parâmetros).

Precisava dar um nome pra isso? Não sei, mas o fato é que hoje esses nomes existem, e muita vezes acabamos usando design patterns sem perceber.

No fim cai no que eu já disse (e volto a repetir): como as implementações orientadas a objeto se tornaram bem populares, muita gente acha que é o único jeito de usar DP. E pior, acham que se vc usa qualquer outra coisa (como um simples if ou switch), então não está usando design pattern. E essa é uma percepção errônea, mas ainda bem comum, infelizmente.

A verdade é que usamos esses patterns mais do que a gente imagina, só que muitas vezes não ficamos pensando "nossa, agora usei o pattern X". Porque os patterns nada mais são do que soluções catalogadas para problemas comuns. E muitas delas são coisas tão "óbvias" e "triviais", e usamos tão naturalmente, que nem paramos pra pensar se é ou não um pattern.

Esse é outro desserviço dos livros famosos sobre DP: fez as pessoas acharem que eles são coisas super-ultra-elaboradas, que só é possível usá-los com código complexo, dezenas de classes e interfaces, etc. No meu comentário já citado tem links sobre artigos que implementam alguns patterns em C, mostrando que não é obrigatório usar classes.

E nesse mesmo comentário também explica que conforme a complexidade aumenta, as soluções com if e switch podem causar alguns problemas que são resolvidos de outras formas. E uma dessas formas é aquela descrita no livro do GoF. O problema é que muita gente leu e achou que é o único jeito (ou o "jeito certo™"). Não é, pra casos simples um if ou switch já resolve, e isso não quer dizer que vc não está usando DP só porque não fez do jeito complexo.

Pode-se até debater se precisava dar nome pra cada coisinha que fazemos, ou se os nomes são adequados, etc. Mas eles existem, e usamos o tempo todo, mesmo quando achamos que não.