@Suslo

В общем, столкнулся с такой проблемой (пока только постигаю азы программирования в с++), я не понимаю, зачем нужно ооп, ибо все на своем уровне я могу запрограммировать и не используя классы, это будет даже легче, чем их использовать. Будьте добры, поясните, зачем нужно ооп, в чем его преимущества? А также будьте добры, приведите пример, где я не могу без него обойтись. Спасибо!

0

@Avazart

А что тогда в вашем понимании "крупный" ООП ?

0

@ninja2

Так от в том то и дело, какую прогу не возьми нету алгоритмов, все приходится придумывать самому, да для учебных прог есть алгоритмы там да.
А вообще наверно проги строятся по такому принципу: сначала придумываем алгоритм, потом пишим код, снова переписываем алгоритм, снова подправляем код, и так пока не получится норм прога. Просто не всегда получается тот первый алгоритм который мы придумали он будет правильный, в процессе написания кода могут быть какие нить "открытия" и мы увидим что смысл нам ити по этому нашему алгоритму, когда лучше по другому пути ити. Так что такой подход будет применяться, это я из опыта сужу и с того что нету инфы в инете.

Отут даже английский не спасет, английский да поможет когда есть инфа на английском (гугл переводчик тоже норм переводит), но когда ее нет нигде то уже все приехали - собираем нищебродские сведения, а затем уже пишем велосипед который кто то придумал и не поделился .

Добавлено через 4 минуты
Крупный это там шаблоны проектирования разные от "банды четырех", в ООП куча разных шаблонов и каждый шаблон имеет свое название и применение.

Использование готовых классов это мелкий ООП. Что там знать то? Создал объект заюзал метод ппц ООП.

Добавлено через 1 минуту
У нас тут высоко интеллектуальная беседа идет, а не какие там "вбросы".

0

@Avazart

Ну так мы о чем говорим об ООП или паттернах ?

0

@ninja2

тут от еще от интересно если я строчку кода напишу с использованием РВ, у меня допустим строк 30 будет прога занимать, то что оно мне выдаст после дизасамбрирования? Наверно не 30 строк, а какой нить громадный код.

0

@xoror

При увеличении объема написанного когда увеличивается сложность программы. ООП и разброс всей программы по заголовочным файлам помогают поддерживать ее сложность на одном уровне.

0

@ninja2

Да об ООП, паттерны это тоже ООП.

0

@Avazart

Паттерны на то они и паттерны проектирования что применяются при проектировании библиотек.
Хотя опять же знание их дает понимание того как работает библиотека (написанная кем то другим)

В примере который я ранее привел (тесты для оценки глазомера) я применил наследование + фабричный метод (ну и еще один момент там был)

Есть предложения по тому как это можно просто и наглядно реализовать без ООП ?

0

@ninja2

Можно просто для каждой фигуры функцию создать и в switch вызывать нужную функцию.

Avazart, Да все можно если заходить, создать в какой нить области видимости namespase::fugur, создать глобально нужные данные что б каждая функция имела к ним доступ и все создаем нужные функции, дальше в операторе switch вызываем нужную функцию. Это как пример. Возможно даже для небольшой такой проги будет и попроще.

0

@Avazart

И чЁ это даст ?

В прямоугольнике 4 точки, а треугольнике 3 ?
Расчет погрешности рассчитывается для разных тестов по разному (расстояние/угол) ?
Прорисовка тоже самое ...
У каждой "фигуры"(теста) есть как что-то общее так и специфические нюансы.

Сколько будет ф-ций и switch?

0

@ninja2

Можно спокойно прогу просто создавая одни функции без ООП, и создав область видимости, а в ней глобально переменные мы можем спокойно иметь доступ к ним из любой функции и тоже скажу получиться очень удобно и даже ИМХО менее громоздко возможно.

0

@Avazart

Нэймспейс и так используется помимо классов...

Что тут пространства помогут ?
Глобальные переменные никогда не были хорошим тоном, даже внутри пространства.

