Вопрос по паттернам проектирования?

Question

[Кирилл Горелов]

Парни, читаю сейчас про паттерны проектирования, и из-за изабилия паттернов разбегаются глаза.
И я немного запутался.

Задача следующая.
На питоне реализовать систему уведомления с первоначальной поддержкой смс, email, а потом будет добавляться боты и подключаться апи, какой тут лучше использовать паттерн. Склоняюсь к декоратору, но хотел проконсультироваться.

И точно так же на счет системы оплаты, хотелось бы сделать тоже через паттерны. Пока мысли только на фабричный метод.
Примеры паттернов на питоне нашел https://github.com/pkolt/design_patterns

Answer 1

[dmitriy]

Стратегия

Answer 2

[Сергей Тихонов]

Склоняюсь к декоратору, но хотел проконсультироваться.

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

Comments

[Кирилл Горелов]

Такой подход меня уже не устраивает. Я поэтому и обращаюсь к паттренам.

[Сергей Тихонов]

Чем не устраивает? Вы пытаетесь среди сборника частных решений найти Теорию Всего. Так не получится.

[Кирилл Горелов]

Сергей Тихонов, Не устраивает то,что надо ждать проблем.
Почему бы сразу не попробовать решить хорошо?
А так можно постоянно откладывать решения на потом.

И я не просил найти ответы на все вопросы, а только для двух случаев. Хотя бы начать с чего-то.

[Сергей Тихонов]

Хорошо, вот ответ для первого случая:

какой тут лучше использовать паттерн

Попробуйте использовать паттерн микросервисы. Он ничем не лучше и не хуже паттерна "декоратор", пока Вы не определитесь с проблемой, которую решаете (заметьте, в описаниях паттернов всегда сначала описывается проблема!), и не станет лучше, пока Вы саме не определите понятие "лучше" в данном конкретном случае.

Вот решение для второго случая:

хотелось бы сделать тоже через паттерны

Берете первый паттерн и начинаете его применять. Если получается хорошо - оставляете получившийся код и переходите ко второму паттерну. Если плохо - выбрасываете код и переходите ко второму паттерну. Названия паттернов и порядок не важны.

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

[Кирилл Горелов]

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

[Сергей Тихонов]

В целом, именно так :) Пара десятков неудачных применений паттернов + периодическое перечитывание Gang-Of-Four дают лучший результат чем попытка с нуля сделать конфету.

[Кирилл Горелов]

Сергей Тихонов, а хотелось бы сразу)))

[Евгений Самсонов]

Кирилл Горелов, паттерны решают какие-то проблемы, нужно определится с проблемой и подобрать паттерн, который её решает :) Если проблемы нет, то и паттерн не нужен

[Кирилл Горелов]

Евгений Самсонов, Я знаю точно, они появятся))) Они уже близко!

[Евгений Самсонов]

Кирилл Горелов, ну так сформулируйте их и найдите подходящий паттерн :)

Answer 3

[Adamos]

Тут такое дело: паттерны - это способы взаимодействия классов, а не метод написания самих классов.
Если вы нормально пишете классы, соблюдая SOLID, то для вас не будет большой проблемой наладить между ними взаимодействие, используя тот или иной паттерн, и переписывать основной код не понадобится.
Если же вы просто фапаете на GoF и пытаетесь вымучить в коде свои представления о том, как вы их поняли, мужественно преодолевая ООП - все равно получится говнокод, который придется несколько раз переписывать для вменяемой работы. Так что на этом этапе паттерны скорее вредны.