Encapsulation VS Inheritance - Как использовать защищенную функцию?

Question

В языках ООП, таких как C # или VB.NET, если я создаю свойства или методы в суперклассе protected , я не могу получить к ним доступ в своей форме - они могут быть доступны только в моем классе который наследует от этого суперкласса.

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

Как правильно сделать это?

Answer 1

" нужно сделать их общедоступными, что препятствует инкапсуляции "

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

Вот что важно. Инкапсуляция не означает сокрытие. Защищенные и частные не являются неотъемлемой частью хорошей инкапсуляции. Вы можете сделать хороший дизайн, когда все открыто (например, так работает Python).

Защищенные / частные материалы - в основном - об управлении интеллектуальной собственностью: готовы ли вы совершить обязательство (в юридически обязательном порядке, «увидимся в суде, если это не сработает») путь) к интерфейсу? Если в разработке вашего программного обеспечения участвуют юристы, вам нужно добавить защиту и частную защиту к вещам, которым вы не привержены.

Если вам не нужно справляться с юристами, подумайте о правильной инкапсуляции, но оставьте все публично.

Answer 2

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

Это все равно, что сказать, что у меня есть автомобиль (автомобиль) с защищенным рулевым колесом, поэтому я не могу получить к нему доступ. Машина мне не нужна.

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

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

Answer 3

Извините, неясно, что вы имеете в виду под "моей формой" - Какова связь между вашей формой и вашими двумя классами? Если ваши классы являются элементами управления в том же проекте, и вы хотите получить доступ к свойствам из формы, вы должны использовать ключевое слово «internal».

Answer 4

Существует как минимум три способа ограничения количества пользователей, которые могут использовать какой-либо конкретный метод экземпляра для отдельных экземпляров класса:

<Ол>

Определите метод как `protected`,` internal` или `private`. В первом случае метод экземпляра можно будет использовать только из методов производного класса того же экземпляра; во втором случае все классы в сборке будут иметь доступ к этим методам, а внешние классы не будут; в третьем случае никакие внешние классы, даже производные в той же сборке, не будут иметь доступа, если только их код не вложен в декларирующий класс.

Определите метод как `public`, но классы, которые создают экземпляры, сохраняют их частными и никогда не выставляют их внешнему миру. Любой, кто хочет вызвать метод экземпляра объекта, должен иметь экземпляр для его вызова. Если класс содержит экземпляры, но никогда не предоставляет прямых ссылок на них, единственными методами экземпляров, которые могут когда-либо использоваться в этих экземплярах, будут те, которые сами классы хранения используют.

Определите метод как `public`, но у вас есть конструктор, который принимает местоположение, в котором может храниться один или несколько делегатов для закрытых методов. Код с доступом к этим делегатам сможет вызывать методы, на которые он ссылается, но другой код не будет (за исключением использования Reflection способами, которые, я думаю, могут использоваться только в сценариях полного доверия).

Если в сценариях с неполным доверием Reflection разрешит привязывать несвязанных делегатов к произвольным экземплярам объектов, можно использовать вложенные классы для усиления # 3, чтобы иметь доступ к полям private для получить незаконный доступ к функциям private ; это определенно будет запрещено вне сценариев полного доверия.