С выгодой для себя или просто вносить свой вклад в поддержание работоспособности сети? Последнее всегда актуально, так как новые блоки всегда будут создаваться в среднем каждые 10 минут.
Это нормально, что по EDI есть мало открытой хорошей информации. Вокруг него такой бизнес построен, что спецификацию хорошую можно получить только за деньги.
Для родительского класса не важно, для кого открыто его состояние. Если оно открыто, то на него уже могут быть зависимости. Лучше эти зависимости формализовать через интерфейс.
Проблему модификации поведения существующих методов? Решение с protected и protected virtual безусловно самое очевидное и простое. Но я уже описывал его недостатки — это открытие (хоть и не всем) того, что по абстракции должно быть сокрыто, потеря гибкости в реализации публичного интерфейса.
Более корректным решением было бы выделение потенциальной проблемной области в модуль, который инжектится снаружи и работает через публичный интерфейс. Тогда для модицикации поведения понадобится написать другую реализацию интерфейса и передавать ее вместо старой.
Если грамотно разбить систему на модули, то тогда не будет такой проблемы, что есть какой-то интерфейс на 100 методов и никому не охота писать еще одну его реализацию. Реализации в идеале должны быть меньше 200 строк кода (условно), чтобы создание альтернативных реализаций не было проблемой.
Что касается проблемы использования private или protected, то для полей — всегда private, для методов protected обычно используется только если есть какой-то кусок функциональности, который не должен быть публичным, но который потомки могли бы вызывать в определенный момент. Модификацию поведения через protected virtual лучше не делать вообще.
А значит все что вы говорите, касается безопасности системы.
Модификаторы уровня доступа придумали не для защиты от идиотов или злоумышленников. Они сделаны для удобства нормальных пользователей (программистов), чтобы они знали и видели ровно столько, сколько требуется и не более. Чтобы было видно, где заканчивается абстракция и начинается реализация.
В вашем примере класс-потомок не нужен. Список должен приходить извне — полный или отфильтрованный. Попробуйте поменьше думать о наследовании и побольше о композиции.
опять же, приходим к тому, что private нужен лишь для того, что бы скрыть запретить третьим разработчикам...
Т. е. вы считаете, что внутри библиотеки, которую разрабатывает один человек или одна команда, можно не заморачиваться, открывать состояние объектов и разрешать модифицировать их поведение, «потому что тут все свои»? Если речь идет об ООП, то в этой парадигме программисты работают с объектами, а не напрямую с их состоянием. Состояние должно быть доступно только самому классу, все остальные должны работать с ним по интерфейсу. Если интерфейс недостаточно гибкий, то нужно менять интерфейс, а не ломать абстракцию напрямую.
Родительский класс лишится возможности изменить собственную реализацию без риска поломать все дерево дочерних классов. Это может обернуться проблемами в будущем во время поддержки, изменения требований или исправления ошибок.
Изменение полей и методов с private на protected не решает проблему непродуманного интерфейса, а скрывает ее, заставляя реализовывать этот интерфейс определенным способом.
Изменение private полей родительского класса на protected ни к чему хорошему не приведет. Родительский класс больше ничего не сможет с этим полем сделать — ни переименовать, ни изменить тип, ни разбить на несколько полей или вообще удалить. Получается что с одной стороны у него есть публичный контракт — интерфейс, который нужно реализовать, а с другой есть неявный контракт — protected поля и методы, которые ограничивают реализацию интерфейса, диктуя определенный подход.
