параметры конструктора против вызовов методов

Question

Я пишу URL-маршрутизатор в Python 3.1 и спрашиваю себя, не является ли дело вкусом использовать один из следующих вариантов:

Кортежи как параметры конструктора:

router = Router( 
    (r"/item/{id}", ItemResource()),
    (r"/article/{title}", ArticleResource())
)

Вызов метода

router = Router()
router.connect(r"/item/{id}", ItemResource())
router.connect(r"/article/{title}", ArticleResource())

Видите здесь какие-либо преимущества или недостатки?

Answer 1

Я предпочитаю передавать кортежи конструктору по двум причинам, которые Алекс не упомянул (по крайней мере, явно).

1. читаемость. Для любого читателя кода ясно, что для экземпляра Router требуется список маршрутов, которые можно использовать.

2. Потеря связи. Код клиента не должен беспокоиться об инициализации экземпляров маршрутизатора. Это ответственность класса Router.

Если вам это кажется громоздким, я бы порекомендовал разбить класс Router на более мелкие классы и передать экземпляры этих классов в Router.__init__. Например, здесь у вас может быть класс RoutesList:

routes = RoutesList((r"/item/{id}", ItemResource()),
                    (r"/article/{title}", ArticleResource()))

router = Router(routes)

Это дает вам гибкость двухфазной конструкции, о которой упоминал Алекс, но также предотвращает ответственность клиентского кода от инициализации класса маршрутизатора. Это все еще сохраняет читабельность, потому что вы должны читать назад, чтобы увидеть, что такое routes, а не вперед (если вы не помните). У него есть дополнительное преимущество: если вы решите изменить способ представления своих маршрутов, класс Router не должен изменяться вообще: все такие изменения должны быть инкапсулированы в классе RoutesList (или, возможно, даже в неопределенный класс маршрута).

Или маршруты могут быть просто списком кортежей, и у вас может быть функция уровня модуля для сопоставления маршрута с контроллером;)

Answer 2

Традиционное представление ООП состоит в том, что конструктор должен гарантировать, что объект находится в своем конечном, пригодном для использования состоянии - то есть состояние может измениться, если, конечно, существуют динамически изменяющиеся требования (например, есть ли disconnect)метод с этим connect, и фактическое требование приложения для включения динамического изменения маршрутизации в ходе операций?), но оно «должно» оставаться пригодным для использования с момента рождения объекта и до его исчезновения.

В реальном мире альтернативный шаблон, иногда известный как «двухфазное построение» (хотя здесь, конечно, это может быть больше, чем просто две фазы, поскольку вы продолжаете называть connect;-) может иметь некоторые преимущества с точки зрения гибкости - сохранение и удаление объектов, правильное построение их в зависимости от конфигурационных файлов, упрощение внедрения зависимостей и проверки (и, следовательно, тестирования).

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

Answer 3

Поскольку вы создаете маршрутизатор для маршрутизации веб-запроса на соответствующий ресурс, вы также можете посмотреть маршруты.Это позволяет сопоставить URL-адреса с действиями вашего приложения.

• http://routes.groovie.org/

Answer 4

Если параметр не является обязательным, вы можете использовать метод вызова метода, который был бы более гибким, если вам нужно добавить больше в будущем.

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