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

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

Я знаю, что такое парадигмы, не беспокойся.
И знаю, что некоторые на классах умудряются реализовывать процедурную парадигму.
Ещё вопросы есть?

Не имеет. От функции у меня есть идентификатор типа std::wstring, я его вывожу, как обычную подстроку и всё. И даже таблица функций прямо здесь не нужна. А готовая разметка потом будет передана в другую программу, задача которой уже трансляция в исполняемый код. И кот там то и будет строиться дерево объектов, но без визуализации. Там количество функций тоже не имеет значения. И там уместна объектная парадигма, но задача другая - разобрать разметку с учётом приоритетов операций, арифметических и операторных скобок и тому подобной иерархии и сгенерить код.

Добавлено @ 07:26
Нет. Забыть назначение функции во-первых не возможно. Во-вторых любая функция легко читается. А в-третьих функции самого проекта не участвуют в выражениях, а участвующие не входят в проект. А вот если класс "притянуть за уши", то его назначение гарантировано забудется уже в процессе декларации его интерфейса.

Это сообщение отредактировал(а) ТарасАтавин - 3.9.2013, 07:26

Я могу до символа повторить программу, написанную ещё в 1995-м году со всеми допущенными ещё тогда ошибками и избыточностями. А на одном проекте у меня была напарница, забывавшая точное имя функции в процессе её реализации. Но даже она не путалась их назначении, а только забывала, что и как именно сокращено, что написано полностью и как правильно такой то слог пишется по-английски. Назначение же она просто читала в комментариях к прототипам. Имя оба противоположные варианты феноменальной памяти, на выбор нужной функции при её использовании мы умудрялись тратить примерно одинаковое время. Ни добавление новых функций, ни замена существующих не мешала не только мне, но и ей. Но даже я со своей памятью не способен надолго запомнить назначение избыточного класса. Уже, кстати, пробовал. Назначение класса забывалось минуты через две, приходилось возвращаться к комментарию и только тогда продолжать. Тот класс я только декларировал трое суток, а как дошёл до реализации, догадался полностью заменить всю иерархию, тогда дело и пошло. Для того, чтоб при избыточности держать в памяти целый класс, она должна быть совсем уж как у машины. Я читал и вообще чужие проекты полностью в процедурной парадигме и потом брал из за основу своих проектов. Ни одна подпрограмма не вызвала затруднений. И даже на спектрумовском бейсике, поддерживающем только алгоритмическую парадигму в чистом виде. Единственная сложность данной задачи заключалась в том, что на выходе нужна высота только числителя, а высота вложенной дроби предварительно должна оцениваться целиком, а при выводе опять только высота числителя, но функций оценки высоты желательно иметь две перекрёстно рекурсивные для дроби и одноэтажной строки. Как только догадался вернуть оба значения в полях одного объекта, всё решение стало элементарным. Но объект здесь - не дробь, а высота. Можно было бы и два скалярных выходных параметра вместо него использовать. Сложность и результат те же.

Это сообщение отредактировал(а) ТарасАтавин - 3.9.2013, 07:53

Тгда ты практически феномен и тебе можно гордиться. Люди, даже если будут тренирвоать свою память, именно таких успехов, как правило, не добьются.
Но и тебе надо учитывать, что они, как правило не таковы.

В этом нет ничего плохого, просто жизнь разнообразна. Я вот что-то такое предполагал, кстати.

Кстати, классы ни чего не добавляют к возможностям группировки функций, для этого более, чем достаточно использовать части имён. Классы нужны для группировки данных: A::method() или AMethod(A &a) разница не велика, а имена данных пришлось бы составлять из имён не классов и полей, а объектов и полей, а таких объектов может быть много и хуже всего становится, когда они ещё и элементы массивов. Сколько массивов придётся индексировать, чтоб достучаться к 10-ти свойствам одной сущности? А с помощью объектов можно индексировать один массив, сохранить, если надо, адрес элемента в указатель и потом юзать поля. А методы (подпрограммы-члены) нужны для доступа к приватным и защищённым членам и не только на плюсах. Разделение класса на интерфейс и сокрытые данные - не флаг константности, а реальная возможность упростить структуру объектно-ориентированного проекта и для всех функций сразу записать, что именно должно быть защищено, или запривачено: одно дело, разработка одной маленькой функции, и совсем другое доступ к данному через 10 лет для других целей в шестиуровневой иерархии классов. В первом случае доступ вытекает из текущей подзадачи и забыть его невозможно, а во втором доступ определяется назначением всей иерархии и влияет на сами подзадачи.

Добавлено @ 07:53
В хорошем проекте это не влияет ни на время выбора функции, ни на количество путаницы, так как всё можно прочитать или в прототипах, или в комментариях, а в моей памяти на листинг приходится вешать последовательный доступ, что ведёт к равному с чтением времени поиска. Способность искать нужную функцию стоя спиной к сидящей за компом напарнице, - это абсолютно лишняя опция.

Это сообщение отредактировал(а) ТарасАтавин - 5.9.2013, 08:04

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

Перегрузка операторов - это способ создать функции с синтаксисом операторов. В данном же случае нужны функции с синтаксисом обычных подпрограмм. И всякая группировка функций членством в классе основана только на данных и призвана распределить доступ. Даже перегруженные операторы могут быть вне классов, ни кто не запрещает перегрузить  вместо , но если TComlex внутренним представлением имеет арифметическое и это учтено оператором, а интерфейс соответствует тригонометрическому представлению, то нужен доступ к закрытым членам и вот тогда оператор должен быть членом. Если же не группировать данные, то ничего страшного вместо этой перегрузки написать функцию . Вот только + между слагаемыми поставить уже не получится, так как формально ни одно слагаемое не будет существовать, как единая сущность. И в сложном математическом выражении такая функция уже не сможет по той же причине поучаствовать. Но снести функцию в группу не проблема и так. Именно группировка данных и управление доступом к членам - единственная цель объектно-ориентированной парадигмы, а если бы задача стояла сгруппировать функции, то скорей уж подойдёт контекстно-ориентированная.

Это сообщение отредактировал(а) ТарасАтавин - 7.9.2013, 06:22

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