Мое мнение, что в ООП-программа должна содержать:
- не менее 2 классов (один класс должен наследоваться от другого) - для демонстрации принципа наследования 
- не менее 1 приватного члена класса - для демонстрации принципа инкапсуляции
- не менее 1 виртуального метода и не менее 1 перегрузки этого метода - для демонстрации принципа полиморфизма.
- не должно быть функций и переменных, не являющихся членом класса (за исключением ф-и main на С++)

Может быть надо продемонстрировать что-то еще?

Можно ли вот такую программу считать правильной ООП-программой?



Это сообщение отредактировал(а) ZZZkoderZZZ - 12.3.2013, 12:23

Тут не хватает одного слова - "правильная демонстрационная ООП-программа"   

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

Это опять про const ? 

Нет. Это про оформление кода.

вот вполне ОО программа:

тут есть объект std::cout, тип которого участвует в наследовании и имеет в своем составе подобъекты с виртуальными функциями.
ему (в ОО терминологии) отправляются сообщения. в качестве сообщения отправляются объекты. 
для этого используются перегруженные операции (это не является обязательной частью ООП, но достойно упоминания как разновидность полиморфизма)

Добавлено через 5 минут и 12 секунд
ZZZkoderZZZ, ОО программа - не самоцель. ООП - инструмент, средство. никому не интересны показатели программы в виде числа классов, объектов, функций, их свойств и т.п.
программа должна делать то, что должна, и быть сопровождаемой. парадигмы, библиотеки и прочие инструменты лишь средства достижения указанных целей.

Как можно лучше оформить короткую программу, которая ничего не делает? Отступы есть, скобочки расставлены по одной схеме, комментировать здесь нечего. Очень хорошо выполнены требования 6, 7 - 
6. Большие функции - это зло
7. Не стоит делать функции с более чем 3-мя параметрами

ZZZkoderZZZ, публичная часть класса должна (рекомендуется) располагаться в начале, а приватная в конце. Фигурные скобки должны расставляться согласно одному правилу, а у тебя 3 метода расстановки, причем один необычный. Двоеточие при определении наследования следовало бы выделить пробелами.

Ну пусть хоть "Hello, world!" напечатает что ли...

Зачем писать лишнее слово? 
Разработчики С++ зачем-то по-умолчанию всё сделали private, может быть по этой причине?

Это сообщение отредактировал(а) ZZZkoderZZZ - 12.3.2013, 16:55

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


Ну я бы сказал это вопрос вкуса, хотя лично тоже предпочитаю распологать вконце.

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

хочешь паблик по-умолчанию - используй структуры.

В структуре надо дописывать private, а в классе - public.

Это сообщение отредактировал(а) ZZZkoderZZZ - 12.3.2013, 19:21

можно не дописывать, зависит от содержимого. 

Если в структуре нет членов-данных, зачастую, private секции может не быть вообще.

Аргументы функции — это переменные, от которых зависит исходный результат функции.
Функцию F = X+Y+Z нельзя сократить до F = X+Y. Вот так же и в программировании, есть случаи, в которых критически важных аргументов много.
Например, функция отправки емейла в PHP. Для отправки корректного (а не похожего на спам) письма надо использовать как минимум 5 аргументов: отправитель, получатель, тема, тело и дополнительные заголовки. 
Можно лично для себя все это инкапсулироть в маленькую функцию, добавляя заголовки автоматически, но в корне все равно будет та же функция.
Без 5 аргументов разработчикам PHP пришлось бы создать класс, геттеры и метод отправки. Или же некие другие системные функции для изменения заголовков, вставляемых в будущее письмо. В общем получилось бы неудобно и убого.
В данном случае функция с 5-6 аргументами - это как раз самое оптимальное решение в плане удобства и реализации.
И это только один пример.

Arantir, 
любое число аргументов можно объединить в структуру и передать одним аргументом

