No description
  • Python 44.5%
  • JavaScript 23.3%
  • CSS 15.1%
  • HTML 14.5%
  • Dockerfile 2.6%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Jairodaniel-17 52a51ce5bf ok
2024-12-04 21:02:48 -05:00
repositories mejora implementada en el song repository: singleton 2024-12-04 18:59:31 -05:00
routers correción faltaba el endpoint para descargar una canción de la lista de reproducción 2024-11-13 18:07:23 -05:00
services version con patrones 2024-11-13 16:04:41 -05:00
static version con patrones 2024-11-13 16:04:41 -05:00
templates version con patrones 2024-11-13 16:04:41 -05:00
.gitignore version con patrones 2024-11-13 16:04:41 -05:00
app.py se deja para usar docker por defecto host: 0.0.0.0 puerto:5000 2024-11-13 16:38:40 -05:00
Dockerfile mejora implementada en el song repository: singleton 2024-12-04 18:59:31 -05:00
Readme.md mejora implementada en el song repository: singleton 2024-12-04 18:59:31 -05:00
requirements.txt version con patrones 2024-11-13 16:04:41 -05:00

Musica-flask

1. Introducción

1.1 Descripción General del Proyecto
Musica-flask es una aplicación web diseñada para facilitar la descarga y gestión de música desde YouTube, ofreciendo una experiencia intuitiva para los usuarios. La aplicación permite descargar canciones, almacenar archivos de audio e imágenes relacionadas, y descargar todo el contenido en un archivo ZIP. Su arquitectura modular incluye patrones de diseño que garantizan escalabilidad, flexibilidad y facilidad de mantenimiento. En esta nueva versión, se ha mejorado la eficiencia y la seguridad en la gestión de recursos al implementar el patrón Singleton en la clase SongRepository, asegurando que esta clase tenga una única instancia durante toda la ejecución de la aplicación.

1.2 Estructura del Proyecto
El proyecto está organizado en una estructura clara y modular que facilita la navegación, el mantenimiento y la extensión de funcionalidades.

Estructura de Carpetas:

Musica-flask/
│   .gitignore
│   app.py
│   ejecutable.bat
│   favicon.ico
│   Readme
│   requirements.txt
│   
├── .venv
├── music
│   ├── .....mp3
├── repositories
│   └── song_repository.py
├── routers
│   ├── download_routes.py
│   ├── image_routes.py
│   └── music_routes.py
├── services
│   ├── file_service.py
│   ├── youtube_service.py
│   └── zip_service.py
├── static
│   ├── css
│   │   └── main.css
│   ├── img
│   │   ├── .....jpg
│   └── js
│       └── main.js
├── temp
└── templates
    ├── index.html
    └── layout.html

1.3 Explicación de Archivos y Directorios
(Se mantiene como en la versión anterior, excepto la actualización en repositories/song_repository.py)

1.3.2 Directorios

  • repositories/: Incluye song_repository.py, que maneja el acceso a las canciones. Ahora utiliza el patrón Singleton para garantizar que solo exista una instancia de la clase SongRepository, optimizando la gestión de recursos.

2. Patrones de Diseño Utilizados

2.1 Patrones Específicos

  • Singleton: Se asegura que SongRepository sea una única instancia en toda la aplicación, proporcionando un punto centralizado para acceder a las operaciones relacionadas con las canciones. Esto previene problemas de inconsistencia de datos o duplicación de operaciones sobre el sistema de archivos.
    Implementación: Se utilizó una metaclase SingletonMeta con bloqueo de subprocesos (thread-safe) para garantizar la creación controlada de instancias.

Ejemplo de código:

class SingletonMeta(type):
    _instances = {}
    _lock = Lock()

    def __call__(cls, *args, **kwargs):
        with cls._lock:
            if cls not in cls._instances:
                instance = super().__call__(*args, **kwargs)
                cls._instances[cls] = instance
        return cls._instances[cls]

