Python-сообщество

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

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

Отредактировано py.user.next (Май 2, 2024 10:32:52)

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

Отредактировано bootcd (Май 2, 2024 10:39:06)

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

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

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

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

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

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

Отредактировано py.user.next (Май 2, 2024 13:04:06)

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 (Май 2, 2024 15:06:12)

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

> Просто реализация функционала на костылях - это плохой код. Велосипедные решения уже давно решенных задач - тоже. Код, который можно безболезненно встроить в имеющийся, который решает типовые задачи и написан согласно паттернам, решающим такие типовые задачи, если это код соответственно может быть использован в других местах и другими людьми - это по моему мнению хороший код.

Всё что ты написал это демагогия и не более того. “Хороший код” должен удовлетворять следующим критериям:
1) Правильно работать
2) Иметь достаточно хорошую архитектуру
3) Быть достаточно производительным
Насколько я понял с 1 и 3 пунктом проблем нет. Что касается 2-го пункта, то ты в первую очередь должен обеспечить слабую связанность между компонентами системы. Как раз SOLID и “депенденси инджекшн” (если ты не разобрался с тем что это такое обрати внимание на второй пост, там как раз он продемонстрирован) на это и нацелены.

> Там я вижу или нубский код типа моего или какую-то хтонь с дженериками, протоколами и прочими малопонятными мне на данный момент вещами.

Не нужно думать что если код “нубский”, то он плохой. Оценивай сами проекты, смотри сколько людей, звёзд и прочее.

> Я вижу такой класс вот так как в этом псевдокоде …

Первое что приходит в голову это вот так:

 class ServerWorksManager():
    def create_server(self, form_data):
        self.orm.save(form_data)
   
    def get_server_by_id(self, _id):
        self.orm.get(_id)
   
    def delete_server(self, _id):
        self.orm.delete(_id)

 class ServerWorksManager():
    def create_server(self, data):
        self.orm.save(data.form_data)
   
    def get_server_by_id(self, data):
        self.orm.get(data._id)
   
    def delete_server(self, data):
        self.orm.delete(data._id)

 class Crud_Singleton:
  orm = ....
 
class BaseData:
    def __init__(self):
        self._orm = Crud_Singleton()
 
class Server(BaseData):
    def __init__(self, _id, form_data):
        super().__init__()
        self._id = _id
        self.form_data = form_data
     
    def create(self):
        self._orm.save(self.form_data)
   
    def get_by_id(self):
        self._orm.get(self._id)
   
    def delete(self):
        self._orm.delete(self._id)

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

Отредактировано sa (Май 2, 2024 23:50:41)

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()

Отредактировано py.user.next (Май 3, 2024 11:08:14)