Здравствуйте!
Я неоднократно видел посты ( на этой конференции так же),
в которых возникали споры, суть которых:
Метод и ф-ия одно и тоже?
Прошу прояснить этот вопрос,
здесь я прочитал вот это:
Если объект вызывает не свойство, а метод, то вызов метода сопровождается заданием фактических аргументов:

x.M(a1, … ak)
            

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


Верно ли что:
метод не void, т.е. который что-то возвращает, есть ф-ия.
Спасибо за ваше внимание!

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

Я понял, +++, спасибо за развернутый ответ!

VOX, да кстати чойт вспомнил вдруг...в шарпе таки есть функции, не являющиеся методами. Замыкания - тоже функции, но методами они не являются.

diadiavova, так вроде они называются Anonymous Methods...

а можно пример анонимус-метода, а то что-то запамятовал.

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

Это сообщение отредактировал(а) diadiavova - 8.12.2009, 22:34

Лямбда-выражение - это функция в математическом смысле. Как только пытаешься ее вызвать - она компилируется в вполне нормальный метод  Вообще лямбда превращается в анонимный метод или дерево выражений (LambdaExpression) еще на этапе компиляции.

Для полноты картны надо рассматривать в отладке.

Это я как бы к тому, что в vb.net уже есть обычные анонимные методы, с синтаксисом сразу через лямбды. И к тому, что путаницы между понятиями замыкание (или как оно vb.net) и анонимный метод существовать не может - это одно понятие, просто в C# для него есть два разных синтаксиса. Но il на выходе одинаковый.

Это сообщение отредактировал(а) PashaPash - 9.12.2009, 02:18

Точнее анонимные функции. Анонимные подпрограммы там только в 10-й версии появятся(или если угодно появились), а уж коль скоро там между методами и функциями делаются различия, то пока там есть только анонимные функции  
Ну я ещё раз повторяю, что существуют разночтения в этих понятиях. На сколько я понимаю, слово "метод" первоначально обозначало "метод какого-либо типа". В процессе развития языков и технологий, появлялись различные нестыковки, отсюда путаница.
В том же бейсике почему ввели деление на методы и функции, при том что никто не утверждает, что функция - не метод? Да всё очень просто: метод не возвращающий значения там называется Sub. Это - сокращение от subrutine, ну это же уже точно не соответствует его сегодняшнему статусу(какая нафиг подпрограмма  ). А называть как-то надо, вот и назвали словом, которое ммммм...не только к ним относится. Со временем вся эта мешанина накапливается, да ещё и кочует через языки и технологии, в результате имеем то, что имеем.

diadiavova, особенности названий методов в vb - это проблемы программистов на vb  Проблема процедур/функций была решена введением слова void еще в C.
В самом .net, на уровне CLR - есть только методы, причем все - неанонимные 

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

Полностью согласен с diadiavova. Разночтения существуют в книгах, подтверждаю)))

Этот топик появился из-за разночтения в голове у автора курсов интуита  Вот зачем было писать 
"отличное от void (быть функцией)" и "могло быть использовано в качестве операнда какой-либо операции", когда в спеке по C# все в более общем виде сформулировано.

7.1 Expression classifications
An expression is classified as one of the following:
...•    Nothing. This occurs when the expression is an invocation of a method with a return type of void. An expression classified as nothing is only valid in the context of a statement-expression (§8.6).

8.6 Expression statements
An expression-statement evaluates a given expression. The value computed by the expression, if any, is discarded.
expression-statement:
    statement-expression;
statement-expression:
    invocation-expression
....

Функции в спеке не упоминаются. Т.е. "быть функцией", IMHO, просто так приписано. Получается суровый персказ спеки своими словами.

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

Читай правильные книги  Это вы еще старой доброй путаницы переводом statement/operator -> оператор/операция не застали....

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

Функция - именованый блок кода который что-то возвращает.
Процедура - именованый блок кода который ничего не возвращает, но что-то, где-то изменяет.

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

Для подчеркивания различия этих концепций в функциональном программировании выделяют чистые функции - то есть такие которые ничего не меняют. В С++ - такие методы помечают const. В Ruby - знаком ! (кажется им)

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

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

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

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

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

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

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

Это сообщение отредактировал(а) Skynin - 9.12.2009, 18:47

Skynin, да, примерно так. А вот ещё один взгляд на вопрос, вроде бы то же самое, а свои нюансы тоже имеются
http://ru.wikipedia.org/wiki/%D0%9F%D1%80%...%D0%B8%D0%B5%29

