Передача класса против передачи экземпляра; Простой дизайн API - PullRequest
0 голосов
/ 07 декабря 2011

Введение

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

Информация

Я переделываю проект в Android, который я делал некоторое время назад, чтобы сделать часть кода более пригодной для повторного использования (постоянно экспериментируя с новыми разработками «API» для практики).

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

Мне понравилось это, потому что это позволяет моей библиотеке управлять всем объектом и устраняет воздействие экземпляра на внешний код, но также мешает мне настраивать реализацию с помощью параметров конструктора (скорость перемещения, направление и т. Д.). (Одним из решений этой проблемы является передача какого-то массива, из которого реализация может получить данные, когда он создается библиотекой, но я ненавижу библиотеки, которые требуют, чтобы вы передавали параметры в каком-то облачном и трудном для восприятия виде. Конфигурационное дерьмо во время проверки во время компиляции типа "скорость: 90; herp: derp".)

Мой вопрос

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

1 Ответ

0 голосов
/ 07 декабря 2011

Если вы используете DI (Dependency Injection), жизненный цикл объектов обрабатывается вне библиотеки. Я предпочитаю этот подход, если только жизненный цикл не очень прост и не нужно настраивать компонент.

...