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

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

2 голосов
/ 25 июня 2009

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

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

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

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

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

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

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

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

Ответы [ 3 ]

2 голосов
/ 25 июня 2009

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

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

1 голос
/ 26 июня 2009

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

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

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

0 голосов
/ 05 июля 2009

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

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

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

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

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

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

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

...