Сам топик о различии функций и "нефункций" в C#, и родился из статьи о C#. В каждом конкретном языке разделение на функции и процедуры или есть, или его нет. Если в шарпе разделения нет, то ввести его, сославшись на "обещпринятые определения" не получится. Если бы C# был васиком или паскалем... если бы у бабушки были яйца, то она была бы дедушкой.  Какая практическая причина разделения на функции и не функции? Кроме букоедства, и желания притянуть в C# определения из басика?


Насколько это "общепринятое" определение?  Так всех учили в школе/универе - так там основным языком был паскаль. Скорее можно утверждать что в некоторых языках это разделение ввели. 

В C# понятия функции/процедуры нет, зачем его притаскивать за уши? Тем более что в C# 3.5 понятие функции (математической) ввели, но обозвали им ... лямбда выражения. Которые вообще-то даже "блоками кода" не являются.


Ага, вот только линк на английский вариант редиректит на http://en.wikipedia.org/wiki/Subroutine и для функций и для процедур. В котором явно сказано что subroutine, subprogram, procedure, method, function, routine - это синонимы. И это определение используется в литературе, документации, статьях и даже сообщениях форумов. Это к вопросу об общепринятости...

Ну так и всё тогда, значит это всё одно и тоже  

А если нет разницы, зачем платить больше ее вводить? Тем более для языка, в которой этой разницы совсем нет.

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

А я разве не объяснил зачем? Затем, что люди, пишущие книги и документацию, не всегда руководствуются буквой спецификации и если не понимать "что с чем едят", просто трудно будет всё это читать.

Не из статьи, а из кирса интуита. А их, кстате, сурьйозныи дятьки пишут.

Родная документация по C# написана в соответствии со спецификацией. А книги с левой терминологией лучше не читать. Себе дороже - забивать мозг неправильными терминами. Придется потом лазить по форумам и спрашивать "что такое функция" у первых встречных 
"Что с чем" едят - у всех разное. Вон, выше уже определение со словами "сайд эффекты" проскочило. Вполне общепринятое, кстати, и гораздо более распространенное чем "процедура, которая что-то возвращает".

Сурьезные - это Рихтер, Эспозито, Фаулер, Гамма и компания. А Биллиг В. А. - просто дядька, хотя курс вполне нормальный 

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

Процедуры, еще раньше назывались подпрограммами, SUBPROGRAM, subroutine. И во многих языках отдельный синтаксис вызова был:
DО MYPROC WITH PAR1, PAR2
и
=myfunc(par1,par2) или $$myfunc(par1,par2) (= и $$ нужно было указывать обязательно)
для функций.

Есть общие термины, а есть конкретные реализации, нюансы осмысления в конкретном ЯП.
Есть история развития терминов, и история развития синтаксиса ЯП и концепций.

Речь шла - о "путанице", я и пытался рассказать о ее причинах.


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


Все есть - блок кода. Как Вы кодите без кода то?   


Я и не притаскиваю. И в той теме о делегатах как раз и наехал за использование "функция" в применении к C#. 

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



Это сообщение отредактировал(а) Skynin - 10.12.2009, 10:40

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

Ты кого имеешь в виду?  


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

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

Это общепринятое название в одной ветке ЯП - заточенных под процедурное программирование. 

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

C# - мультипарадигменный язык, с уклоном в ОО и поддержкой ФП. В ОО нет функций и процедур. Есть объекты и их методы. Статический метод еще можно фунцией/процедурой назвать, но метод - это понятие, которое во времена процедурных языков не сущестовало. 

Функциональные языки появились до процедурных. Там свое понятие функции. Понятие фукнции (в документации по С#) унаследовано из F#, по крайней мере в доках по linq.

Специфическое разделение на фунции/процедуры никогда за пределы процедурных ЯП не выходило. Называть его "общепринятым" - неосмотрительно, это приводит вот к той самой путанице. 


Википедию можно исправить 
Что-то меня ни C, ни C++, ни даже ассеблер за вызов "функции" как "процедуры" не ругал. 
Это ограничение вообще существовало где-нибудь, кроме пары древних однопарадигменных процедурных ЯП? 21 век уже, чисто процедурные языки надо забыть как страшный сон.


Лямбда при копмиляции как Expression первращается в кусок данных, а не в "блок кода", и при этом вызвать ее нельзя и "код" в ней не выполняется. Вот так и кодим.


Вот поэтому я книг почти не читаю, кроме пары специфических, с правильной терминологией. 


Ок, пример:


То что в where - фунция в общепринятом смысле и по документации. Но при этом не функция с точки зрения процедурного программирования. Это не "блок кода, возвращающий значение". И не метод.

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

Нас ес-но %)

