Почему я не мог защитить интерфейсных участников?
Вы не должны располагать BLoC в пределах WillPopScope.
Задача вашего «провайдера» - управлять удалением вашего BLoC: он должен закрывать потоки, когда виджет провайдера удаляется из дерева.
Это достигается за счет того, что ваш провайдер является методом StatefulWidget (с внутренним приватным InheritedWidget для раскрытия BLoC) и основным методом dispose.
См. Флаттер: как правильно использовать Inherited Widget? для примера (он не относится к BLoC и не имеет dispose, но идея похожа). [ 119]
10 ответов
Я думаю, что все ковали точку интерфейса, имеющего только общедоступных участников, никакие детали реализации. То, что Вы ищете, Редактирование абстрактного класса .
public interface IOrange
{
OrangePeel Peel { get; }
}
public abstract class OrangeBase : IOrange
{
protected OrangeBase() {}
protected abstract OrangePips Seeds { get; }
public abstract OrangePeel Peel { get; }
}
public class NavelOrange : OrangeBase
{
public override OrangePeel Peel { get { return new OrangePeel(); } }
protected override OrangePips Seeds { get { return null; } }
}
public class ValenciaOrange : OrangeBase
{
public override OrangePeel Peel { get { return new OrangePeel(); } }
protected override OrangePips Seeds { get { return new OrangePips(6); } }
}
: справедливо утверждать, что, если у нас есть PlasticOrange, который происходит из класса Украшение, это может только реализовать IOrange а не защищенный метод Семян. Это прекрасно. Интерфейс по определению является контрактом между вызывающей стороной и объектом, не между классом и его подклассами. Абстрактный класс так близок, как мы приходим к этому понятию. И это прекрасно. То, что Вы по существу предлагаете, является другой конструкцией на языке, через который мы можем переключить подклассы от одного базового класса до другого, не повреждая сборку. Мне это не имеет смысла.
при создании подкласса класса подкласс является специализацией базового класса. Это должно быть полностью осведомлено о любых защищенных членах базового класса. Но если Вы внезапно хотите выключить базовый класс, он не имеет никакого смысла, что подкласс должен работать с любым другим IOrange.
я предполагаю, что у Вас есть справедливый вопрос, но он походит на угловой случай, и я не вижу преимущества от него, чтобы быть честным.
Не видьте, почему можно было бы хотеть это. Если Вы хотите, чтобы производный класс обеспечил реализацию конкретного метода, пойдите для абстрактных базовых классов. Интерфейсы - просто это - интерфейсы. Государственный контракт, ничто иное. Думайте об интерфейсе со спецификации, которая описывает, как реализация должна смотреть на внешний мир. Спецификация для двухконтактного разъема не указывает (по крайней мере, я предполагаю, что), что это - внутренняя структура, должен быть похожим. Это просто должно быть совместимо с интерфейсом с гнездом разъема. 
(источник: made-in-china.com )
Поскольку это не имеет никакого смысла. Интерфейс является публично выставленным контрактом. Я - IThing, поэтому я выполню методы IThing, если спросили. Вы не можете попросить, чтобы IThing подтвердил, что выполняет методы, о которых он не может сказать Вам.
Интерфейсы существуют, чтобы позволить людям получать доступ к Вашему классу, не зная, какова конкретная реализация. Это полностью divorices реализация из контракта на передачу данных.
Поэтому все в интерфейсе должно быть общедоступным. Непубличные участники только полезны, если Вы имеете доступ к реализации и поэтому значительно не способствуете интерфейсному определению.
Взаимодействуйте через интерфейс участники общедоступный API; вещами как protected и т.д. являются детали реализации - и интерфейсы не делают , имеют любая реализация. Я подозреваю то, что Вы ищете, явная интерфейсная реализация:
public class NavelOrange : IOrange
{
public OrangePeel Peel { get { return new OrangePeel(); } }
OrangePips IOrange.Seeds { get { return null; } }
}
Интерфейс является контрактом, который обещает определенную функциональность клиентам. Другими словами, цель интерфейса состоит в том, чтобы смочь бросить тип в него и раздать его как этот для кодирования, которому нужны функции, гарантируемые тем интерфейсом. Так как клиентский код типа не может получить доступ к защищенным членам того типа, не имеет никакого смысла объявлять защищенные объекты в интерфейсе.
Интерфейс - все о том, что определенный объект может сделать, поэтому при использовании класса, который реализует тот интерфейс, разработчик будет ожидать, что все участники будут реализованы, таким образом, модификатор защищенного доступа ничего не будет означать для интерфейсов.
Существует звуковое суждение в текущем дизайне интерфейсов, который является, что это предлагает реализаторам большую гибкость. Помните, что очень часто интерфейсы записаны программистами платформы, и реализаторы являются различными людьми. Осуществлять реализацию было бы напрасно резко.
Путем реализации интерфейса тип указывает, что поддерживает определенный набор методов. Если бы какой-либо из этих методов не был общедоступен, то это не было бы доступно вызывающим сторонам, и таким образом тип не поддерживал бы интерфейс, как указано.
Интерфейс содержит только общедоступных участников. Защищенный означает то, что Вы объявляете, только доступно экземплярам производного класса и классу.