Это своего рода простой ответ, но я думаю, что в этом суть настоящей проблемы - масштаб видимости. Просто держись там, пока я пробираюсь сквозь это!
Простой импорт модуля не обязательно должен предоставлять разработчику приложения доступ ко всем его классам или методам; если я не могу увидеть исходный код модуля, как я узнаю, что доступно? Кто-то (или что-то) должен сказать мне, что я могу сделать, и объяснить, как использовать те функции, которые мне разрешено использовать, иначе все это бесполезно для меня.
Те, кто разрабатывает абстракции более высокого уровня на основе фундаментальных классов и методов через импортированные модули, представлены со спецификацией DOCUMENT, а НЕ с фактическим исходным кодом.
В спецификации модуля описаны все функции, которые должны быть видны разработчику клиента. При работе с большими проектами и командами разработчиков программного обеспечения фактическая реализация модуля должна ВСЕГДА оставаться скрытой от тех, кто его использует - это черный ящик с интерфейсом для внешнего мира. Для пуристов OOD я считаю, что технические термины - это «разъединение» и «согласованность». Пользователь модуля должен знать только методы интерфейса, не обременяя себя деталями реализации.
Модуль НИКОГДА не следует менять без предварительного изменения его базового спецификационного документа, что может потребовать проверки / одобрения в некоторых организациях до изменения кода.
Как программист-хобби (сейчас ушедший в отставку), я запускаю новый модуль со спецификацией doc, фактически записанной в виде гигантского блока комментариев в верхней части модуля, это будет та часть, которую пользователь фактически видит в библиотеке спецификаций. Поскольку это только я, я еще не создал библиотеку, но это было бы достаточно легко сделать.
Затем я начинаю кодирование с написания различных классов и методов, но без функциональных тел - просто нулевых операторов print, таких как "print ()" - достаточно, чтобы модуль мог компилироваться без синтаксических ошибок. Когда этот шаг завершен, я компилирую завершенный нулевой модуль - это моя спецификация. Если бы я работал в команде проекта, я бы представил эту спецификацию / интерфейс для обзора и комментариев, прежде чем приступить к выделению тела.
Я уточняю тела каждого метода по одному и компилирую соответственно, гарантируя, что синтаксические ошибки будут исправлены немедленно на лету. Это также хорошее время, чтобы начать писать временную «основную» секцию выполнения внизу, чтобы протестировать каждый метод при его кодировании. Когда кодирование / тестирование завершено, весь тестовый код закомментирован до тех пор, пока он вам не понадобится снова, если потребуется обновление.
В реальной команде разработчиков блок комментариев к спецификации также появится в библиотеке управления документами, но это уже другая история. Дело в том, что вы как клиент модуля видите только эту спецификацию, а НЕ исходный код.
PS: задолго до начала времени я работал в оборонном аэрокосмическом сообществе, и мы сделали несколько довольно крутых вещей, но такие вещи, как проприетарные алгоритмы и логика управления чувствительными системами, были надежно зашифрованы и зашифрованы в супер-защищенных библиотеках программного обеспечения. У нас был доступ к интерфейсам модуля / пакета, но НЕ к телам реализации черного ящика Был инструмент управления документами, который обрабатывал все проекты системного уровня, спецификации программного обеспечения, исходный код и записи тестов - все это было синхронизировано вместе. Правительство предъявляло строгие требования к программному обеспечению качества. Кто-нибудь помнит язык под названием "Ада"? Вот сколько мне лет!