Раньше когда я начинал изучать ООП (в Lazarus), я думал, что ООП - это и есть всякие окошки, кнопки, поля ввода, и прочее. Но теперь уже я понимаю, что ООП - это просто метод программирования. Классы имеют поля и методы, что для огромного и сложного приложения просто необходимо.
Но я все равно не понимаю как набор классов становится приложением. Допустим, у меня есть огромная программа с кучей классов, методов. К этой программе подключаются дополнительные модули, динамические библиотеки. НО на данном этапе написания я могу вводить/выводить информацию в поля экземпляров какого-то класса только через консоль.
Как же тогда реализуется нормальный интерфейс приложения? В Lazarus и Visual Basic все было просто: берешь элемент, кидаешь его на форму, пишешь обработчик и всё готово. Но как я уже потом понял - это неправильно. Сначала нужно написать программу, а потом уже придумывать и создавать интерфейс.
Так вот как на самом деле происходит создание интерфейса? Например, есть у меня большая программа на С++. Мне нужно создать интерфейс. Я все объекты, формы, и тд и тп вручную что ли должен прописывать?
А если не прописывать вручную, а создавать отдельно, то как его потом подключать к самой программе?
Другие языки программирования и технологии
Объектно-ориентированное программирование. Программа и ее интерфейс.
I. Как делаются программы.
По хорошему, создание программы должно проходить через 5 этапов:
1. Анализ требований - Там вы думаете, что должна делать ваша программа и какие цели она должна выполнять. Или же вы разговариваете с заказчиком и добиваетесь от него конкретных задач и составляете техническое задание.
2. Проектирование - Вы уже продумываете, как программа должна работать, продумываете модули, архитектуру приложения (в случае ООП это классы), думаете как решить эти задачи.
3. Кодирование - Вы воплощаете ваши идеи в реальность, пишите программу.
4. Тестирование - Вы проверяете и тестируете свою программу на всякие ошибки и баги и всячески стараетесь их выловить
5. Апробация - вы начинаете использовать эту программу, передаёте её заказчику. Если вы делали программу для фирмы, то идёте туда и учите местных тётенек с ней работать.
Эти этапы не всегда идут линейно, порой первые 4 этапа прогоняются несколько раз. Смотрите методики разработки ПО.
II Интерфейс.
Интерфейс - это всего лишь часть программы отвечающая за взаимодействие с пользователем. Можно сделать прекрасную программу, которая работает через командную строку, можно сделать программу которая будет работать в окошках.
III ООП
Как уже выше сказали, ООП это всего-лишь модная парадигма, к которой большинство современных языков и фреймворков принуждают. Это просто способ организовать части вашей программы. По сути вы разбиваете программу на маленькие модули, которые имеют свои данные, свои функции и как-то общаются с другими модулями.
ООП это не окошки, это просто так классы реализованы. На самом деле класс может быть чем угодно.
IV Как классы становятся программами.
Программа - это алгоритм, который выполняет компьютер. Компьютер понимает только язык машинных кодов. Чтобы то, что вы понаписали работало, вы скармливаете вашу программу компилятору или интерпретатору, который перерабатывает программу написанную вами на язык машинных кодов. Перед компиляцией, программа попадает в комповщик, который все ваши модули в один большой модуль и передаёт его компилятору. (Говорю упрощенно немного)
V С++
На чистых плюсах ты графического интерфейса не добьёшся (ну разве что ты не сможешь как-то через ассемблерные вставки (хотя это уже не плюсы) как-то добиться взаимодействия с видеокартой (как, я даже не представляю, но это и не нужно). Если в Visual Basic и Lazarus это есть из коробки, то в С++ этого нет. Не для этого С++ создавался. Дед Мазай вам уже представил некоторые варианты библиотек и фреймворков для построения интерфейсов. Есть ещё GTK.
P.S.
Вам не стоило обучаться сразу с Lazarus и Visual Basic, поскольку вы упустили много деталей, не поработали с консолькой, от этого у вас представление, что ООП - это окошки. Работа с командной строкой более традиционна для языков программирования, в каждом языке можно найти функции ввода/вывода в консоль.
По хорошему, создание программы должно проходить через 5 этапов:
1. Анализ требований - Там вы думаете, что должна делать ваша программа и какие цели она должна выполнять. Или же вы разговариваете с заказчиком и добиваетесь от него конкретных задач и составляете техническое задание.
2. Проектирование - Вы уже продумываете, как программа должна работать, продумываете модули, архитектуру приложения (в случае ООП это классы), думаете как решить эти задачи.
3. Кодирование - Вы воплощаете ваши идеи в реальность, пишите программу.
4. Тестирование - Вы проверяете и тестируете свою программу на всякие ошибки и баги и всячески стараетесь их выловить
5. Апробация - вы начинаете использовать эту программу, передаёте её заказчику. Если вы делали программу для фирмы, то идёте туда и учите местных тётенек с ней работать.
Эти этапы не всегда идут линейно, порой первые 4 этапа прогоняются несколько раз. Смотрите методики разработки ПО.
II Интерфейс.
Интерфейс - это всего лишь часть программы отвечающая за взаимодействие с пользователем. Можно сделать прекрасную программу, которая работает через командную строку, можно сделать программу которая будет работать в окошках.
III ООП
Как уже выше сказали, ООП это всего-лишь модная парадигма, к которой большинство современных языков и фреймворков принуждают. Это просто способ организовать части вашей программы. По сути вы разбиваете программу на маленькие модули, которые имеют свои данные, свои функции и как-то общаются с другими модулями.
ООП это не окошки, это просто так классы реализованы. На самом деле класс может быть чем угодно.
IV Как классы становятся программами.
Программа - это алгоритм, который выполняет компьютер. Компьютер понимает только язык машинных кодов. Чтобы то, что вы понаписали работало, вы скармливаете вашу программу компилятору или интерпретатору, который перерабатывает программу написанную вами на язык машинных кодов. Перед компиляцией, программа попадает в комповщик, который все ваши модули в один большой модуль и передаёт его компилятору. (Говорю упрощенно немного)
V С++
На чистых плюсах ты графического интерфейса не добьёшся (ну разве что ты не сможешь как-то через ассемблерные вставки (хотя это уже не плюсы) как-то добиться взаимодействия с видеокартой (как, я даже не представляю, но это и не нужно). Если в Visual Basic и Lazarus это есть из коробки, то в С++ этого нет. Не для этого С++ создавался. Дед Мазай вам уже представил некоторые варианты библиотек и фреймворков для построения интерфейсов. Есть ещё GTK.
P.S.
Вам не стоило обучаться сразу с Lazarus и Visual Basic, поскольку вы упустили много деталей, не поработали с консолькой, от этого у вас представление, что ООП - это окошки. Работа с командной строкой более традиционна для языков программирования, в каждом языке можно найти функции ввода/вывода в консоль.
Значиццо так.
Вся программная логика должна быть реализована в отдельных, не зависящих от интерфейса классах.
А как ты сделаешь интерфейс - дело десятое. Хочешь писать его ручками - флаг тебе в эти ручки. Хочешь сделать его на каком-то конструкторе - тоже дерзай. Это абсолютно неважно.
Вся программная логика должна быть реализована в отдельных, не зависящих от интерфейса классах.
А как ты сделаешь интерфейс - дело десятое. Хочешь писать его ручками - флаг тебе в эти ручки. Хочешь сделать его на каком-то конструкторе - тоже дерзай. Это абсолютно неважно.
"Я все объекты, формы, и тд и тп вручную что ли должен прописывать?"
Нет, конечно. В развитых средах программирование для этого есть визуальное проектирование. Просто перетаскиваешь нужные элементы из панели на их места.
Нет, конечно. В развитых средах программирование для этого есть визуальное проектирование. Просто перетаскиваешь нужные элементы из панели на их места.
огромные и сложные приложения можно писать без всяких классов. объектно-ориентированное программирование как парадигма стало модным дай бог лет тридцать назад, а до тех пор нормально обходились без него.
а создание интерфейсов взаимодействия с пользователем обычно ведётся параллельно и вместе с разработкой основного функционала программы. просто на этапе проектирования надо прикинуть, какие интерфейсы понадобятся, и как они будут увязаны между собой и с внутренним представлением данных.
а создание интерфейсов взаимодействия с пользователем обычно ведётся параллельно и вместе с разработкой основного функционала программы. просто на этапе проектирования надо прикинуть, какие интерфейсы понадобятся, и как они будут увязаны между собой и с внутренним представлением данных.
В Lazarus и Visual Basic есть стандартные (для этих систем) библиотеки классов для создания GUI (графический интерфейс), а в стандартной библиотеке С++ таких классов нет. Надо использовать сторонние библиотеки, а их много. К библиотекам иногда прилагается IDE с удобным редактором форм.
Например,
Qt и Qt Creator https://ru.wikipedia.org/wiki/Qt_Creator
https://ru.wikipedia.org/wiki/Ultimate++
https://ru.wikipedia.org/wiki/WxWidgets
https://ru.wikipedia.org/wiki/C++_Builder - это коммерческая система. Раньше Builder был копией Delphi (отличие только в языке программирования), последние версии я не видел.
Например,
Qt и Qt Creator https://ru.wikipedia.org/wiki/Qt_Creator
https://ru.wikipedia.org/wiki/Ultimate++
https://ru.wikipedia.org/wiki/WxWidgets
https://ru.wikipedia.org/wiki/C++_Builder - это коммерческая система. Раньше Builder был копией Delphi (отличие только в языке программирования), последние версии я не видел.
Nursultan .
Ещё можно использовать вызовы Windows API. Но это имеет следующие недостатки:
- программировать сложно, громоздкий код. Windows API - это обычные функции, а не классы С++.
- отсутствие переносимости. Библиотеки, перечисленные в списке из моего ответа, являются кроссплатформенными (возможно, кроме C++Builder), а Windows API - это жёсткая привязка к Windows (если не учитывать эмулятор Wine).
- программировать сложно, громоздкий код. Windows API - это обычные функции, а не классы С++.
- отсутствие переносимости. Библиотеки, перечисленные в списке из моего ответа, являются кроссплатформенными (возможно, кроме C++Builder), а Windows API - это жёсткая привязка к Windows (если не учитывать эмулятор Wine).
Похожие вопросы
- Конец объектно-ориентированному программированию? Переходим от “черных” ящиков к ”белым” и ”прозрачным” ящикам?
- Кто-будь доступно может объяснить что же такое Объектно ориентированное программирование?
- Что из себя представляет объектно-ориентированное программирование, как выглядит (своими словами, пожалуйста)?
- Языки объектно-ориентированного программирования общая характеристика?
- Что такое объектно-ориентированное программирование?
- Объясните что такое объектно-ориентированное программирование просто и понятно, желательно с примерами (с++)
- Стоит ли пользоваться Объектно-ориентированным программированием ?
- Чем отличается объектно-ориентированное программирование от обычного?
- Почему объектно-ориентированное программирование провалилось?
- Объектно ориентированное программирование. (ООП)
Ассемблерные вставки для сознания GUI так же "необходимы", как и для решения прочих задач на C или C++ (т. е. бесполезны). Если желаете использовать низкоуровневое программирование графики, к вашим услугам Windows API (там несколько подсистем), DirectX и OpenGL (и другие API в случае Unix-систем).
Но я не совсем понял как подключать интерфейс к готовой программе. Создать его как модуль и подключить тоже как модуль? Или как?