Ответ

G_Z 03.11.2015 19:58 / 03.11.2015 19:59

— У объектов есть поведение (интерефейс). Фактически это жесткий контракт, который жестко фиксирует свойства объекта. Любой, кто взаимодействует с объектом должен иметь гарантию, что контракт не поменяется в процессе взаимодействия с объектом. Манкипатчинг нарушает нарушает контракт и придает объекту свойства, которых у него не было. С точки зрения ООП-подхода это плохо.

Плохо.
Но интерфейс пользовательских объектов может меняться совершенно сводобно хоть после каждого вызова.

Вызывало ли это проблемы хоть раз?
Думаю, нет.

— Допустим, что мы разрешили нарушать контракт. Тогда возникает вопрос: что нам делать, если два объекта добавили в системный класс метод с одним и тем же именем, но с разным интерфейсом (входными и выходными параметрами или логикой получения результата). Мы сразу получили некорректную работу одного из объектов, потому что интерфейс не тот, который он ожидает. Отлаживать такие проблемы будет крайне сложно: понять кто и в каком порядке напихал методы в системные классы та еще задачка.

Да, многократное изменение может быть проблемой.
Её можно решить, к примеру:
1. запретом многократной модификации: меняешь — меняй единожды;
2. возможностью через reflection выяснить были ли изменения.

С учётом того, что при патчинге широко распространена практика предварительной проверки окружения, это опять же не должно стать проблемой.


Лично я не вижу альтернатив патчингу в задаче, когда необходимо расширить интерфейс класса или объекта.
Вот хочу я иметь метод in у каждого объекта.
Для массивов он проверяет наличие элемента, для строк и чисел — наличие подстроки, и так далее.
Метод удобный и с точки зрения главенства интерфейса над классом правильный — я буду работать через метод с объектом, не обращая внимания на его класс.

Даже если будет возможность наследования от нативных классов, я не получу желаемого результата.
Исключительно в случае замены всех нативных методов, возвращающих нативные типы своими наследниками и своими типами.

Задача мне кажется вполне разумной, а инструмента кроме патчинга для ей решения нет.
Возможно я ошибаюсь.

---