Arantir, для этого существуют структуры и классы. По хорошему, для отправки письма необходимо только три параметра: адрес, тема и текст письма. Все остальное необязательно или общее для всех отправляемых писем. Именно поэтому логичнее всего объединить все это в структуру или класс.

ZZZkoderZZZ, 
bsa, 
Заставлять компьютер создавать структуру на долю секунды при каждой отправке письма только ради того, чтобы это вам угодило, — не есть айс.

Не приводите частное к общему.
semdmail() в PHP — это функция, которая позволяет отправить корректный мейл на любом сервере, сайте, домене и при других переменных условиях. 
Я привел ее как пример той цели, которую она выполняет, а не как подспорье для обсуждения необязательных аргументов при отправке письма. Несомненно, для конкретного сайта или даже сервера заголовки будут настроены в угоду админу, документации, целевому получателю или звездам на небе... А для отправки регистрационного письма так и вовсе получателя и текста достаточно, остальное — константы.

Я лишь привел реальный пример того, что процитированное правило далеко не является универсальным. К нему должна полагаться большая аннотация с объяснениями.

В частности, про какие именно функции идет речь. Давайте возьмем, к примеру, веб-фреймворк. В нем есть контроллер, в котором, в свою очередь, есть методы, представляющие соответствующие запросы к сайту. Так что теперь, не передавать на сайт больше трех параметров в ссылке? Или метод контроллера уже не стоит считать функцией?

какова разница в прочтении ручного заполнения структуры? что насчет числа параметров конструктора?

другое дело, что часто



исключения бывают. правило остается

Слишком много исключений получается =)
Существует такое выражение — "слепое следование правилам"...

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

Посмотрите в PHP. В нем огромное количество функций с количеством аргументов больше трех. Но именно это делает их применение простым и удобным. Не думаю, что вообще кто либо согласится, что создание структуры или объекта для каждого вызова подобных функций — это хорошее решение. Особенно в крупных приложениях.

Статья про оформление кода это мнение о best practices, а не свод догматов.

И вообще, тему числа параметров функции надо рассматривать в контексте конкретной задачи. А "правило трех" должно соседствовать и перекликаться с принципом "одна задача - одна функция (класс)".


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


а как же mysql vs mysqli?
впрочем php (до последней версии) громоздок для таких описаний. а вот что-то типа
представляется вполне изящным

А в чем собственно вопрос?

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

ZZZkoderZZZ, я вас разочарую OOP можно реализовать без классов

Добавлено через 43 секунды

нельзя

Добавлено через 5 минут и 31 секунду

чтобы мозги у писателей чаще включались

ZZZkoderZZZ, я тебя расстрою но, в ООПе главное не оказаться в ПОПе, если уж за это взялся. Все остальное решается чисто технически и еще, при помощи мозгов. 

Зачем все усложнять и перед каждым вызовом функции заполнять структуру? А если в числе параметров большие обьекты? Иж можно передать по const& в функцию и избежать копирования. А со структурой придется использовать указатели или написать конструктор(с тем же количеством параметров) и инициализировать константные ссылки. Так чем этот подход лучше простой передачи параметров в функцию? Так ведь и программисту будет легче понять что/где/как.

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

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

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

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

Согласен. При определённых условиях создавать отдельный обьект, только для того чтобы передать методу допустим 8 параметров, чего хорошего? Как такое облегчает лoгику программы, да и производительность тоже?

Если одни и те же параметры используются во многих функциях и из себя представляют что-то единое, то да. Не надо искуственно создавать классы/структуры только ради каких то чисел, если эти структуры не будут что-то осмысленное из себя представлять(то есть что-то более осмысленное чем кучка параметров).

