Другие языки программирования и технологии
Зачем разделять файлы на реализацию и интерфейс в с++?
Программисты, объясните пожалуйста, Зачем разделять файлы на реализацию и интерфейс в с++?
Интерфейс – кнопка. Реализация – то, что произойдёт при нажатии на кнопку. Разделение кода позволяет менять реализацию, сохраняя интерфейс. Только одно это требует их разделять.
Максим Тюряга И (Бик)
Спасибо за ваше объяснение, но по сути вот для чего нам разбивать на h.файл и cpp.файл? Нельзя ли всё в одном файле описать?
Чтоб другой программист, который будет поддерживать Ваш код, не искал по коду что там и как устроено, а посмотрел всё в одном месте.
Если вы про .cpp и .h, то это не реализация и интерфейс, а реализация и определение.
Лепить все в один файл - это мешает в основном в тех случаях, когда потом приходится в этом файле что-то изменять.
Попробуйте и увидите.
Когда добавляете, скажем, новую функцию, или новый using namespace в файле .h, то IntelliSense в Visual Studio не сразу об этом узнает и не сразу начинает ее отображать в коде, где инклюден этот .h. Даже обычное построение и запуск отладки не помогают. Нужно скомпилировать этот файл со всеми заголовками, и тогда функция станет видна.
Если бы функция была реализована в .cpp, то достаточно запустить обычное построение/отладку - и функция точно стала бы доступна там, где инклюден заголовок с ее определением.
С другой стороны, если требуется написать модуль для быстрой интеграции в проект, и этот модуль в дальнейшем особо не планируется модифицировать, то, очевидно, проще его сделать одним файлом .h, который кинуть рядом в папку и проинклюдить. А был бы .cpp, то его мало кинуть в папку, его бы еще пришлось бы так или иначе добавлять в список компиляции (компилятор должен скомпилировать каждый cpp и в дальнейшем компоновщик должен все файлы obj скомпоновать в exe).
Реализация и интерфейс (точнее, бизнес-логика и интерфейс) - это другое. Под интерфейсом имеется в виду GUI. Под логикой - то, что происходит при взаимодействии с GUI (блокнот сохраняет файл и т. д.). Они должны быть разделены для того, чтобы при изменении интерфейса не приходилось грузить себя бизнес-логикой, как и наоборот, и чтобы это вообще могли разные люди делать.
В вебе имеет смысл пойти дальше и еще отдельно выделить Controller. Там всегда сперва юзер проходит по ссылке, а уже потом в ответ получает View (интерфейс страницы сайта) с Model (бизнес-логика). По разным ссылкам разные связки View-Model. Вот в Controller и задаются соответствия, по какой ссылке что вернуть в ответ. Это паттерн MVC - Model-View-Controller.
На десктопе это избыточно. Окна вызываются непосредственно друг из друга (нажали кнопку - открылось второе окно), а не через общую "точку управления" (через ссылкиы). MVC не нужен, достаточно MV.
Лепить все в один файл - это мешает в основном в тех случаях, когда потом приходится в этом файле что-то изменять.
Попробуйте и увидите.
Когда добавляете, скажем, новую функцию, или новый using namespace в файле .h, то IntelliSense в Visual Studio не сразу об этом узнает и не сразу начинает ее отображать в коде, где инклюден этот .h. Даже обычное построение и запуск отладки не помогают. Нужно скомпилировать этот файл со всеми заголовками, и тогда функция станет видна.
Если бы функция была реализована в .cpp, то достаточно запустить обычное построение/отладку - и функция точно стала бы доступна там, где инклюден заголовок с ее определением.
С другой стороны, если требуется написать модуль для быстрой интеграции в проект, и этот модуль в дальнейшем особо не планируется модифицировать, то, очевидно, проще его сделать одним файлом .h, который кинуть рядом в папку и проинклюдить. А был бы .cpp, то его мало кинуть в папку, его бы еще пришлось бы так или иначе добавлять в список компиляции (компилятор должен скомпилировать каждый cpp и в дальнейшем компоновщик должен все файлы obj скомпоновать в exe).
Реализация и интерфейс (точнее, бизнес-логика и интерфейс) - это другое. Под интерфейсом имеется в виду GUI. Под логикой - то, что происходит при взаимодействии с GUI (блокнот сохраняет файл и т. д.). Они должны быть разделены для того, чтобы при изменении интерфейса не приходилось грузить себя бизнес-логикой, как и наоборот, и чтобы это вообще могли разные люди делать.
В вебе имеет смысл пойти дальше и еще отдельно выделить Controller. Там всегда сперва юзер проходит по ссылке, а уже потом в ответ получает View (интерфейс страницы сайта) с Model (бизнес-логика). По разным ссылкам разные связки View-Model. Вот в Controller и задаются соответствия, по какой ссылке что вернуть в ответ. Это паттерн MVC - Model-View-Controller.
На десктопе это избыточно. Окна вызываются непосредственно друг из друга (нажали кнопку - открылось второе окно), а не через общую "точку управления" (через ссылкиы). MVC не нужен, достаточно MV.
Канат Каныбек
Водяной Змей, вы совсем не о том ведёте речь.
Похожие вопросы
- интерфейс + реализация + прикладная программа в С++
- Какой смысл в разбиении класса на интерфейс и реализацию?
- Объектно-ориентированное программирование. Программа и ее интерфейс.
- Как на PHP получать пути к файлам из массива names в теге input при загрузке некольких файлов?
- C++ Файлы. помогите чем можете . за хороший ответ подарю денюжку
- помогите написать bat-файл.
- фотошоп: как пользоваться правильно пакетной обработкой файлов?
- Помогите написать bat файлы, срочно надо, сам изучить уже не успеваю
- Как определить что файл имеет зеркальное расширение? Особенно полезно будет для школьников и пожилых людей
- Нужен bat файл, чтобы переименовал все txt файлы в папке, заменяя имя на первую строку содержимого файла