0

@0x10

И полностью потерять контроль над доступом к этим переменным.

0

@ninja2

Да тоже самое будет что и с ООП, код будет по размеру даже менее громоздкий, создаем функции для фигур, сколько у нас будет фигур столько и функций, столько case будет в switch. Если код будет использоваться только для одной фигуры мы ее так и оставляем в самой функции фигуры, если код будет во всех фигурах использоваться выносим в отдельную функцию и вызываем уже из функций для фигур, если по разному расчитываются то мы так и оставляем в виде кода, если одинаково, то делаем в виде функции и вызываем. Прорисовываются по разному для каждого свою функцию создаем и вызываем в цикле из каждой функции свою функцию прорисовки, в любом случае ты ее перегружаешь, для каждой фигуры.

switch допустим один будет, он нужен только для выбора функции фигуры.

Добавлено через 1 минуту
Нет хороши они тем будут что не нужно будет писать f(int k , int c, double b, и т.д.), а просто запишем f();, внутри пространства ничего страшного не случится, а удобства на лицо. И возвраты из функции не нужно делать, просто сохраняем в глобальную переменную.

0

@Avazart

Ага здравствует "чудо"-код!
Очень интересно, данные разные ... как ф-ции будут с ними работать ? И что нужно наизусть выучить все вариации ф-ий их параметров?

В моем же случае пользователю лишь достаточно знать об открытых методах абстрактного класса (интерфейсе)

0

@sergei60

Добрый день! Позвольте вставить свою копейку. Тема сложная ,противоречивая и мне кажется должна находиться не на "С++для начинающих". Мне как начинающему после прочтения всех указанных ссылок ,статей о быдлокодерах, и так далее ,честно сказать стало немного тяжело. На этом форуме для новичков должен даваться импульс к познанию, должна даваться помощь,подсказка,поддержка...а вопрос этой темы должен обсуждаться в другом месте,может быть даже в узком кругу спецов профессионалов.

0

@Avazart

Это общая часть которую нужно знать на "поверхности" все остальное скрыто в конкретных классах производных от это.

0

@ninja2

Нет ну если пользователь и создатель это одно лицо, а вообще у тебя походу так оно и есть , пользователи и создатели разные лица, только в том случае когда создается какая нить либа которая будет использоваться распространятся и т.д. это создатели классов и пользователи классов им да нужен интерфейс делать и все дела. Дело в том что твоим интерфейсом воспользуется всего навсего один человек и это ТЫ, так что можно было не сильно парится на счет интерфейса.

Данные будут хранится в глобальной области видимости, пользователь за них ничего не будет знать, для каждой фигуры создать нужно в глобально области данные, затем их инициализировать рандомно инициализировать.

А интерфейс, ну если ты для других делаешь то вынеси каждую функцию отдельно в заголовочный файл и опиши что она делает, например для треугольника функция fucnction_treeangle() и все пользователь ее вызовет и начнет работать программа где нужно будет там точку поставить куда нужно, и так для каждого (он должен сам построить прогу на switch), но так как ты являешься и создателем и пользователем этого модуля, то тебе проще создать одну функцию допустим start(int) в которой будет этот swtich или как ты придумаешь сделать вызов функций я не знаю мб. через if неважно. В цикле от 1 до 7 вызовешь этот старт и для каждой функции пройдешь тест.

ООП не всегда делает легче и понятней прогу, можно спроектировать прогу без ООП и она будет легче и понятней.

0

@Avazart

А в чем конкретно затруднения ?

0

@ninja2

Интерфейс можно любой придумать, смотря какие цели ты приследуешь, можно создать интерфейс в виде одной функции и из своей проги ее вызвать и все.

0

@Avazart

Как гласит реклама "ты не ты когда голодный" в данном случае пройдет какое-то время и тот кто писал программу позабудет детали, подобный подход даст возможность вспомнить настолько глубоко насколько это надо (например что бы добавить еще один тест, если попросит заказчик)

0