Это сообщение отредактировал(а) PashaPash - 10.12.2009, 17:51

Ну это вряд ли. В F# оно тоже не из пальца высосано. Это как раз таки есть общепринятые понятия, естественно с некоторой спецификой, только и всего.

Скорее чистые языки вообще.  
А как она выполняется, если это не блок кода? Я чойт не уловил твою мысль.  

Да она как бы и не выполняется, в том и фишка с лямбдами. Компилятор делает из него дерево объектов типа Expression. А уже конктретный linq provider решает что с этим деревом делать. Может откомпилировать в делегат и вызвать как код. 
Может оттранслировать в строчку SQL и скормить SQL Server-у. Но тогда на самом деле ни вызова геттера row.Field, ни вызова > на самом деле выполнено не будет. Может превратить в JOIN, если эта лямбда в LoadOptions, типа LoadWith(task => task.Project) - тогда код вообще не "выполняется".

По аналогии - аттрибут на каком-нибудь свойстве - не выполняется ведь. Аттрибут [DefaultValue(42)] - не выполняется в "общепринятом" смысле. Лямбда в цепочке вроде config.SetDefaultFor<MyClass>(c => c.MyProperty).To(42) тоже не выполняется, используется просто как способ указать на свойство.

Ты сейчас говоришь не о функции Were, а об аргументе, который ей передаётся. Да и потом почему это не блок кода? Если этоне код, тогда что?  
То что этот код может выполняться по-разному в общем-то значения не имеет, в том и прелесть высокоуровневых языков, что можно на этом не заморачиваться. Всё-таки говоря о функциях и прочих делах мы обсуждаем элементы программного кода, а не то как этот код выполняется. Мало того, взять например опять-таки мой любимый васик (кто о чём, а лысый о расчёске  )...функции васика, в конечном итоге превращаются в то же самое, что и методы шарпа, тем не менее ты утверждаешь, что в шарпе методы - никакие не функции. Тогда почему говоря о лямбдах ты пытаешься что-то вывести из того, чем они становятся в процессе компиляции/выполнения?  

А при чем к коду - компиляция?


Замечательно!   


Это все объясняет  
Винигрет из лямбд, компиляции и Expression

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

Это сообщение отредактировал(а) Skynin - 10.12.2009, 21:10

Да, зато у тебя все строго и по классике 
row => row.Field > 42
Блок кода. Немиенованный. Не функция по твоему определению, так? Может винигрет все-таки у тебя? Книжки неправильные читаешь, или еще что-то.... 

Смотри, простой пример:

То что справа - функция или нет? По твоему определению, если убрать "именованный" - да.


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

diadiavova, Я утвреждаю, что вы пытаетесь притянуть термин из процедурного программирования в ООП. 

Лямбды в шарпе и анонимные функции в басике - это функции в математическом смысле. Отношение между двумя множествами.
А методы - это с большой натяжкой - функции в смысле computer science, которые "кусок кода, который что-то возвращает"
Это абсолютно разные понятия. 

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

Это сообщение отредактировал(а) PashaPash - 10.12.2009, 22:19

Ну во-первых, почему это как в шарпе так лямбды, а как в васике - так сразу анонимные функции. Там они тоже лямбда-выражениями называются(вспоминается один фильм, где Лесли Нильсен пописав из пальца сказал про инопланетян "не такие уж мы и разные"  ).
Во-вторых речь была не о лямбдах. Для объявления обычного метода класса, возвращающего значение в васике используется ключевое слово Function, но в конечном итоге это превращается в то, чему напрочь отказываешь в том, чтобы называть это функцией. Я сопсно об этом.

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

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


A lambda expression is an anonymous function (с) из доки по C#. Вот только само по себе lambda expression описывает математическую функцию. 
Запись в коде (x,y) => x+y это не узкое понятие "кусок кода: взять x, взять y, сложить, результат вернуть". Это функция в матеметическом смыле. Можно построить график (x,y) => x+y. Нельзя построить график "куска кода". 
Да, лямбду компилятор может превратить в фукнцию в смысле cs (анонимный метод). А может и не превратить. Из коровы можно сделать колбасу, но никто ж не утверждает что корова - это колбаса. А книги - это туалетная бумага.

