bootcd
Если вы про именно программистскую вышку - да, у меня такого нет. Я весьма бородатый админ, инженер по образованию. Но сфера разработки приложений сложнее чем скрипты - это для меня новая сфера, да.

bootcd
Мои знания питона - сисадминские. То есть, написать скрипт для мониторинга, парсер логов, добавить в готовую прогу код для метрик Prometheus, дренуть ручку, что-то с нее получить, передать далее и тп.

py.user.next
А если база данных сменится с изначальной на другую, что ты делать будешь?

 engine = create_engine(f'mysql+pymysql://'
                       f'{os.getenv("DB_USER")}'
                       f':{os.getenv("DB_PASSWORD")}'
                       f'@{os.getenv("DB_SERVER")}/'
                       f'{os.getenv("DB_NAME")}',
                       pool_recycle=3600)
  
Base = declarative_base()
  
def get_session():
    return Session(bind=engine)
  
class LDAPAccountsRepo(UserAccountsRepo):
  
    @staticmethod
    def get_accounts(domain_id, search_filter=None):
        with get_session() as session:
            accounts=session.query(UserAccount).filter_by(domain_id=domain_id).all()
        return accounts

py.user.next
Давай так: провёл ли ты декомпозицию на объекты, перед тем как вообще классы затрагивать? Сначала нужно выяснить, какие объекты есть и что они делают, когда всё это работает. Это ещё никаких классов нет. Потому что где-то нужно допридумать объекты, где-то их разделить на части (на другие объекты), где-то их соединить (слить в один объект или агрегировать, собрав в одном объекте, не разрушая их границ и не лишая их состояний). Когда у тебя объекты все установлены и функционируют, образуя работающие механизмы, тогда ты думаешь над классами этих объектов - как всю эту массу объектов разбить на отдельные классы по общим признакам. Классы потом тоже нужно увязывать в отношения, чтобы сохранять целостность и компактность программы, устойчивость к изменениям и нововведениям.

py.user.next
Да даже не вышку, просто книжку. Какие-нибудь игры классические типа там Doom или Warcraft написаны без ООП, но это не значит, что ты их напишешь. Это же надо уметь программировать.

py.user.next
Это нужно учиться, тренироваться и так далее.

bootcd
По идее если у меня будет другая БД, я могу изменить engine.

bootcd
Я описываю абстракцию “Работа с моделями ОРМ по определенной теме”.

bootcd
Посмотрел однажды отрывки из какого-то платного курса по питону и мне как человеку, имеющему опыт преподавания в ВУЗе, было больно.

bootcd
По идее такой объект может выглядеть как набор полей: instance_id, form_data, select_filter и набор методов CRUD.

py.user.next
А если не будет движка для этой ORM-системы?

py.user.next
В вузе тоже может быть дурак какой-то. Я видал таких. Кто его поправит на парах? кто рискнёт? Но когда он в Интернет вылазит и ему говоришь, что он чушь несёт, он пытается с тобой, как со студентом, обращаться, сейчас двойку поставит. Вместо того, чтобы учиться, он пытается тебя заткнуть. Потому что ломать своё представление о своих способностях, это очень неприятно. И курсы от них тоже есть. Одного вот препода помню “абстракция - это вот какая-то каша у меня в голове, сам не знаю, что несу”. Кто его уволит с вуза, если он дебил? Никто его не уволит, потому что что? потому что надо будет искать нового и затыкать им дыру в расписании.

py.user.next
Надо обнаружить все объекты и рассмотреть, что они делают, какие у них взаимодействия. Это без всяких полей делается. Потому что полей можно напридумывать миллион в разных вариациях. И на них тоже не написано, что вот этот набор полей правильный, а вот этот набор полей неправильный.

 class ServerWorksManager():
  
    form_data: dict # Позволяет задать содержимое ORM объекта для сохранения и обновления данных в БД при CREATE и UPDATE
    instance_id: int # Позволяет задать id сервера при операциях READ, UPDATE и DELETE
    select_filter: int # Позволяет задать фильтр для остальных методов READ получения той или иной информации
  
    def create_server(self):
        orm.save(self.form_data)
  
    def get_server_by_id(self):
        orm.get(self.id)
  
    def delete_server(self):
        orm.delete(self.id)
  
server_works_manager = ServerWorksManager(form_data=form_data)
server_works_manager.create_server()
  
server_works_manager = ServerWorksManager(instance_id=instance_id)
server_works_manager.delete_server()

py.user.next
Но когда он в Интернет вылазит и ему говоришь, что он чушь несёт, он пытается с тобой, как со студентом, обращаться, сейчас двойку поставит.

bootcd
Вопрос именно в том, где у меня кардинальное непонимание принципов ООП

bootcd
В итоге я отказался от этой идеи и просто завел набор статических методов, используя класс как неймспейс.
Вопрос именно в том, где у меня кардинальное непонимание принципов ООП, что я пришел вот к такому?

bootcd
Как в на данный момент вижу объекты:

1. Есть необходимость реализовать набор функций. CRUD.
2. Эти функции работают вокруг одной темы. В частности они обеспечивают работу с ОРМ, касаемо выделенной темы. Я приводил в пример информацию о серверах организации.
3. Информация о сервере представляет собой набор данных касаемо самого сервера (формфактор, имя в домене и тп) и сопутствующих данных, например информация о доступе по протоколу ssh извне через IP адрес, выданный провайдером, информация о котором лежит в другом месте БД.
4. Я выделяю абстракцию “работа с серверами”. В нее могут входить данные, необходимые для работы (например данные из веб-формы или id записи в таблице БД) и методы, которые мне позволят оперировать с ОРМ через эти данные.

bootcd
То есть, по факту - это менеджер, который ходит и носит данные в БД, из нее или их там обновляет.
У меня возникли проблемы с пониманием объекта этого менеджера. Потому что по факту в классе “менеджер”, мы создаем инстансы не сколько самого менеджера, а разных по сути менеджеров (менеджер для создания, менеджер для удаления, менеджер для обновления и тд.)
В итоге я отказался от этой идеи и просто завел набор статических методов, используя класс как неймспейс.
Вопрос именно в том, где у меня кардинальное непонимание принципов ООП, что я пришел вот к такому?

bootcd
Вопрос именно в том, где у меня кардинальное непонимание принципов ООП

bootcd
Я написал набор классов, который состоит из статических методов, как раз, чтобы инкапсулировать работу с ORM.

bootcd
По идее можно делать объект типа ServerRepo:
И в зависимости от необходимости в клиентской части укладывать в него нужное поле:

  
server = ServerRepo()
server.data = form_data
server.create()

или

  
server.id = id
server.new_data = form_data
server.update()