1. Видимо что то не так со структурой и логикой, раз нужен объект прослойка только для передачи параметров методу(хотя не стоит забывать про шаблоны проектирования Адаптер, Прокси и Декоратор). Либо мы можем использовать этот объект в других местах, либо у нас этот метод работает как не пришей собаки хвост. Вообще все преимущество объектов и их методов, в том что первые могут хранить состояние, а вторые с этим состоянием работать.
2. Производительность разговор отдельный поэтому я его и не затрагивал. А вот логику программы наличие объектов облегчает, при условие конечно грамотного проектирования, так как объект хранит состояние и этим состоянием можно управлять через него. Ведь можно сделать так:

а можно так:

На первый взгляд второй вариант будет проще но, только до тех пор пока программа будет рисовать только одину окружность и ничего больше. Как только нужно рисовать кроме нее ещё квадрат и треугольник, да так чтобы они могли менять наложение друг на друга и передвигаться по экрану, получаем головную боль и трудно расширяемый код, если нам вдруг потребуется. Если кто мне не верит может попробовать реализовать такую программку только через функции и без использования структур( к коим относится и массив ). Если у вас получится легко расширяемая программа я с удовольствием сниму перед вами шляпу.


Это сообщение отредактировал(а) krundetz - 28.3.2013, 16:53

ты так говоришь, как будто эти параметры не зависят ни от чего, просто с воздуха их взяли и на бум решили что здесь применим?

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

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

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

Не стоит утрировать.

Это сообщение отредактировал(а) krundetz - 29.3.2013, 08:39

вот такой пример: класс доступа к веб сервису. для его инициализации требуется
1) параметры сервера
2) параметры для вывода в лог-файл
3) параметры, связанные с задачей

каждая группа параметров содержит несколько подпараметров (например, сервер: url, и информация о прокси - тип, адрес, порт, логин, пароль).

как делать в этом случае?

Понравилась статья. Мне кажется - по теме.
Особенно нравится примеры про собаку и счет в банке.

DI нам в помощь, но наблюдатель будет более предпочтительным.

сколько какие?


вот и получается, что здесь лучше использовать несколько структур, чем кучу разрозненных параметров, никак в струкутры не объединенные

на мой взгляд код вида:

более удобен, чем:

и удобнее такого:

самым оптимальным при функциональном подходе будет что то наподобие такого:

но даже в этом варианте, я вижу много минусов, так как не получиться скрыть работу с прокси, то есть если они будут не только HTTP, но и Socks, то нам придётся выносить работу с разными вариантами прокси в createConnection, вместо того чтобы подставлять разные классы прокси реализующие один интерфейс.

В общем приведенный тобой пример, говорит больше в пользу ООП или хотябы структурного подхода.


Ознакомлюсь, выскажу своё мнение.

Это сообщение отредактировал(а) krundetz - 29.3.2013, 10:45

это те же структуры, только сбоку

Добавлено через 2 минуты и 34 секунды

возможно...

но я не для тебя пример писал, хотелось бы мнение другой стороны услышать

Добавлено через 3 минуты и 12 секунд

хабр лежит уже который час

Бу-го-га, наш старый холивар теперь и на хабре  

Господи, чушь какая, если что - то изучаем, обычно вопросы задаем конкретные, что явно непонятно. А тут тупая болтовня   

Хороший пример привел baldina, можно еше что-то такое:

Например функция для добавления нового графического обьекта в конкретную сцену. Параметры:э
ссылка на соответствующую сцену
ссылка на хранилище данных  чтобы своевременно обновить графические елементы в зависимости от поступающих данных
ссылка на обьект трансформатор для перевода значении из хранилища в соответствующие значения для сцены
ссылка на параметры графического обьекта

получилось 4 параметра, если еще подумать, можно еще добавить. Да, программа должна быть обьектно ориентированной, но не могу понять какое отношение имеют структуры-обертки для параметров к ООП. 

P.S. если честно мне все равно )

видимо у нас с тобой расхождение в терминологии, да и диалог о структурах больше относиться к передаче параметров методу, а не к ООП. Выше я писал следующие:



а что тогда дискутируешь?


ты про что? это ж флейм!


сразу не понял


мне бы тоже, но видимо не судьба