Какой вариант дизайна лучше использовать при написании фреймворка?

Question

Я разрабатываю фреймворк (на Java, но вопрос общий), в котором я предоставлю набор интерфейсов для реализации клиентами.Функции в фреймворке будут зависеть от того, как будут сконструированы классы реализации, то есть они зависят от этих реализаций для предоставления других экземпляров интерфейсов.

Например, у меня могло бы быть:

Interface IContribution {
   public IMyStuff getMyStuff();
   public IHelper getHelper();
}

Interface IMyStuff {
     public void doSomeMethod(IHelper helper);
}

Как я могу убедиться, что эти экземпляры IMyStuff и IHelper доступны?

Одним из методов было бы создать методы 'getter' в интерфейсе и в моей среде тщательно проверять наличие возвращаемых нулевых объектов.

Другим вариантом было бы создать абстрактные классы, реализующие фабрику, которая вызывает (используя шаблоны стратегии) методы интерфейса, которые должны быть реализованы.Но это противоречит тому факту, что у меня есть интерфейс в первую очередь.Затем клиенты должны использовать абстрактный класс.Но они могли бы обойти это, используя интерфейс вместо абстрактного класса.Поэтому я должен предоставлять не интерфейс, а только абстрактный класс...

Итак, каковы ваши идеи по этому поводу, каков прагматичный подход к этому?

Answer 1

Как я могу убедиться, что эти экземпляры IMyStuff и IHelper доступны?

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

Answer 2

Чтобы создать хороший фреймворк, вам нужно одновременно создавать приложение на его основе.Таким образом, вы будете знать и понимать, какую боль перенесут ваши клиенты, ПРЕЖДЕ чем она будет им навязана.

Другими словами, начните с:Как бы мои клиенты работали с этим приложением?Как им нужно с этим работать?

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

Answer 3

Вы не можете обеспечить это только с помощью интерфейсов, никакого поведения там нет.

Я согласен с философией защитного программирования в Фреймворке, помогающем разработчикам избегать ошибок.

Вы можете предоставить заводской объект:

public class MyPoliceman {
    public IContribution makeContributor( IMyStuff stuffer, IHelper helper)
                    throws BadAssociatesException {

     // check validity of stuffer and helper here, throw exceptions if null
    }
}

Тогда, по крайней мере, мы сможем проверить наличие нулей и т.д.

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