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

bootcd

py.user.next
Вот у тебя два человека общаются стоят. Ты что будешь описывать? Абстракцию Человек и ещё одну абстракцию Человек?

Скорее я опишу абстракцию “Разговор людей”, где свойством “участники” будет список, состоящий, например из объектов людей, а методами, например “фиксация разговора”, в виде “запись разговора на диктофон”, если абстракцию “Разговор людей” я через наследование, например, могу выделить в абстракцию “Интервью” или метод “запись разговора на видео”, если это будет наследник - “Видеоподкаст”.
Что-то типа:

  
class Human:
    pass
  
class TalkingPerson(Human):
    def __init__(self, name, role):
        self.role: str = role
        self.name: str = name
    
  
class Talking:
    def __init__(self, members):
        self.members: list[TalkingPerson] = members
  
    def get_fixation(self):
        pass
  
    def get_info(self):
        pass
  
    
class Interview(Talking):
  
    def __init__(self, members):
        super().__init__(members)
  
    def get_fixation(self, dictofon_recording_file=None):
        # record works
        return dictofon_recording_file
  
    def get_info(self):
        return f"{self.members[0].name} задает вопросы {self.members[1].name} и записывает на диктофон ответы."
  
  
class VideoPodcast(Talking):
    def __init__(self, members):
        super().__init__(members)
  
    def get_info(self):
        return f"{self.members[0].name} ведет подкаст с гостем {self.members[1].name} и записывает видео."
  
    def get_fixation(self, videostaff_recording_file=None):
        # record works
        return videostaff_recording_file
  
  
person1 = TalkingPerson('Васян', 'журналист')
person2 = TalkingPerson('Толян', 'интервьюируемый')
  
interview = Interview([person1, person2])
interview_file = interview.get_fixation()
interview_info = interview.get_info()
  
person3 = TalkingPerson('Иванов', 'подкастер')
person4 = TalkingPerson('Зубарев', 'гость')
  
videopodcast = VideoPodcast([person3, person4])
  
videopodcast_file = videopodcast.get_fixation()
videopodcast_info = videopodcast.get_info()
  
print(interview_info)
print(videopodcast_info)

Вот так на данный момент я понимаю самые простые конструкции ООП. Где я понимаю неверно?

Ну вот ты код написал, когда ещё ничего не разработано. Это для красоты просто.

А теперь продолжаем

py.user.next
Вот у тебя два человека общаются стоят.

И тут один из них спрашивает другого “слушай, а напомни мне, как тебя зовут?”, другой ему отвечает “меня зовут Коля”, а первый говорит “хорошо, я запомню” и запоминает.

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

bootcd
Вот у меня есть условный коллега, для которого я пишу этот класс. Написал - отдал.

И ему надо добавить в него теперь вот эту ситуацию. Прикол в том, что он тебе тоже может передать красивый код, а добавлять в него надо будет тебе. Кто не добавил, тот и виноват во всём. Но самый прикол будет, когда тебе твой же код передадут.

Отредактировано py.user.next (Май 4, 2024 02:50:45)

Rodegast
Ты удивишься, но у объекта может быть несколько конструкторов каждый под свои условия. Это распространено в java, c# и подобных языках в python-е это сделать сложнее, но всё рано можно.

Да это обычное дело. Это полиморфный метод. Но даже при наличии этой семантики в языке, это никак не поможет его спроектировать. Он же не проектирует ничего, вон сразу бросился код писать, будто код ему правильную архитектуру построит, если он его писать начнёт поскорее. Стандартная ошибка школоты.

Rodegast

bootcd
А у тех же джавистов написано, что если у вас в классе есть статические методы (по моему ,приводили - если больше одного), то ваш класс криво спроектирован.

Не надо на них внимание обращать, у них свой ООП со своими приколами.

Не, там имеется в виду, что если у тебя статические методы копятся вперемешку с обычными методами, то это признак того, что ты эти статические методы не туда засунул и загрязнил объект (внутри объекта находится то, что должно быть снаружи него). Это понижение связности. Все методы объекта должны быть собраны вокруг его функции, которую он выполняет, и должны работать на выполнение этой функции.

py.user.next
Да это обычное дело. Это полиморфный метод. Но даже при наличии этой семантики в языке, это никак не поможет его спроектировать. Он же не проектирует ничего, вон сразу бросился код писать, будто код ему правильную архитектуру построит, если он его писать начнёт поскорее. Стандартная ошибка школоты.

Вот, не поверите!
Именно за этим я сюда и пришел! Чтобы прояснить момент именно по проектированию.
Код я пишу, чтобы показать проблему. Я там пытался на словах пояснить, не мне сразу начали показывать код, собственно, что начал делать и я.

py.user.next
Стандартная ошибка школоты.

Покажите мне место, если есть возможность, где изначально учат проектировать? Может книга какая?
Везде учат синтаксису. Неважно, курсы, книги. Все примеры показывают на коде. Я использую все доступные мне методы, чтобы понять какие-то вещи, чтобы выработать навык. Ощущение такие, что я иду в темноте по минному полю.
Даже сюда пришел и выслушал про себя “школота” и прочие помидорные распальцовки. Через “карандаши”, “уметь программировать” и кошек с собаками, пытаюсь вот понять связанность.

bootcd
где изначально учат проектировать?

Ну ты вот сарай строить собрался, ты его как строишь? Начинаешь куда-то доски прибивать. А надо как его строить? Надо сначала его придумать. Потом надо его продумать. Потом под это всё подобрать материалы. Также надо выделить время, одежду, инструменты. И только потом его можно строить, прибивая доски. Что в этом непонятного? По-моему, это знают все. Это азы.

