Введите в гугле "процедуры в языке си" и зачитайтесь Особенно первой ссылкой
http://www.codenet.ru/progr/cpp/qc/


Сообщение отредактировал GetSmart - Oct 16 2009, 13:33

А что по-твоему ООП? Чем объектно-ориентированный подход отличается от объектного?

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

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

Классический пример - графика. Вот есть полсотни объектов, которые имеют в качестве общего свойства то, что их можно нарисовать - в силу того, что они графические объекты. Поэтому все они имеют переопределяемую в потомках (виртуальную) функцию draw(). Теперь, чтобы нарисовать их все, достаточно пройтись по массиву указателей (в С++) на базовый класс (на тот класс, в котором эта функция draw определена впервые), вызывая для каждого эту функцию. И для каждого объекта будет вызвана его собственная функция. Т.е. код, вызывающий функцию, один и тот же, а функции вызываются каждый раз разные. И без ошибок.

Т.е. ООП - это очень эффективный способ управления множеством объектов, связанных между собой "родственными связями", когда известно, что можно делать, но неизвестно в общем случае как (это "как" в каждом случае свое). И по терминологии ООП это что обзывается термином "метод". Другими словами, у каждого объекта есть одинаковое по смыслу действие, но способ его реализации в каждом случае разный. Способ == метод. Отсюда и происхождение этого термина.

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

В чистых же ООП языках все объекты являются связанными, в них все функции-члены реализуются как переопределяемые, т.е. являются как раз методами реализации одних и тех же (по целевому смыслу) действий.




Это лишь доказывает, что вы не один попали под влияние Паскаля. К тому же, надо делать скидку, что переводы тоже делают люди. Не случайно А.С.Пушкин называл переводчиков "подставными лошадьми истории". Ну, и в конце концов, мало ли что пишут на заборах. Мы тут серьезно разговариваем, т.ч. давайте апеллировать к серьезным источникам, коими являются Стандарт языка и его автор[ы].

Это скорее на совести авторов терминологии языка Си, т.к. именно они расширили термин "функция" (в корыстных целях, кстати) на ситуацию когда она может не возвращать результат. В общем смысле этого понятия результат обязателен.


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

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


Какие нафик заборы? Речь идёт о Майкрософте! "Quick C - Компилятор с языка СИ фирмы Микрософт"


А оригиналы пишут Боги Если Бог сказал - функция, значит хоть убейся, но это будет функция, даже если это процедура

Сообщение отредактировал GetSmart - Oct 16 2009, 14:30

Всё равно не вижу тождества "метод == виртуальный" В той же графике, метод move(x, y), например, вполне может быть одинаков для всех фигур, и состоять из, и потому ему совершенно необязательно быть виртуальным.

То есть, (имхо), метод = действие объекта, виртуальный = переопределяемое действие объекта. И эти вещи более или менее ортогональны. Поэтому я всё же склоняюсь к мысли, что название "метод" - это просто краткий способ назвать функцию класса. Ещё более в этом мнении меня утверждает существование термина "Виртуальный метод". Раз есть "виртуальный", то, наверное, должен быть и просто метод?



А, я наконец понял, откуда идёт эта аналогия. Метод = метод (вариант) реализации? Понятно. Но всё же не соглашусь. Метод - это функция объекта, независимо от того, есть у объекта родственные связи или нет. Единственный вариант(метод) реализации - тоже вариант (метод) )

Сформулируйте тогда альтернативное понятие (свободное от навязанных си и паскалем). Правда,оч интересно.
ЗЫ: медаль съел(обе), спасибо, невкусно

Заберите у _Pashи медаль Он накосячил в вызове функции/процедуры по указателю. Надо так:




Да нормально всё определено в Паскале. Вирту - респект. Мне такая дифференциация очень помогает в работе. Но навязывать что-то другим не собираюсь. В общении с особо озабоченными сишниками буду стараться говорить на их "языке". Не факт что получится Но в моих мозгах понятия процедуры и функции никогда не сольются в одно общее понятие функции.

Сообщение отредактировал GetSmart - Oct 16 2009, 21:57

Решил таки копнуть поглубже Поискал по имеющимся книжкам.

1. Bruce Eckel - "Thinking in C++", Глава 10, задание 28:

- статический, следовательно - невиртуальный, но метод.
Там же, Глава 16:

- при этом из приведённого исходника видно, что ни begin() ни end() - не виртуальные.

2. Dale N. - "C++ plus data structures (3rd edition) (2003)", глоссарий:

- ни слова о виртуальности.

3. "Design Patterns":

- тоже никакого обособления виртуальных методов.

4. Ален Голуб - "Верёвка достаточной длины":

- и далее многократно по тексту употребляется слово "метод" в контексте "функция-член".

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