Ну о синтаксисе это я так...к слову
http://msdn.microsoft.com/ru-ru/library/32s6akha.aspx

diadiavova, у вас там до сих пор модули есть. 
Но если почитать повнимательнее, то "Имеющиеся в Visual Basic 6 математические функции были заменены эквивалентными методами класса System.Math". Т.е. оставили только фукции преобразования, да и то - собранные по модулям, и только в целях совместимостию

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

В васике есть историческое разделение. C# унаследовал синтаксис и терминологию от C/C++/JAVA, в которых нет разделения на функции/процедуры. Я не вижу ни одной разумной причины его вводить. Никтож не пытается скобки { } читать как "бегин/енд", хотя они внутренне ничем не отличаются от бегина/енда в васике.


Я как раз пытаюсь показать что лямбды "не исполняются". С точки зрения и C# и васика, лямбда - функция в математическом смысле, отображение множества на множество, а не "подпрограмма", и не "блок кода, который что-то возвращает". Нельзя "выполнить" математическую функцию.

В васике нет бегиненда...только енд.
Так о чём мы говорим: о том как это называется в спецификации или всё-таки об общепринятых понятиях, которые допускают разную терминологию и которыми пользуются очень многие?


Я этого всё-равно не понял. Да они для того, чтобы исполниться должны быть преобразованы в делегата, и что с того? В коде они работают так же как и пресловутые методы.

Видимо ты ещё не работал с лямбдами из 4-го фреймворка. Там есть даже лямбды, возвращающие войд. Просто пространство System.Linq.Expressions немного расширили. Мало того, на этом пространстве построена платформа DLR, позволяющая портировать на дотнет динамические языки. А вних уже будут и функции и шмункции и со всем этим можно взаимодействовать из шарпа, втом числе через это же пространство имён. Так что не могу с этим согласиться.

Что не мешает писать что C# что на Java в процедурном стиле. Используя методы просто как процедуры и функции.
И такой код массово встречается. Особенно у начинающих.

Потому что в спецификации НЕ рассказано об объектно-ориентированном стиле, или функциональном стилях.

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


Спецификация ЯП - это справочник по грамматике. О падежах, временах и порядке слов в предложении. "Онегина" такие справочники писать не научат.


row.Field > 42 - блок кода записанный в виде лямбды.



x * x - блок кода, оформленный в виде лямбды, и сохраняемый в виде объекта класса - Expression<Func<int, int>>

Блок кода - это группированый набор выражений ЯП. Набор может состоять из одного выражения. Группировка может быть именованной. Когда-то она была всегда именованной. Хотя... очень быстро появились конструкции "указатель на функцию" подобные приведенной выше.

Поэтому:

Неверно. Во-первых потому что у C# и васика не может быть точки зрения, это не субъекты  Точка зрения есть только у PashaPash'а, Skynin'а,..., ... и собачки Шарика.
Во-вторых, потому что выражения ЯП - предназначены для выполнения на некоем устройстве. А уж что они будут выполнять, модифицировать некие данные, работая как подпрограмма, или вычисляя математическое выражение не модифицируя внешние данные - зависит от "правил" ЯП, описанных в его спецификации и мыслетворчества программиста.

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

Когда же без понимания базиса в аргументации применяются "последние достижения науки", ИМХО - это просто ради форсу.




Это сообщение отредактировал(а) Skynin - 11.12.2009, 11:44

Наверно у меня именно такой код. Большая просьба дать ссылку на примеры хорошего кода на C#. Ну или вообще, где он этот хороший код в хорошем стиле.

Я просто не совсем понимаю, почему в C# плохо использовать методы как функции или процедуры... И хочу пример хорошего кода, поэтому, который это разъяснит.

Это сообщение отредактировал(а) ДобренькийПапаша - 11.12.2009, 14:22

Штудировать паттерны(шаблоны). Не копировать, а вникать в идеи, в способ ОО мышления.


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


Глава из книги “Применение DDD и шаблонов проектирования: проблемно-ориентированное проектирование приложений с примерами на C# и .NET”
Пример применения шаблона State.

Понятно. У нас в универе преподаёт программер с 20-ти летним стажем. Он сказал, что штудировать шаблоны - идиотизм. (Я с ним согласен, хотя и не очень доверяю ему).

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

Это небольшой оффтопик, но мне хотелось бы услышать мнение дядиВовы и Партизана по этому поводу. Что вот так вот прям, надо взять и проштудировать шаблоны?