Так вот, если ты, не зная азов, пытаешься сразу стать архитектором каких-нибудь зданий типа башня Бурдж-Халифа, даже не построив ни одного сарая, потому что просто прибиваешь доски куда-то там, то с чего вдруг кто-то должен тебе давать книжки по строительству таких зданий? Ты возьми книжки по возведению сараев и хотя бы их прочитай.

bootcd
Везде учат синтаксису.

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

bootcd
и выслушал про себя “школота” и прочие помидорные распальцовки

Это не распальцовки. Мы-то всего достигли уже. У нас уже всё есть. Ты не можешь проскочить это, это так не работает. Это как стать великим архитектором через интенсивный скоростной курс.

Тебе сказали уже: иди изучай азы; тренируйся на кошках; ты не знаешь ничего, как бы там тебе что ни казалось. Это не мы дураки, это у тебя завышенная самооценка. Вот она играет с тобой злую шутку. Ты считаешь себя великим скоростным гением на абсолютно пустом месте и не замечаешь этого в упор. Что ты мне вот рассказываешь, ты обрати внимание на другие сферы своей жизни - там происходит всё то же самое, а нас там нет при этом. Потому что у человека с завышенной самооценкой везде происходит этот эффект, во всех сферах, потому что он даже мысли не допускает, что он обычный никто.

bootcd
Через “карандаши”, “уметь программировать” и кошек с собаками, пытаюсь вот понять связанность.

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

> Чтобы прояснить момент именно по проектированию. Код я пишу, чтобы показать проблему.

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

py.user.next
Ты тут не один. Сегодня ты есть, завтра тебя нет. Поэтому я пишу не столько для тебя, сколько для всех, кто здесь есть сегодня и кто здесь будет завтра. Вот для них это пишется. Потому что есть люди, которые хотят научиться, а не выёживаться тут сидеть, охреневая от своей гениальности и любуясь в зеркальце на себя замечательного.

Вы очень много пишите текста.
Я уже понял, что вы имели ввиду. Основы, азы, кошки. Я с этим уже немного разобрался.
Хотелось бы, знаете, идти дальше, но, видимо, будет уже труднее.

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

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

py.user.next
Ты возьми книжки по возведению сараев и хотя бы их прочитай.

Посоветуйте тогда, если можно.

py.user.next
Мы-то всего достигли уже. У нас уже всё есть.

Расскажите пожалуйста, как вы к этому пришли. Попробую впитать ваш опыт.
Спасибо!

Rodegast
> Например тот вариант с классами который я тебе написал подойдёт если у тебя справочные данные, а если тебе понадобятся транзакции, то будет больно.

Вот я как раз не могу уловить эти моменты. Мне нужен алгоритм того, как прийти к пониманию того, что в таком-то случае “будет больно”, а в таком нет.
Я сейчас даже сомневаюсь про какие “транзакции” идет речь.
Если про работу с СУБД, то я создал модели sqlalchemy с учетом внешних ключей. ТО есть если я укладываю данные в несколько связанных моделей, то я использую сессии, которые насколько я понимаю, как раз и призваны обеспечивать транзакции в БД.
Но в тот же момент, под словом “транзакция” может оказаться очередная конструкция/паттерн ООП, про которую я не знал).
Сложновато понимать немногим более серьезные чем хеловорлд вещи, когда не знаешь годных материалов для изучения.

> Мне нужен алгоритм того, как прийти к пониманию того, что в таком-то случае “будет больно”, а в таком нет.

Нет такого алгоритма. Начни делать проекты в одиночку и чем сложнее тем лучше. Через пару лет всему научишься.

> Если про работу с СУБД, то я создал модели sqlalchemy

Имелись в виду именно транзакции в СУБД. Дурацкий вопрос - ты SQL знаешь?

Rodegast
> Начни делать проекты в одиночку и чем сложнее тем лучше.

Вот как раз я на этом пути. И ощущения “минного поля в темноте” началось как раз когда я запустил приложение в работу, поправил совсем детские баги и задумался над правильной архитектурой.

Rodegast
Дурацкий вопрос - ты SQL знаешь?

В определенной мере да. Мне довольно много приходится ковырять для MSSQL касаемо мониторинга резервного копирования, создания джобов и прочее. По крайней мере сджойнить что-то с фильтрами, сортировками и подзапросами смогу.
В проге у меня конструкции вида: “ получить айди из реквеста, взять из 3 таблиц данные по айди через внешний ключ, по такому-то фильтру, отсортировать по столбцу такому-то по алфавиту, отдать в метод-валидатор, сдампить в модель - вернуть во вьюху”.
Или: “получить форму, сдампить в модель для валидации, вернуть оттуда словарь, создать экземпляр модели sqlalchemy, закинуть в сессию, заапендить модели по связям, положить в базу.”

bootcd
Вот я как раз не могу уловить эти моменты. Мне нужен алгоритм того, как прийти к пониманию того, что в таком-то случае “будет больно”, а в таком нет.

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

Затронули тему про ООП, могу рассказать свое виденье этого.

Здесь нужно понять что такое объект. Речь не о программировании и коде сейчас. Вообще что такое объект, чем он характерен?

У объекта есть границы, отделяющее его внутреннее состояние от всего другого, что не является этим же объектом. Соответственно объект занимает какое-то пространство.

У объекта есть поведение - способность изменять свое состояние. Под состоянием подразумевается его характеристики, свойства, данные

Объект сообщается с внешним миром. Он получает сообщения, реагирует, отправляет сообщения.

В ООП важно создать объекты, которые будут иметь свое состояние, поведение, и реакции. НЕ классы создать этих объектов, а сами объекты.

Скажите, какие объекты вы можете выделить в вашей программе?