none
Общий подход к разработке библиотеки RRS feed

  • Вопрос

  • Проектируется библиотека классов и помимо разработки её самой, постоянно приходится следить за тем, что бы клиенту библиотеки был предоставлен только самый необходимый доступ к её объектам(и не больше). Это довольно утомительно, может есть какой ни будь общий подход в этом случае?
    4 февраля 2011 г. 8:12

Ответы

  • общий подход как раз и заключается в том чтобы разграничивать доступ на внешние и внутренние объекты

    т.е. не надо все делать public.

    фантазирую.

    есть 2 dll

    private.dll в одной все internal и private (внутренние объекты)

    public.dll во второй - все public (доступная для пользователя библиотека)

    private.dll разрешает "смотреть" internal Типы для сборки public.dll (friend assembly)

    таким образом надо меньше думать над тем что должно быть паблик, интерфесные вещи

    находятся в одной сборке, core объекты - в другой

    4 февраля 2011 г. 10:18

Все ответы

  • Не совсем понятен вопрос. Вы используете интерфейсы?
    4 февраля 2011 г. 8:53
  • общий подход как раз и заключается в том чтобы разграничивать доступ на внешние и внутренние объекты

    т.е. не надо все делать public.

    фантазирую.

    есть 2 dll

    private.dll в одной все internal и private (внутренние объекты)

    public.dll во второй - все public (доступная для пользователя библиотека)

    private.dll разрешает "смотреть" internal Типы для сборки public.dll (friend assembly)

    таким образом надо меньше думать над тем что должно быть паблик, интерфесные вещи

    находятся в одной сборке, core объекты - в другой

    4 февраля 2011 г. 10:18
  • Ups... А я не знал про дружественные сборки. Я то думал чего мне не хватает. Спасибо.
    4 февраля 2011 г. 10:28
  • Такое разделение тянет за собой вопрос - как решить, объект должен быть public или private?

    А для ограничения "самого необходимого доступа", т.е. определения public interface, есть интерфейсы (извините за тафталогию). Как Алексей Митеев выше написал. И фабрики/конфигураторы контейнеров.


    My blog
    4 февраля 2011 г. 10:38
  • Видимо, я не совсем понял логику вопроса, раз дружественные сборки — это то, что Вам было нужно и вы считаете это общим подходом к разработке библиотек. Однако учтите, что данный подход будет накладывать ограничения на имя файла или строгое имя сборки-клиента.
    4 февраля 2011 г. 10:43
  • да, и желательно потом это все слить вместе ilmerge(для уменьшения файлов поставки), и подписать, интересно будет ли работать дружественные сборки...
    4 февраля 2011 г. 10:46