Это сообщение отредактировал(а) ДобренькийПапаша - 11.12.2009, 15:40

Есть и такое веяние. Аналогичное - программировать нужно в нотепаде!
Дело хозяйское, хошь учись, хошь не учись и коси под программиста с 20летним стажем.
У меня - 17 лет. ИМХО, идиотизм - это "книг не читать", опыта не иметь, но вести себя как многоопытный.

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

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

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

Их первое задание – «построить декоративную кирпичную стену».

И в этот момент они осознают, или должны осознать, как мало в действительности они знают. Они никогда не занимались постройкой стен более чем из 18 кирпичей. И они еще не знают о такой штуке, которую все каменщики используют – о металлической проволоке, которая натягивается вдоль стены, чтобы все кирпичи лежали ровно даже на 100-метровой кладке. И они вообще ничего не знают о современных подходах в строительстве, вроде лазера который позволяет прочерчивать ровную линию вдоль стены. И они не знают как противостоять сильному ветру на высокой стене. Никто не говорил им о подкладках под стойку и о линии промерзания. Они даже не знают как пользоваться простым молотком, чтобы разбить один кирпич на два. И у них нет никаких, даже самых туманных представлений об эстетике, и поэтому они не знают что же слово «декоративный» обозначает в действительности.

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

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


А там описаны - задачи.

А вот как можно подпускать неграмотного программиста к любой задаче?
Я - не пускаю. Найдете того кто будет рад ###коду в продакшене - замечательно.

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

Вот Вы русский язык знаете?
А нука, прочтите И. Канта "Критика чистого разума". Много поймете?
А если после учебника "История философии" для неспециализированых курсов?

Это сообщение отредактировал(а) Skynin - 11.12.2009, 16:29

Опять 25  Общепринятое понятие "функция" может означать вообще все что угодно. Если в книге написано "метод должен быть функцией", то вообще неизвестно что автор под "функцией" подразумевал. Разделение на фунции и процедуры слишком нечетко (если не вспоминать про VB), чтобы про него вообще вспоминать. Спор по "понятиям" ни к чему не приведет.


Лямбды не обязательно должны быть преобразованы в делегат "чтобы исполниться". Посмотри, например, fluentnhibernate.org. Там лямбды использутся как равнозначная замена xml-файла. Т.е. в xml-ный маппинг вроде не функция, а как только аналог записан в коде в виде лямбд (не методов) - вдруг становится функцией?

Skynin, как вы ловко превратили мое "почти не читаю" в "не читаю" и косвенно обозвали идиотом. Для этого явно надо 20-летний стаж и знание форта. Я читаю 3-4 хороших книги в год + периодику + туеву кучу статей. В последнее время ни разу не встречал книги про "функции и процедуры в C#". Может я что-то не то читаю, мне надо взять пару книг "C# за 21 день", поднять свой уровень чуть выше идиотизма....? Какой смысл читать "историю философии", если уже давно прочитал и понял Канта 


Понятия из процедурного программирования - это справочник по типам бумаги. "Онегина" такие справочники писать не научат.

Почему вы вместо простого ответа на "лямбда это функиция" ушли в пространное рассуждение о блоках кода? Неужели так сложно на него ответить в рамках "общепринятых понятий"? Может быть с "понятиями" что-то не то?

Это же совсем простой вопрос, могу даже на части его разбить:
1. Это функция, по понятиям?

2. То же, но на VB. Это функция, по понятиям?

По вашему понятию функции и по вашему "Известные способы группировок: процедуры, функции, методы, лямбды." ответы -  "нет", "нет".
В принятых в докуменации по C# и VB терминах - "да" "да". Странно, правда?

Ну и вообще известные способы группировки, в переложении на аналогию со стихами: "Известные типы стихов: синие, зеленые, квадратные, твердые". Намешаны термины из 3-х разных разделов CS.

Добавлено @ 17:24

Не штудировать паттерны - идиотизм. 
Как ты поймешь что шаблон нужен в определенной ситуации, если не знаешь самих шаблонов? 

К сообщению Skynin-а можно только добавить про овердизайн. Это когда каменьщик начинает строить декоративную стену вмето несущей, потому что он вчера прочитал про паттерн "красивые узоры из кирпича" и хочет его применить. А потом все здание разваливается к чертям, хотя построено очень красиво.

Это сообщение отредактировал(а) PashaPash - 11.12.2009, 17:32