class SongRepository(metaclass=SingletonMeta):
    def __init__(self):
        if not hasattr(self, "initialized"):
            self.music_path = os.path.join(os.getcwd(), "music")
            self.initialized = True

Otros Patrones Relevantes:

  • Servicio (Service): Encapsula la lógica de negocio en servicios reutilizables.
  • Repositorio (Repository): Maneja operaciones de persistencia y recuperación de datos, implementado ahora como Singleton.
  • Router/Blueprint, Fachada (Facade), Controlador (Controller), y otros permanecen sin cambios, con ejemplos claros de su implementación en el proyecto.

3. Conclusión
Con la inclusión del patrón Singleton en SongRepository, la aplicación Musica-flask refuerza su arquitectura modular y escalable, asegurando una gestión eficiente de los recursos relacionados con las canciones. Esto, junto con los otros patrones de diseño, facilita el mantenimiento y asegura que la aplicación pueda manejar futuras expansiones sin comprometer el rendimiento o la estabilidad.

Tienes razón, el patrón utilizado en ConfigService no es un Singleton tradicional, sino que se implementa a través de una clase que utiliza la metaclase SingletonMeta. Esto asegura que sólo exista una instancia de la clase en todo el ciclo de vida de la aplicación. Vamos a corregir el anexo:


4. Anexo: Patrones de Diseño

El proyecto Musica-flask emplea varios patrones de diseño que aseguran modularidad, reutilización y escalabilidad. Este anexo describe cada patrón utilizado, su propósito y cómo se implementa en el proyecto.

Patrón de Diseño Descripción Implementación en el Proyecto
Singleton (con SingletonMeta) Asegura que una clase tenga una única instancia en toda la aplicación mediante una metaclase especializada. Implementado en ConfigService utilizando SingletonMeta para centralizar y mantener una única configuración global.
Servicio (Service) Encapsula la lógica de negocio en componentes reutilizables y accesibles desde múltiples partes del sistema. YouTubeService, FileService y ZipService manejan operaciones específicas como descarga de videos y creación de ZIP.
Repositorio (Repository) Abstrae el acceso a los datos para facilitar la gestión y el mantenimiento sin exponer la implementación interna. SongRepository maneja la persistencia de archivos de música e imágenes en el sistema de archivos.
Router/Blueprint Divide las rutas de la aplicación en módulos independientes para mejorar la organización y modularidad. Las rutas están separadas en archivos como download_routes.py, music_routes.py e image_routes.py.
Abstracción de Funciones Simplifica el uso de funciones complejas, reduciendo el acoplamiento entre módulos. FileService abstrae operaciones como limpieza de nombres de archivos, guardado de imágenes y conversión de MP3.
Controlador (Controller) Coordina la lógica de la aplicación, manejando la interacción entre servicios y vistas. app.py actúa como controlador principal, configurando la aplicación y delegando responsabilidades a los servicios.
Fachada (Facade) Proporciona una interfaz unificada para acceder a un conjunto de subsistemas, ocultando la complejidad. Los servicios como ZipService encapsulan múltiples operaciones complejas en métodos sencillos para los usuarios.
Fábrica (Factory Method) Proporciona un método para crear objetos sin exponer el proceso de instanciación al cliente. Implícito en servicios como YouTubeService, que crean instancias de clases necesarias para interactuar con la API.
Adaptador (Adapter) Permite que una interfaz existente se adapte a otra esperada por el cliente, facilitando la integración. YouTubeService actúa como adaptador entre la API externa de yt_dlp y los servicios internos de la aplicación.

4.1 Beneficios de los Patrones de Diseño Implementados

  • Mantenimiento: La separación de responsabilidades facilita la localización y corrección de errores.
  • Escalabilidad: La modularidad permite agregar nuevas funcionalidades sin alterar las existentes.
  • Reutilización: Los servicios y repositorios son independientes y pueden ser reutilizados en otros proyectos.
  • Claridad: La abstracción de funciones y el uso de fachadas simplifican la interacción con subsistemas complejos.