_Créditos das imagens: Copilot_
# LeetCode :: Integer to Roman : Implementando Soluções em xBase (Harbour) e TL++
## Introdução
A conversão de números inteiros para números romanos é um dos desafios do [LeetCode](https://leetcode.com/problems/integer-to-roman/description/).
Existem várias abordagens para resolver esse problema, e neste artigo vamos explorar quatro diferentes métodos implementados em **Harbour** e **TL++ (TOTVS Language Plus Plus)**, cada um com suas peculiaridades e vantagens. O objetivo é comparar as abordagens usando diferentes técnicas de programação, desde loops simples até métodos recursivos mais avançados.
---
### Versão 1: Uso de Loop
A primeira abordagem utiliza um **loop while** para iterar enquanto o número for maior ou igual a 1000,900,500,400,100,90,50,40,10,9,5,4,1 (e baseada na versão [Harbour](https://raw.githubusercontent.com/naldodj/naldodj-harbour-core/ce1bc2039902f3a3797de532f2d1c7a7745d44a6/contrib/hbmisc/nconvert.prg)) adicionando o símbolo correspondente e subtraindo o valor até que o número seja reduzido a zero. Esse método é simples e direto, com uma lógica bem clara, mas pode ser um pouco ineficiente se o número de iterações for grande.
Esse método é bastante intuitivo e fácil de entender. Contudo, pode tornar-se mais verboso quando lidamos com números maiores, já que o processo de subtração e adição de símbolos ocorre de forma repetitiva. O código dessa abordagem pode ser consultado [aqui](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/hb/012/int_to_roman.12.1.prg).
---
### Versão 2: Uso de Hash Map
A segunda versão utiliza um **hash map** (estrutura de dados) para armazenar os símbolos romanos e suas correspondentes divisões do número inteiro. Isso permite que a conversão seja feita de forma mais flexível e modular. A chave aqui é que o valor do número é calculado diretamente com base na divisão pelo valor mapeado, removendo os loops.
O uso de um hash map oferece uma estrutura mais dinâmica para armazenar e recuperar os símbolos romanos conforme necessário, o que pode ser vantajoso em termos de manutenção e escalabilidade do código. O código dessa abordagem pode ser consultado [aqui](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/hb/012/int_to_roman.12.2.prg).
---
### Versão 3: Implementação de Função Estática `RomanMapping()`
A terceira versão melhora a organização do código, movendo os valores fixos para uma função **estática** chamada `RomanMapping()`. Isso torna o código mais modular, permitindo que as relações entre os números e os símbolos romanos sejam facilmente alteradas em um único ponto. Além disso, a função retorna um **array** que contém todas as combinações possíveis de números e seus respectivos símbolos.
Esse método é altamente modular e facilita a manutenção do código, pois qualquer alteração nas combinações romanas pode ser feita diretamente na função `RomanMapping()`. Ele também é muito mais expansível, permitindo adição de outros valores ou ajustes de forma centralizada. O código dessa abordagem pode ser consultado [aqui](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/hb/012/int_to_roman.12.3.prg).
---
### Versão 4: Recursividade
A quarta versão implementa uma abordagem **recursiva**. A recursão é uma técnica poderosa em que a função chama a si mesma para resolver subproblemas menores. Esse método pode ser mais elegante e eficiente para determinados tipos de problemas, especialmente quando o número a ser convertido possui uma estrutura que pode ser quebrada de maneira recursiva.
A recursão resolve o problema de forma elegante, dividindo o número em partes menores e tratando cada parte de forma independente. Embora a recursão possa ser mais difícil de depurar, ela leva a soluções mais concisas e que, em muitos casos, são mais fáceis de entender após a familiarização com a técnica. O código dessa abordagem pode ser consultado [aqui](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/hb/012/int_to_roman.12.4.prg).
---
### Conclusão
Cada uma das abordagens apresenta vantagens e desvantagens dependendo do contexto. A versão com **loop** é simples, mas pode ser ineficiente para números maiores. O **hash map** oferece uma solução mais flexível e modular, ideal para cenários mais complexos. A versão com **RomanMapping** organiza bem os dados, tornando o código mais fácil de manter, enquanto a abordagem **recursiva** oferece uma solução elegante e compacta, embora mais difícil de depurar.
Cada técnica pode ser escolhida com base na necessidade de eficiência, clareza ou manutenção do código, sendo que soluções mais complexas podem oferecer maior flexibilidade à medida que o sistema cresce.
---
### Links para Consulta
- **Harbour (xBase)**:
- [Versão 1](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/hb/012/int_to_roman.12.1.prg)
- [Versão 2](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/hb/012/int_to_roman.12.2.prg)
- [Versão 3](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/hb/012/int_to_roman.12.3.prg)
- [Versão 4](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/hb/012/int_to_roman.12.4.prg)
- **TL++ (TOTVS Language Plus Plus)**:
- [Versão 1](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/tlpp/012/int_to_roman.12.1.tlpp)
- [Versão 2](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/tlpp/012/int_to_roman.12.2.tlpp)
- [Versão 3](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/tlpp/012/int_to_roman.12.3.tlpp)
- [Versão 4](https://github.com/naldodj/naldodj-xbase-leetcode-solutions/blob/main/src/tlpp/012/int_to_roman.12.4.tlpp)
---
### Hashtags
#TLPP, #Harbour #Algoritmo, #Desafio, #ConversaoDeNumeros, #Romanos, #Programacao, #Tecnologia, #HashMap, #Recursao, #LeetCode
---
Um desafio e tanto Marinaldo! Já pensei em fazer uma função assim, mas logo desistí...
ResponderExcluir