Если он одинаков у неких разных объектов, то просто это означает, что некоторые производные классы используют родительский метод. Но никто и ничто не мешает какому-нибудь из производных переопределить свой способ реализации - и него будет уже свой метод выполнить действие "move".



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


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

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

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

Да!

Если метод не объявлен виртуальным, то у них ничего не выйдет
Давай я так скажу - виртуальные методы - те, которые потомки могут изменить, невиртуальные - которые не должны меняться. В этом состоит гибкость наследования. Но и те и другие - методы.
То есть, разработчик базового класса управляет возможностью переопределения методов этого класса.
Скажем, есть метод AddRef() у хитрого указателя. Его переопределять опасно, он должен действовать одинаково для всех потомков. Поэтому он будет невиртуальным. Но ведь он не перестанет от этого быть методом?


Почему не связанный? Он очень даже связан. Он может вызывать другие виртуальные методы в нужном порядке. Он может обеспечивать общую для всей иерархии логику. Он - метод, просто неизменяемый, инвариантный. И это не метод реализации (это уже немного другая область, и другой термин), а метод класса. В смысле - действе.
Что касается "метода реализации" - это уже другая область, типа паттерны проектирования. Там слово метод имеет другой смысл, и там далеко не всегда применяются виртуальные функции. Бывают шаблоны. Бывают фабрики классов. И многое другое



Мы же с тобой сейчас заняты не изобретением новой терминологии. а выяснением существующей. Той. что применяется сейчас.



То есть, все неправы? Книжки вроде очень уважаемые. Я вчера ещё у Александреску нашёл употребление слова метод по отношению к невиртуальной функции.

По-моему, единственное упоминание у Страуструпа (причём очень нечёткое) не тянет на устоявшуюся терминологию.



Во-первых, где это чёткое определение? Приведи пожалуйста. А во-вторых, почему это чёткое определение относится только к виртуальным функциям С++? Невиртуальные функции разве не наследуются? Разве они не являются точно таким же механизмом ООП?

Конечно! Потому, что если функция не виртуальная - то это не метод!


Виртуальные методы - это масло масленное. Если функция гарантировано не переопределяется, то это не метод для потомка, это просто унаследованный код. Методом оно станет только тогда, когда потомок имеет возможность реализовать эту функцию своим способом - т.е. у него свой способ = метод, отличающийся от споcоба/метода родителя.

Например:



Ну, и какие же TSlon::set_data и TMamont::blink_led методы, если у них целевое назначение совершенно разное? Они - просто разнокачественный код. Обычный код, никак не связанный между собой по смыслу. А вот их виртуальные функции set_request - это функции, которые имеют одинаковое целевое назначение (сделать запрос), но способ реализации этого у них совершенно разный. Методы достижения разные. Поэтому они - методы.


Перестает. Потому, что тут нету никакого способа/метода. Есть просто статический код, который не меняется во всей иерархии.



Вдумайся в смысл слов "метод" и "действие". Чувствуешь разницу? Вот "действие" - адекватное обозначение для термина "функция-член". А "метод" - это всегда по смыслу способ. А не действие.


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


В этом вопросе, к сожалению, да. Программисты, там, может, и сильные, но ООП - это отдельная кухня, там свои правила. И не самая часто применяемая парадигма в С++. Все применяется к месту.


В оригинальном тексте или в переводе?


Устоявшаяся она в ООП. Оттуда и ноги растут. И в контексте С++ мнение Страуструпа вполне перетягивает все остальное.


Ты сам нарыл его в педивикии. Копать надо в источниках по ОО, а не в просто книжках по С++, где и ООП-то рассматривается весьма поверхностно.


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

P.S. Что-то мне думается, что дискуссия на эту тему вряд ли кому-то еще тут интересно. Поэтому, дабы не захламлять форум, предлагаю перенести обсуждение в асю/джаббер. Ты как?

Ок Написал в личку.

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

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

ЗЫ. И незачем в рот смотреть авторам терминологии. В их терминологии не факт, что всё гладко. Именно поэтому:

Сообщение отредактировал GetSmart - Oct 18 2009, 03:24

"Кто ясно мыслит, ясно излагает" (с). Обратное тоже верно. Путаница в словах является отражением путиницы в голове, хотя в большинстве случаев индивид этого и не осознает. Но главная проблема не в этом, а в том, что такой индивид, будучи под властью неверных стереотипов, считает свое мнение безальтернативно правильным. И это делает его необучаемым, а эту путаницу в голове и словах - устойчивой.

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

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

На этом свое участие в данной дискуссии прекращаю. Всего вам хорошего. И всем спасибо.

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

Хотя, если считать обратным == "Кто ясно мыслит, не всегда ясно излагает" => то я не спорю

Долой стереотипы!

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


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

Сообщение отредактировал GetSmart - Oct 18 2009, 07:05