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

Доброе время суток!
Пишу игровое приложения “Мафия” и столкнулся с проблемой ООП.
Не могу понять, как сделать в функции “def is_dead” удалить объект\игрока
И где я должен прописать речи игроков, ночь, отстрелы и проверки.

Просьба объяснить логику написания ооп
Спасибо за помощь

 class Player():
    def __init__(self, user_name, user_box, user_rol):
        self.user_name = user_name # Имя игрока
        self.user_box = user_box # Место за игровым столом
        self.user_rol = user_rol # Роль игрока
        self.user_life = 0 # Переменная для проверки жив игрок за столом или нет
        def is_dead(self): # Функция смерти
            self.user_life = 1
class Game_Mafia():
    def __init__(self):
        self.rols = rols # Дублирую роли из списка
        random.shuffle(self.rols) # Шафлю роли
    def create_player_and_take_rols(self): 
        for i in range(len(lobby)):
            self.player = [Player(lobby[i], i, self.rols[i])] # Создание каждого игрока

Наличия классов недостаточно для ООП.

FLiN
Просьба объяснить логику написания ооп

Отредактировано py.user.next (Ноя. 27, 2021 00:37:31)

Up, может кто поможет?

FLiN
Давайте начнем с объявления типов. Вам нужно для начала вообще без всякого наполнения кодом определить какими сущностями будет оперировать программа. Вот например у вас есть некая переменная user_rol, что это такое, какого оно типа? Наверное это некий алгебраический тип, то есть сумма всех возможных ролей? Тогда создайте соответствующий класс-перечисление. И так для всех используемых понятий. Потом вы должны будете определиться с ответственностью ваших типов, то есть наделить каждый из них набором присущих сугубо этому типу действий, таким образом, чтобы ответственности не пересекались и в то же время классы не были слишком универсальными. Это называется принцип единой ответственности. Потом наполняйте свои классы зависимостями. Это означает, что какие-то классы будут использовать другие классы в своей внутренней структуре. Зависимости должны быть как можно менее связными, то есть если класс А входит как зависимость в класс Б, то изменения в классе А не должны приводить к необходимости изменять код класса Б и наоборот.