Realizar un sistema de facturación de llamadas telefónicas
Las decisiones de diseño fueron las siguientes:
1- El punto de entrada del sistema es una entidad que es la compañia de telefono. La idea de esto es que si el sistema quiere soportar multiples compañias telefonicas (Claro, Personal, Movistar, etcetera) pueda hacerlo. En ese sentido, el sistema es escalable pues cada telefono pertenecerá a una compañia telefonica y a cada una podrá generarsele la feactura correspondiente.
2- Los telefonos tienen asociada una serie de facturas (bills) según el mes. Cuando se pide la factura de un mes, si el telefono no la posee, la genera y, si no existía antes de pedirla, asumí que significaba que no se habian realizado llamadas durante ese periodo, lo cual devuelve unicamente la factura con el cargo básico del servicio. Hay un problema con esta implementación principalmente en que no está contemplado el hecho de pedir facturas por fuera del mes, por ende, pedir una factura para mayo del año 2024, por poner un ejemplo, traería la factura de mayo del año 2026. Esto se soluciona facilmente sumando al mes de la factura, el año en que fue generada, lo cual tambien permitiría al sistema no generar facturas que todavía no pueden generarse (por ejemplo, pedir una factura de un mes que todavía no ha atravesado el sistema). El scope del ejercicio no parecía hacer mucho enfasis en esto y por eso lo dejo aquí asentado como decisión tomada pero no implementado.
3- Existen 3 tipos de llamadas modeladas dentro del sistema. El problema es que al modelar una "localización (Location)" me dí cuenta que tanto las llamadas Nacionales como las Internaciones tienen la misma "regla" que es básicamnete, poder diferenciar un lugar de otro (ciudades en caso de llamada nacional, paises en caso de llamadas internacionales). Por un lado podríamos obviar la clase Location del sistema pues de momento no aporta nada mas que un lugar donde guardar el nombre de la ciudad y la cuota específica que tiene que aplicarse a cada minuto de llamada realizada, pero me pareció que si bien no tienen un comportamiento suficiente ahora mismo que amerite una clase y una entidad en el sistema, es lógico y consistente con la vida real y también permite que, si en un futuro se diferencian una de otra y hay comportamientos especificos que modelar, podamos con muy poco trabajo incorporar estos nuevos comportamientos o funcionamientos que deberíamos agregar. En estos momentos ambos se tratan de la misma manera simplemente porque el sistema pone la misma restricción:
"""
- Las llamadas Internacionales tienen un costo distinto según el país al que se llame
- Las llamadas Nacionales tienen un costo distinto según la localidad a la que se llame
"""
El día de mañana, si estos comportamientos comienzan a diferir, con la entidad Location ya tenemos mucho del comportamiento que van a seguir compartiendo (tener una cuota específica de precio de llamada por minuto, nombre de la localidad, inicialización, entre otros) en un lugar desde el cual puedan heredar estas clases que representan lo mismo al fin y al cabo, pero que comenzarían a tener comportamientos diferentes (por ejemplo, en el calculo del fee, u otras cuestiones que puedan llegar a surgir).
Para visualizar una factura generada por un pequeño bloque de codigo, puede copiarse lo siguiente y correrlo en el playground:
| company phone date call1 call2 call3 city country bill |
company := TelephoneCompany withName: 'Claro'.
phone := Telephone withNumber: 1234.
company newClient: phone.
date := DateAndTime year: 2026 month: 4 day: 14 hour: 9 minute: 0 second: 0.
call1 := Call withDuration: 25 date: date.
company registerCall: call1 forTelephone: 1234.
city := Location withName: 'Rosario' andFee: 0.9.
call2 := Call withDuration: 10 date: date Type: 'National' inCity: city.
company registerCall: call2 forTelephone: 1234.
country := Location withName: 'Londres' andFee: 2.0.
call3 := Call withDuration: 5 date: date Type: 'International' inCity: country.
company registerCall: call3 forTelephone: 1234.
bill := company getBillForNumber: 1234 fromMonth: 'April'.
Transcript show: bill generateBill.
El sistema tambien cuenta con una serie de tests que fueron realizandose a medida que surgían nuevos requerimientos, escribiendo primero tests que me dieran la pauta de que necesitaba soportar mi sistema, y escribiendo el codigo que pudiera cumplir con esos requisitos. En resumen, utilicé TDD para modelar el sistema, aunque no aplicado a la totalidad del código, me dió una buena guia para ver que (y como) quería otorgarle funcionalidades al sistema.