6.
CONSIDERACIONES TÉCNICAS
6.1 Patrones de Diseño Aplicables en JavaScript
Los patrones de diseño son soluciones generales y reutilizables a problemas comunes en el
desarrollo de software. Para un proyecto en JavaScript, algunos patrones aplicables son:
Singleton: Garantiza que una clase solo tenga una instancia y proporciona un punto de
acceso global a ella. Útil para gestionar la configuración de la base de datos o un carrito de
compras.
Factory: Define una interfaz para crear un objeto, pero permite a las subclases decidir qué
clase instanciar. Esto se usa para manejar la creación de diferentes tipos de menús (e.g.,
menú de desayuno, almuerzo) sin especificar las clases concretas.
Observer: Define una dependencia de uno a muchos entre objetos para que, cuando un
objeto cambie de estado, todos sus dependientes sean notificados y actualizados
automáticamente. Ideal para notificaciones en tiempo real, como el estado de un pedido.
Module Pattern: Utiliza closures para encapsular variables y funciones privadas,
exponiendo solo la interfaz pública. Es fundamental en JavaScript para evitar la
contaminación del espacio de nombres global.
6.2 Principios SOLID
Los principios SOLID son cinco principios de diseño de software destinados a hacer los diseños más
comprensibles, flexibles y fáciles de mantener.
S - Single Responsibility Principle (Principio de Responsabilidad Única): Una clase debe
tener una sola razón para cambiar.
o Aplicación: En lugar de tener una sola clase que maneje el pedido, el pago y la
entrega, se crean clases separadas. Por ejemplo, ClasePedido, ClasePago y
ClaseEntrega.
O - Open/Closed Principle (Principio Abierto/Cerrado): Las entidades de software deben
estar abiertas para la extensión, pero cerradas para la modificación.
o Aplicación: Si se añade un nuevo método de pago (e.g., PayPal), se crea una nueva
clase PayPalPago que implementa la interfaz de Pago, sin modificar la clase de
pago existente.
L - Liskov Substitution Principle (Principio de Sustitución de Liskov): Los objetos de un
programa deben ser sustituibles por instancias de sus subtipos sin alterar la corrección de
ese programa.
o Aplicación: Si tienes una clase MenuHamburguesa que extiende Menu, cualquier
función que acepte un Menu debe poder usar MenuHamburguesa sin fallar.
I - Interface Segregation Principle (Principio de Segregación de Interfaces): Los clientes no
deben ser forzados a depender de interfaces que no usan.
o Aplicación: Se crean interfaces específicas para cada rol. Por ejemplo, una interfaz
GestionPedidos para el administrador y una interfaz SeleccionProductos para el
cliente.
D - Dependency Inversion Principle (Principio de Inversión de Dependencias): Los
módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben
depender de abstracciones.
o Aplicación: La clase ProcesadorPedidos no debe depender directamente de una
clase de base de datos específica. En su lugar, debería depender de una interfaz
RepositorioPedidos, que luego se implementa en la clase de base de datos
específica.
6.3 Seguridad y Validaciones
La seguridad es clave para un sistema multiusuario donde cada negocio tiene su propio
administrador.
Autenticación y Autorización:
o Autenticación: Verificar la identidad del usuario (administrador de negocio). Se
implementaría un sistema de inicio de sesión seguro, usando JSON Web Tokens
(JWT) para gestionar sesiones de forma segura y sin estado.
o Autorización: Controlar a qué recursos tiene acceso el usuario autenticado. Cada
administrador solo tendría acceso a la información y gestión de su propio negocio,
como sus menús, pedidos y reportes.
Validaciones:
o Validación del lado del servidor: Todas las entradas del usuario (datos de pedidos,
información de productos, etc.) deben ser validadas en el servidor para prevenir
ataques de inyección de SQL y XSS.
o Validación de datos: Se debe asegurar que los datos enviados a la base de datos
cumplan con los tipos y formatos esperados.
Separación de datos:
o Cada negocio tendría su propio esquema o identificador en la base de datos,
asegurando que los datos de un negocio no sean accesibles por otro.
Cifrado de contraseñas:
o Las contraseñas de los administradores se deben almacenar siempre hasheadas
(no cifradas) usando algoritmos robustos como bcrypt.
API REST:
o Para la comunicación entre el frontend y el backend, se usaría una API REST con
endpoints seguros, validando cada solicitud con el token JWT para garantizar que
el usuario tiene permisos para acceder a la información que está solicitando.