Каковы преимущества и недостатки использования заголовочных файлов? [закрытый]
У меня был некоторый опыт в таких языках программирования, как Java, C#, Scala, а также в некоторых языках программирования более низкого уровня, таких как C, C++, Objective - C.
мое наблюдение заключается в том, что языки низкого уровня пытаются отделить заголовочные файлы и файлы реализации, в то время как другой язык программирования более высокого уровня никогда не отделяет его. Эти языки используют некоторые идентификаторы, такие как public, private, protected, чтобы попытаться выполнить задания заголовочных файлов. C++ также имеет как идентификаторы, так и заголовочные файлы а также
Я видел одно преимущество использования файла заголовка (в какой-то книге, например, Code Complete), они говорят о том, что с помощью файлов заголовков люди никогда не могут смотреть на наш файл реализации, и это помогает с инкапсуляцией.
недостаток в том, что он создает слишком много файлов для меня. Иногда, похоже, многословный.
Это просто моя мысль, и я не знаю, есть ли какие-либо другие преимущества и недостатки, которые люди когда-либо видят и работают с заголовочным файлом
этот вопрос может не относиться непосредственно к программированию, но я думаю, что если я смогу лучше понять программирование для интерфейса, разработки программного обеспечения.
4 ответов
Я не уверен, какой именно вопрос вы задаете, поэтому я попытаюсь перефразировать его:
в чем преимущество размещения публичной информации в отдельном файле (заголовке или интерфейсе), а не просто маркировки информации как публичной или частной, где бы она ни появлялась?
основным преимуществом наличия отдельного интерфейса или файла заголовка является то, что это снижает когнитивную нагрузку на читателя. Если вы пытаетесь понять большое система, вы можете решать один реализация файл за раз, и вам нужно прочитать только интерфейсы других реализаций / классов / модулей, от которых он зависит. Это основное преимущество, и языки, которые не требуют отдельных файлов интерфейса (например, Java) или даже не могут экспресс интерфейсы в отдельных файлах (например, Haskell) часто предоставляют такие инструменты, как Doxygen или Haddock, чтобы отдельный интерфейс для чтения создавался из реализация.
Я сильно предпочитаю языки, такие как Standard ML, Objective Caml и Modula-2/3, где есть отдельный файл интерфейса, доступный для изучения. Наличие отдельных файлов заголовков в C также хорошо, но не так хорошо, потому что в целом файлы заголовков не могут быть проверены независимо компилятором. (Файлы заголовков c++ менее хороши, потому что они позволяют частной информации, такой как частные поля или реализации встроенных методов, просачиваться в заголовок файлы, и таким образом общественная информация становится разбавленной.)
это фольклор в мире языкового дизайна, что для типичных статически типизированных языков только около 10% информации в модуле является общедоступной (измеряется строками кода). Помещая эту информацию в отдельный файл заголовка, вы уменьшаете рабочую нагрузку читателя примерно в десять раз.
они позволяют распространять API библиотеки, чтобы компилятор мог компилировать правильный код.
Как и в C, вместо того, чтобы включать всю реализацию, вы просто включаете определение того, что такое в библиотеке при подключении.
в этом смысле преимущества в основном для компилятора. Следовательно, вы устанавливаете двоичную библиотеку в say /lib и заголовки в вашем пути поиска include. Вы говорите, в время работы, ожидать, что эти символы с этим соглашением о вызове должны быть доступны.
когда они не требуются компилятором / компоновщиком / интерпретатором, Соглашение для этого языка является лучшим способом сделать это, потому что это то, что ожидают найти другие программисты. Ожидается обычный.
языки, такие как C#, включают возможность проверить библиотеки для информации из двоичного blob, поэтому во многих из этих языков вам не нужны заголовки. Такие инструменты, как Сесил для C# также позволяют проверить библиотеку самостоятельно (и даже изменить его).
короче говоря, некоторые языки удаляют преимущества заголовков и позволяют проверять библиотеку для всех времени компиляции информация, необходимая для обеспечения связи кода соответствует тем же спецификациям интерфейса/api.
они используют некоторые идентификаторы, такие как public, private, protected для выполнения заданий заголовочных файлов.
Я думаю, что вы ошибаетесь: C++, например, по-прежнему имеет public private и protected, но обычно разделяют реализацию из интерфейса с помощью файла заголовка (хотя это не относится к шаблонам функций).
Я думаю, что в целом неплохо отделить интерфейс от реализации при создании библиотек, так как вы тогда никогда не раскрывайте клиенту внутреннюю работу чего бы то ни было, и, таким образом, клиент никогда не сможет сознательно создать код, зависящий от имплементации. Выбор, если вы хотите разделить его, зависит от вас. Я должен признать, что для моего собственного кода (небольших программ, которые я пишу для себя) я не часто использую его.
в контексте c реализация файла заголовка приносит много читаемости в нашей программе, и это становится легко понять. Если это способ систематически писать наш код, а файл заголовка приносит абстракцию, стандартизацию и свободную связь между нашим основным файлом функций(.С) и другие (.c) файлы, которые мы используем.