разоблачение или сокрытие объектов зависимостей?

Question

Общий сценарий: у меня есть библиотека, которая использует другие библиотеки. Например, математическая библиотека (назовем ее foo), которая использует numpy.

Функции foo могут:

• вернуть объект numpy (чистый или унаследованный переопределение)
• вернуть список
• возвращает реализованный foo объект, который ведет себя как numpy (выполняет делегирование)

Три решения также можно переформулировать как:

• foo проходит через внутренне используемый объект, ясно заявляя, что его зависимость от библиотеки также является зависимостью API (поскольку он возвращает объекты, подчиняющиеся интерфейсу библиотеки numpy)
• foo использует общее подмножество объектов, которые являются частью языка.
• foo полностью скрывает то, что использует внутри. Ничто в базовых библиотеках не выходит из библиотеки foo в код клиента.

Мы, конечно, находимся в плюсе-минусе. Прозрачный или непрозрачный? сильная связь с базовыми инструментами или нет? Я знаю упражнение, но я нахожусь в процессе, чтобы сделать этот выбор, и я хочу поделиться мнениями, прежде чем принимать решение. Предложения, идеи, личный опыт очень ценятся.

Answer 1

Поскольку вы говорите о возвращаемых значениях, это не совсем о "внутренних объектах" - вам просто нужно документировать интерфейсы, которые будут поддерживать ваши возвращаемые объекты (это нормально, если это подмножество numpy.array или что-то еще ;-). Я не рекомендую возвращать ссылку на ваши внутренние изменяемые атрибуты и документировать, что мутаторы работают, чтобы косвенно изменять ваш собственный объект (и НЕ документировать это не намного лучше), что приводит к слишком сильному сцеплению в будущем.

Если вы говорите о реальных внутренних объектах, я бы рекомендовал Закон Деметры - в упрощенном чтении, если код клиента a.b.c.d.e.f(), то что-то очень неправильно ("только один точка "может быть иногда экстремальной, но" четыре прямо "). Опять же, проблема заключается в сильной связи - лишает вас возможности изменить внутреннюю реализацию даже незначительными способами, не нарушив миллион клиентов ...!

Answer 2

Главный вопрос, о котором я бы подумал, это то, сколько из вашей библиотеки вернуло бы numpy объекты? Если бы оно распространялось, я бы пошел с прямым возвратом numpy, поскольку вы так привязаны к numpy, что вы могли бы также сделать это явным. Кроме того, это, вероятно, облегчит использование других библиотек на основе numpy. Если, с другой стороны, у вас есть только несколько методов, которые возвращали бы numpy, я бы выбрал либо numpy-подобный объект, либо список, возможно, numpy-подобный объект.