Как правильно разделить большой модуль с единственным классом?

Question

[User]

Приветствую всех.

Суть проблемы. Есть одно ООП-подобное полотно (жертва оверинжиниринга) с единственным классом на 1200 строк и почти с 50 методами. Методы разные, но все они работают напрямую с тремя таблицами - с пользовательскими данными и их правами (табл. 1), с данными чатов/групп/каналов (табл. 2),и есть всякие утилитарные методы для таблицы 3.
Медленно ковыряясь в этом полотне после двухлетнего перерыва встал вопрос оптимизации и упрощения кода модуля. Но.. с чего начать? Какие есть правильные пути и что можете посоветовать?
-
Пока долго изучал код и сочинял вопрос,придумал вариант с раздроблением класса на 4 маленьких. Где 1й - базовый, который подключается к базе и возвращает курсор, и 3 унаследованных от базового для тех самых трёх таблиц.
Правильно ли такое разделение или есть варианты получше? Чтобы всё было по красоте и OOP-style.

Comments

[Дмитрий]

Наследование тут прохо применится, сделайте что то типо репозитория основного, и три потомка на каждую таблицу, и логику где только данные даются репозиториям

[User]

Дмитрий, Спасибо

[Дмитрий]

User, судя по названиям ваших методов, вам идеально орм какая либо готовая зайдет

Answer 1

[mayton2019]

Есть такое старое правило что сначала нужно писать тесты. Без тестов ты конечно можешь начать рефакторинг но если что-то сломалось то сложно будет детектировать поломку именно в тот момент. Это всплывёт позднее.

Далее без исходников сложно что-либо советовать. Тут - сколько людей столько и мнений.

Comments

[User]

Тесты будут обязательно, но сейчас вопрос больше о структуре самого модуля.

Далее без исходников сложно что-либо советовать

Исходники не приложил, потому что там всё максимально просто

Приблизительный пример

class DB:
    def __init__(...):
        ...
    def get_user(user_id)
    def update_state(user_id, state)
    def save_user(user)
    def is_user_admin(user_id)
    ...
    def is_chat_paid(chat_id)
    def get_chat_users(chat_id)
    ...

И дальше по списку. То есть обычная инициализация класса и список из кучи методов. В них ничего необычного не происходит, просто самих методов много.

[mayton2019]

User, нет-нет. Приблизительный пример - это как бабка "надвое" сказала. Или как вылить кофе и гадать по нему.

Вобщем декомпозиция на мелкие классы - идея правильная. Насчет Python я тут не сильный советчик. Не скажу как лучше. Но если-бы это была Java и работа с базой данных - тогда обычно вводят сущности таблиц (Entities) и репозитарии доступа к базе. Можешь глянуть как принято делать в ORM-фреймворках.

[Дмитрий]

User, может есть какая то готовая орм?

[User]

mayton2019, Спасибо, почитал про репозиторий паттерн, вроде то что мне нужно.

Дмитрий, Нашел одну, но быстрее будет написать свое решение. у меня требования небольшие и не хочу переусложнять

[Дмитрий]

User, ну репозиторий чем удобен, завтра поменялись реалии, поменяли хранилище, надо только поменять реализацию работы репозитория с хранилищем, остальное не переписывается

[Vitsliputsli]

User, просто следуйте правилу Single Responsibility. Выделяйте ответственности и заключайте их в отдельные классы.

Дмитрий, если придерживаться абрстракций при разработке, то все равно получится слой похожий на репозиторий.
Часто ли вам приходилось менять СУБД, если говорить про классические? В сложных проектах это в любом случае сложно, в простых нет нужды.

[mayton2019]

Если брать ентерпрайзные проекты при мне, то база менялась аж.. никогда. Обычно когда бизнес купил себе Oracle или MSSQL то переход на другую систему равносилен пожару или потопу. К тому времени приложения уже используют модули и хранимые процедуры и смена dbms превращается в аватнюру. Никто просто не захочет заплатить столько денег.

Поэтому необходимость в ORM есть но в части смены DBMS она обычно преувеличена.