Ну не знаю, взял я банду четырёх, силился-силился и ничё толком так и не понял. По сему отложил её, может позже что-то пойму.

Это была попытка подстроиться под Ваш стиль выдергивания.

Вот мои слова:
В C# нет функций. Хотя их можно эмулировать с помощью статических методов. 
Тема -  C# | Delegates 
Там же привел 4ре важных, ИМХО, отличия между методом и функцией.

В этой теме: Методы в ООП - названы отдельным словом чтобы подчеркнуть концепцию что - "передача сообщения объекту" и т.д.

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


Форта не знаю. Стаж меньше. ЯП в профессиональной деятельности использовал штук 5. Заочно пробовал еще с пяток.
А форт я приплел в адрес некоего абстрактного преподавателя, опытного программиста.
Не прочли, мне скопипастить?


Вы не читали моих постов. Что мне ответить на Ваши выпады?
Или я задел гордость форумного божка и всезнайки?
Хорошо, не буду тогда писать, на RSDN прекратил по этой причине, там есть пяток, которые мнят о себе черте-что и не утруждаются читать что им пишут.

Добавлено @ 19:29

Из свежего - Крэг Ларман. Применение UML и шаблонов проектирования. 2-е издание.
Примеры там на Java, но подход к преподаванию шаблонов для новичков, ИМХО, удачен.

Это сообщение отредактировал(а) Skynin - 11.12.2009, 19:31

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


Не всё, но многое  

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

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


Ну вообще-то действия могут быть описаны и структурой данных(принцип эквивалентности алгоритмов и данных). Формат XML вполне подходит для создания на его базе полноценного языка программирования, и не функционального(как xslt например), а вообще любого.

Это ещё почему?  

Я вроде никого идиотом не обзвывал, даже косвенно.



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

Я вас обидел тем, что не прочитал ваш пост в соседнем топике? На RSDN ваши посты не читали? Жаль вас разочаровывать, но - тут ваши (и мои) посты тоже почти никто не читает. Перестали писать на RSDN? Судя по количеству сообщений, вы даже не начали писать, так, оставили пару следов. 

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

В С# нет функций? Так тут же прибегает diadiavova и начинает утверждать что они в VB есть. И в ненавистных вам доках по C# слово функция употребляется. Но вы ж документацию не читаете, она мешает вам писать "Онегина".

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


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

Заморочка в том, что даже в спеке, которую никто не читает, разница между "функцией" и "процедурой" упоминается только в одном месте. Точно в том, в котором про функции вспомнил автор с интуита.

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

Кстати, а ты, diadiavova, прочел все посты Skynin-а? А то вдруг я тут один такой.

Ну вообще-то xslt - везде называют функциональнымм языком программирования, а шаблоны(templates) стало быть - функции. Так что я ничего нового не придумал.

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

Ну эт конечно, только он то используется.

Я думаю, что вы уже начали переходить на личности и ни к чему хорошему это привести не может.

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

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

C xslt - понятно. Конкретно в nhibernate (или вообще в любом другом подобном маппере) конкретный xml-файл - это фукнция? Т.е. понятие функции можно растянуть до "да", но я сомневаюсь что оно того стоит.



Не могу придумать пример, где ж еще можно использовать понятие функции как "не-void" метода. 

А если серьезно? Ты прочитал хотя бы соседний топик про делегаты?

Добавлено через 2 минуты и 46 секунд
ДобренькийПапаша, о, кстати, хорошая идея. Будем называть статические методы без сайд-эффектов "культурными". Наверняка можно найти нужное определение. ;)

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

Я читаю только те топики, названия которых меня заинтересовали. Торчу не только в профразделах, а в последнее время и не столько в них, поэтому всего не прочитаешь. Топик про делегаты не читал.

Добавлено через 28 секунд
Вроде бы не читал  

Проще уж зафиксировать путем удаления и автозамены "функция" на "метод".

Мнишь о себе черте-что и не утруждаешься читать что тебе пишут! Сорри, не удержался.

Хм, пойду-ка я прочту штук 10 книг "XXX для чайников" ...

Основной спор идёт из-за определений трёх понятий: метод, функция, процедура. В споре участвуют трое, Skynin, PashaPash, DiadiaVova.
Для того, чтобы спор закончился необходим компромисс. Соответственно предлагаю заключить Беловежское соглашение. Одно определение достаётся Skynin, другое PashaPash и третье DiadiaVova.  

Определения поделены, тема закрыта.