Для этого достаточно, чтобы подпрограмма begin-transaction выставляла бы специальный флаг, при котором все действия по сохранению информации в базе данных были бы запрещены, а end-transaction снимала бы его.
Наоборот, "All database storage actions would be disallowed if the flag is not set".
В Waterfall скатываются обычно по другой причине. А высокая неопределенность оценки играет, как раз, на руку Agile, поскольку он предоставляет больше возможностей для раннего выявления отклонений об плана и своевременного принятия соответствующих бизнес-мер.
В Scrum оцениваются, как правило, только Stories путем коллективной оценки. В этом смысле Exreme Programming лучше справляется с задачей максимально раннего выявления отклонения от плана, поскольку использует двухуровневую оценку, сперва Stories оцениваются коллективно (тут есть отличия между 1-ой и 2-ой версией), а затем, при планировании итерации, уже оцениваются Tasks индивидуально.
При этом нужно не забывать, что оценка — это вероятностная распределенность, и, если делать оценивание правильно, то выражать оценку нужно не только вероятностной оценкой, но и ее среднеквадратическим отклонением распределения времени, которое, как раз, и выражает неопределенность оценки и служит бизнесу для грамотного управления бизнес-рисками. Чаще всего для этого используется методика оценки PERT.
Ну, и, кроме того, нужно не забывать, что оценка имеет свою стоимость, которая растет, как правило, экспоненциально в зависимости от точности, и бизнес-выгоды, которые растут линейно. Поэтому точность оценки должна находиться в балансе между затратами на оценку и ее бизнес-выгодами. Как правило, на оценку выделяется не больше 5% итерации.
Полагаю, что имелось ввиду получение проблемы «Parallel Inheritance Hierarchies».
Если я Вас правильно понял, тогда то, что Вы предлагаете сделать, очень похоже на "Replace Type Code with Subclasses". Это, действительно, решает проблему «Switch Statements» (классифицированный Code Smell). И это, действительно, может привести к Code Smell «Parallel Inheritance Hierarchies» и взрывному комбинаторному росту типов. Чтобы этого не допустить, вместо «Replace Type Code with Subclasses» можно применить «Replace Type Code with State/Strategy».
Действительно, в OOP желательно избегать условных операторов в исполняемом коде, поскольку вся суть ООП заключается в возможности группировать вместе данные и поведение. Чтобы обеспечить полиморфизм, условные операторы желательно переносить из исполняемого кода в конструкторы/фабрики (тут есть вариации в зависимости от возможностей конкретного языка). Здесь Вы мыслите совершенно верно. Правда, действовать нужно без фанатизма, ибо если Code Smell «Switch Statements» не угрожает перерасти в «Divergent Change» или «Shotgun Surgery», то он большой угрозы не представляет.
Лучше начинать с первого издания. Второе издание подходит лучше для формализации процессов, и оно лучше адаптировано под сложившуюся на рынке обстановку. Но для понимания лучше все-таки первое издание. Это почти что две разные книги. Прочесть стоит обе. На русский было переведено только первое издание, если я не ошибаюсь. Ценность второго издания еще и в том, что его легче сочетать со Scrum-процессом (подробней эту тему раскрывает Henrik Kniberg в «Scrum and XP from the Trenches: How We Do Scrum» 2nd edition).
Я ценю ваши глубокие познания подкапотного устройства, но не очень отчетливо понимаю, каким образом то, что Вы описали, релевантно к девушке, которая в силу обстоятельств изучала PHP, а потом узнала, что для реализации ее математических навыков более подходит другой язык, например, Python? Что именно, не входящее в стандартный Python-Tutorial (а лучше «Learning Python» 5th edition by Mark Lutz, kimisa ), может помешать ей это осуществить?
Соглашусь, что я, наверное, неправильно выразился, и под «синтаксисом» я имел ввиду ту часть знаний, которая дается официальным руководством.
У нас в практике был случай, когда для одного проекта нам требовался разработчик со знанием Python, но у нас был превосходный кандидат с великолепной теоретической подготовкой, правда, с опытом на PHP, и лишь поверхностным знанием Python. Мы тогда решили, что нам проще и быстрее перепрофилировать его, нежели тратить время на поиск релевантного Python-разработчкика. И время подтвердило правильность нашего выбора.
Где-то деаллокация вручную, где-то по счётчику ссылок, где-то mark-and-sweep GC с разными триггерами на срабатывание, где-то GC умеет определять циклические ссылки, где-то нет.
Ключевое слово здесь «где-то». И именно тем самым, что применяется «где-то», занимается (упомянутое мною) общее устройство компиляторов/интерпретаторов. Например, идея упомянутого Вами mark-sweep сборщика, примененного в Golang, была впервые предложена еще Дейкстрой в 1978 году.
А вообще, за 15 лет у меня было только два случая, когда знаний по GC, изложенных официальным руководством по языку, было недостаточно. Поэтому давайте, пожалуйста, воздержимся от гипертрофирования проблемы применительно к такому простому случаю, как у девушки.
При всём уважении к МС, это едва ли эталонное приложение, на мой взгляд.
Возможно, но это субъективно (спасибо что прямо об этом говорите). Другое субъективное мнение по этому поводу можно услышать от Greg Young (автора термина CQRS): «A perfect example of this [you can see] if you go look at the CQRS and Event Sourcing by Microsoft Patterns and Practices, which is heavily focused on doing this inside of Azure using their toolkits.»
создать у себя в проекте папочки Repository, Unit of work, etc и гордо думать, что у вас хорошая архитектура
При всем уважении, лучше не измерять качество архитектуры папочками. Качество архитектуры измеряется экономикой разработки, и соответствием поставленной задаче достигнутого баланса Quality Attributes (сейчас они стандартизованы).
Ваше возражение было против предлога «В» оригинальной цитаты автора. Именно он стал причиной вашего диалога с автором в стиле RTFM. Дальше вы использовали попеременно предлог «у» и родительный падеж. Но даже если Вы по случайности не заметили предлог «В» оригинальной цитаты автора, которую оспорили, то есть разница между «менеджером Scrum-команды» и «менеджером(-ами) участников Scrum-команды». В последнем случае менеджер находится вне Scrum-процесса. В первом случае — объектом отношений является сама команда, соответственно, менеджер, в таком случае, является участником Scrum-процесса, и вы даже описали его обязанности и ответственность по отношению к команде:
Который отвечает за оценку команды в целом и отдельных сотрудников, нанимает/увольняет/отправляет на обучение, отвечает за результаты работы команды.
Вы даже попросили меня оспорить это:
На какой странице [The official Scrum Guide] там идет речь о том, что менеджеры не нужны?
Я не утверждал, что менеджер входит в Scrum-команду.
Автор: В scrum-командах нет начальника, который в классической системе управления дает фидбэк (к слову говоря, совершенно субъективный) своим сотрудникам. Эту функцию берет на себя вся команда.
Вы: Это неверно. У скрам-команды, конечно, же есть начальник… Подробное описание роли менеджера скрам-команды (род. падеж) читайте в...
Вы именно приписали.
Всякое может быть. Если Вы процитируете, о каких именно моих словах идет речь — мне будет понятней. Пока что я не могу обнаружить, чтобы я что-то Вам приписал.
P.S.: Если Вы хотите поговорить не по предмету обсужения, то я предлагаю не флеймить здесь, а продолжить в привате.
Тут, наверное, опечатка. «Процитировал» Вас, а не «приписал».
и доблестно бросились ее опровергать.
Если помните, то я просто спросил у вас номер страницы «The official Scrum Guide», которая подтверждает Ваши слова. Вы написали кучу слов, но так и не ответили на первоначальный вопрос.
Повторяя иногда мои же тезисы.
Если только Вы — Ken Schwaber, Jeff Sutherland, или, на худой конец, Kent Beck (по вопросам Agile, учитывая что Scrum — это Agile, надеюсь, что хоть это не стало для Вас сюрпризом).
Себе то вы право рассказывать про скрам оставили.
И вы, конечно же, не поленились процитировать эти мои слова перед своей репликой.
P.S.: Тот факт, что Вы перешли от аргументации по сути к обсуждению субъекта диалога, говорит намного больше, чем само содержание Вашего ответа. И это, как бы, не совсем профессионально.
P.S.S.: Когда выбираете литературу, то, если это не первоисточник (и), то старайтесь, хотя бы, чтобы ее рецензировал первоисточник, как, например, книги автора Henrik Kniberg. Я не хочу сказать, что вы прочитали плохую книгу, в конце-концов, Mike Cohn и Ron Jeffries обладают весомым авторитетом в Agile. Может быть, вы просто не так поняли автора. Я не знаю, и это не есть предмет обсуждения. Есть только один документ, который устанавливает, что в Scrum должно быть.
Это, как раз, ключевой аргумент. K.Rubin может выражать официальную позицию Scrum не больше, чем Вы, в отличии от первых двух персон, перечисленных мною: «Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them.» — «The official Scrum Guide»
нужен ли такой вывод для CTO,CEO, VP of Product, HR etc?
Нужны ли эти роли в Scrum-команде и требуется ли их участие именно в Scrum-процессе? «This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together… The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.» — «The official Scrum Guide».
Таким образом, участие перечисленных Вами ролей в Scrum-процессе не требуется, поскольку официальный документ однозначно говорит, что Scrum состоит только из тех ролей, которые содержит документ.
Но, поскольку Scrum — это фреймворк, а не финальная методология, то Вы вольны строить на его основе свои собственные процессы (только они не будут при этом изменять сам Scrum): «Rather, it is a framework within which you can employ various processes and techniques.» — «The official Scrum Guide»
есть начальник. Который отвечает за оценку команды
«The Development Team is responsible for all estimates.» — «The official Scrum Guide»
есть начальник. Который… отвечает за результаты работы команды.
«The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.» — «The official Scrum Guide». А вообще, в Agile заказчик принимает на себя часть финансовой ответственности за право влиять на процесс разработки.
Начальник команды — это тот ради кого и внедряется Scrum.
Scrum внедряется ради получения заказчиком бизнес-выгод, предоставляемых Agile-разработкой, которая заключается в техническом обеспечении итеративной разработки, таким образом, чтобы будущие проектные решения опирались на feedback от практической эксплуатации реализации проектных решений предыдущих итераций. Это открывает возможность эффективного управления бизнес-рисками.
А роль «начальника» в Agile-разработке закреплена в 4-м принципе Agile Manifesto: «Business people and developers must work together daily throughout the project.» А также в «The official Scrum Guide»: «Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.»
Да, кстати, как же я мог забыть… Жирной точкой в этом вопросе можно считать сайт Ward Cunningham (надеюсь, этот человек в представлениях не нуждается). Будем его считать третьим авторитетом (правильней было бы сказать — отцом целого ряда авторитетов). Много текста, поэтому цитировать не буду. Посмотреть можно здесь. Предвосхищая возражения, сразу прошу обратить внимание на «Last edit May 26, 2013» внизу страницы. Если этого мало — загляните еще и в глоссарий ГОФ, а так же в «Библию» ООП — «Object-Oriented Software Construction» 2nd Edition by Bertrand Meyer. В общем, большинство (по крайней мере, авторитетное большинство) — на стороне Alan Kay в этом вопросе.
Про Ken Schwaber и Jeff Sutherland — я слышал. Про K.Rubin — не слышал. Не могли бы Вы подсказать, на какой именно странице "The official Scrum Guide" идет речь о роли менеджера?
Ладно, давайте с другой стороны. Ок, Alan Kay — личность известная далеко не всем начинающим программистам, обратимся к (ну, не знаю, к первому взятому наугад) авторитету современности, к автору бестселлера «Code Complete» 2-е изд. Steve McConnell:
«Don't expose member data in public. Exposing member data is a violation of encapsulation and limits your control over the abstraction.» (далее идут отсылки источникам такой формулировки и примеры).
Я не заостряюсь на том, что инкапсуляция — это принцип, и даже отличительная особенность OOP, т.е. без инкапсуляции ООП теряет свои отличительные признаки.
Что такое «Encapsulation»? Смотрим у МакКоннела же:
«Encapsulation picks up where abstraction leaves off. Abstraction says, „You're allowed to look at an object at a high level of detail.“ Encapsulation says, „Furthermore, you aren't allowed to look at an object at any other level of detail.“»
Здесь речь идет об управлении сложностью, но очевидно, что «Encapsulation» неразрывно связана с «Abstraction».
Что такое «Abstraction»? Это то, что обуславливает само существование класса как Abstract Data Type (ADT).
Итак, вот я посмотрел внимательно Вашу Википедию, и самый популярный/авторитетный источник информации. И нигде не обнаружил, что
должны ли данные быть скрыты для поддержания парадигмы?… ООП говорит нам — лучше да, чем нет, но необязательно.
Более того, никаких расхождений с Alan Kay я не обнаружил.
Когда мы говорим об ООП как о парадигме, а не о реализации языковых конструкций для сокрытия данных, — то инкапсуляция, как отличительный признак ООП, непосредственно связанный с абстракцией и самим смыслом существования класса/ADT — должна быть.
Давайте для объективности заглянем к другому (тоже взятому наугад) авторитету, известному по принципам GRASP, Craig Larman, «Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development» 3-е изд.
«Encapsulation — A mechanism used to hide the data, internal structure, and implementation details of some element, such as an object or subsystem. All interaction with an object is through a public interface of operations.»
Интересно, и что же такое «интерфейс»?
«Interface — A set of signatures of public operations.»
О как… интересно, а «operations» — это, случайно, не «данные»?
«Operation — In the UML, „a specification of a transformation or query that an object may be called to execute“ [RJB99]. An operation has a signature, specified by its name and parameters, and it is invoked via a message. A method is an implementation of an operation with a specific algorithm.» (почти как Alan Kay сказал)
Ну, пожалуй, остановимся на двух. С третьим, я думаю, будет тоже самое.
Рад был бы поверить Вам, что большинство считает также как и Вы, но… похоже, что большинство, включая самую авторитетную его часть, все-таки больше на стороне Alan Kay в этом вопросе.
Вы все время уходите в сторону, и путаете «определение» с конкретным формулированием отношения ООП к сокрытию данных, данное автором этого термина. Еще раз напомню — речь идет о сокрытии данных.
для доказательства своей позиции
Процитируете «мою позицию»?
Нет, я уверен в том, что многие языки, которые общепризнано считаются объектно-ориентированным, не реализуют то ООП, которое имел в виду Алан Кей.
сейчас под ООП имеют в виду не то, что имел в виду Алан Кей
Последние два утверждения интересны (хотя и бесполезны в отношении вопроса сокрытия данных), потому что признав в первом утверждении существование современных «чистых» (в концепции Alan Kay) ООП-языков, вы автоматически оспорили свое второе утверждение. Значит, все-таки не все так считают. Вообще, это плохая привычка говорить от лица всех.
Вы уверены в том, что значение ООП, заложенное автором этого термина, не реализуется ни одним современным языком программирования? Интересно…
Термины нередко имеют совсем не то значение
Тут многое зависит не от самого термина, а от субъекта восприятия. Раз уж Вы убеждены в том, что Ваше мнение очевидно всем, то невольно напрашивается вопрос — чем Вы тогда здесь сейчас занимаетесь?
P.S.: просто хотел напомнить, что мы обсуждаем не значение термина ООП в понимании тех, кто не знаком с его сутью и историей, а:
должны ли данные быть скрыты для поддержания парадигмы
Наоборот, "All database storage actions
would be disallowed if the flag is not set".
Вероятно, имелось ввиду C2?
В Scrum оцениваются, как правило, только Stories путем коллективной оценки. В этом смысле Exreme Programming лучше справляется с задачей максимально раннего выявления отклонения от плана, поскольку использует двухуровневую оценку, сперва Stories оцениваются коллективно (тут есть отличия между 1-ой и 2-ой версией), а затем, при планировании итерации, уже оцениваются Tasks индивидуально.
При этом нужно не забывать, что оценка — это вероятностная распределенность, и, если делать оценивание правильно, то выражать оценку нужно не только вероятностной оценкой, но и ее среднеквадратическим отклонением распределения времени, которое, как раз, и выражает неопределенность оценки и служит бизнесу для грамотного управления бизнес-рисками. Чаще всего для этого используется методика оценки PERT.
Ну, и, кроме того, нужно не забывать, что оценка имеет свою стоимость, которая растет, как правило, экспоненциально в зависимости от точности, и бизнес-выгоды, которые растут линейно. Поэтому точность оценки должна находиться в балансе между затратами на оценку и ее бизнес-выгодами. Как правило, на оценку выделяется не больше 5% итерации.
Если я Вас правильно понял, тогда то, что Вы предлагаете сделать, очень похоже на "Replace Type Code with Subclasses". Это, действительно, решает проблему «Switch Statements» (классифицированный Code Smell). И это, действительно, может привести к Code Smell «Parallel Inheritance Hierarchies» и взрывному комбинаторному росту типов. Чтобы этого не допустить, вместо «Replace Type Code with Subclasses» можно применить «Replace Type Code with State/Strategy».
Обычно эта проблема решается с помощью Special Case (он же).
Действительно, в OOP желательно избегать условных операторов в исполняемом коде, поскольку вся суть ООП заключается в возможности группировать вместе данные и поведение. Чтобы обеспечить полиморфизм, условные операторы желательно переносить из исполняемого кода в конструкторы/фабрики (тут есть вариации в зависимости от возможностей конкретного языка). Здесь Вы мыслите совершенно верно. Правда, действовать нужно без фанатизма, ибо если Code Smell «Switch Statements» не угрожает перерасти в «Divergent Change» или «Shotgun Surgery», то он большой угрозы не представляет.
Соглашусь, что я, наверное, неправильно выразился, и под «синтаксисом» я имел ввиду ту часть знаний, которая дается официальным руководством.
У нас в практике был случай, когда для одного проекта нам требовался разработчик со знанием Python, но у нас был превосходный кандидат с великолепной теоретической подготовкой, правда, с опытом на PHP, и лишь поверхностным знанием Python. Мы тогда решили, что нам проще и быстрее перепрофилировать его, нежели тратить время на поиск релевантного Python-разработчкика. И время подтвердило правильность нашего выбора.
Ключевое слово здесь «где-то». И именно тем самым, что применяется «где-то», занимается (упомянутое мною) общее устройство компиляторов/интерпретаторов. Например, идея упомянутого Вами mark-sweep сборщика, примененного в Golang, была впервые предложена еще Дейкстрой в 1978 году.
А вообще, за 15 лет у меня было только два случая, когда знаний по GC, изложенных официальным руководством по языку, было недостаточно. Поэтому давайте, пожалуйста, воздержимся от гипертрофирования проблемы применительно к такому простому случаю, как у девушки.
При всем уважении, лучше не измерять качество архитектуры папочками. Качество архитектуры измеряется экономикой разработки, и соответствием поставленной задаче достигнутого баланса Quality Attributes (сейчас они стандартизованы).
Вы даже попросили меня оспорить это:
Вы: Это неверно. У скрам-команды, конечно, же есть начальник… Подробное описание роли менеджера скрам-команды (род. падеж) читайте в...
Всякое может быть. Если Вы процитируете, о каких именно моих словах идет речь — мне будет понятней. Пока что я не могу обнаружить, чтобы я что-то Вам приписал.
P.S.: Если Вы хотите поговорить не по предмету обсужения, то я предлагаю не флеймить здесь, а продолжить в привате.
Если помните, то я просто спросил у вас номер страницы «The official Scrum Guide», которая подтверждает Ваши слова. Вы написали кучу слов, но так и не ответили на первоначальный вопрос.
Если только Вы — Ken Schwaber, Jeff Sutherland, или, на худой конец, Kent Beck (по вопросам Agile, учитывая что Scrum — это Agile, надеюсь, что хоть это не стало для Вас сюрпризом).
И вы, конечно же, не поленились процитировать эти мои слова перед своей репликой.
P.S.: Тот факт, что Вы перешли от аргументации по сути к обсуждению субъекта диалога, говорит намного больше, чем само содержание Вашего ответа. И это, как бы, не совсем профессионально.
P.S.S.: Когда выбираете литературу, то, если это не первоисточник (и), то старайтесь, хотя бы, чтобы ее рецензировал первоисточник, как, например, книги автора Henrik Kniberg. Я не хочу сказать, что вы прочитали плохую книгу, в конце-концов, Mike Cohn и Ron Jeffries обладают весомым авторитетом в Agile. Может быть, вы просто не так поняли автора. Я не знаю, и это не есть предмет обсуждения. Есть только один документ, который устанавливает, что в Scrum должно быть.
Нужны ли эти роли в Scrum-команде и требуется ли их участие именно в Scrum-процессе? «This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together… The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.» — «The official Scrum Guide».
Таким образом, участие перечисленных Вами ролей в Scrum-процессе не требуется, поскольку официальный документ однозначно говорит, что Scrum состоит только из тех ролей, которые содержит документ.
Но, поскольку Scrum — это фреймворк, а не финальная методология, то Вы вольны строить на его основе свои собственные процессы (только они не будут при этом изменять сам Scrum): «Rather, it is a framework within which you can employ various processes and techniques.» — «The official Scrum Guide»
«The Development Team is responsible for all estimates.» — «The official Scrum Guide»
«The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.» — «The official Scrum Guide». А вообще, в Agile заказчик принимает на себя часть финансовой ответственности за право влиять на процесс разработки.
Scrum внедряется ради получения заказчиком бизнес-выгод, предоставляемых Agile-разработкой, которая заключается в техническом обеспечении итеративной разработки, таким образом, чтобы будущие проектные решения опирались на feedback от практической эксплуатации реализации проектных решений предыдущих итераций. Это открывает возможность эффективного управления бизнес-рисками.
А роль «начальника» в Agile-разработке закреплена в 4-м принципе Agile Manifesto: «Business people and developers must work together daily throughout the project.» А также в «The official Scrum Guide»: «Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.»
«Don't expose member data in public. Exposing member data is a violation of encapsulation and limits your control over the abstraction.» (далее идут отсылки источникам такой формулировки и примеры).
Я не заостряюсь на том, что инкапсуляция — это принцип, и даже отличительная особенность OOP, т.е. без инкапсуляции ООП теряет свои отличительные признаки.
Если верить приводимой вами же Википедии, то вы пришли к "распространённому заблуждению — рассмотрению инкапсуляции неотрывно от сокрытия.". Там же: «некоторые языки (например, Smalltalk, Python) реализуют инкапсуляцию в полной мере, но не предусматривают возможности скрытия в принципе.»
Что такое «Encapsulation»? Смотрим у МакКоннела же:
«Encapsulation picks up where abstraction leaves off. Abstraction says, „You're allowed to look at an object at a high level of detail.“ Encapsulation says, „Furthermore, you aren't allowed to look at an object at any other level of detail.“»
Здесь речь идет об управлении сложностью, но очевидно, что «Encapsulation» неразрывно связана с «Abstraction».
Что такое «Abstraction»? Это то, что обуславливает само существование класса как Abstract Data Type (ADT).
Итак, вот я посмотрел внимательно Вашу Википедию, и самый популярный/авторитетный источник информации. И нигде не обнаружил, что
Более того, никаких расхождений с Alan Kay я не обнаружил.
Когда мы говорим об ООП как о парадигме, а не о реализации языковых конструкций для сокрытия данных, — то инкапсуляция, как отличительный признак ООП, непосредственно связанный с абстракцией и самим смыслом существования класса/ADT — должна быть.
Давайте для объективности заглянем к другому (тоже взятому наугад) авторитету, известному по принципам GRASP, Craig Larman, «Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development» 3-е изд.
«Encapsulation — A mechanism used to hide the data, internal structure, and implementation details of some element, such as an object or subsystem. All interaction with an object is through a public interface of operations.»
Интересно, и что же такое «интерфейс»?
«Interface — A set of signatures of public operations.»
О как… интересно, а «operations» — это, случайно, не «данные»?
«Operation — In the UML, „a specification of a transformation or query that an object may be called to execute“ [RJB99]. An operation has a signature, specified by its name and parameters, and it is invoked via a message. A method is an implementation of an operation with a specific algorithm.» (почти как Alan Kay сказал)
Ну, пожалуй, остановимся на двух. С третьим, я думаю, будет тоже самое.
Рад был бы поверить Вам, что большинство считает также как и Вы, но… похоже, что большинство, включая самую авторитетную его часть, все-таки больше на стороне Alan Kay в этом вопросе.
Процитируете «мою позицию»?
Последние два утверждения интересны (хотя и бесполезны в отношении вопроса сокрытия данных), потому что признав в первом утверждении существование современных «чистых» (в концепции Alan Kay) ООП-языков, вы автоматически оспорили свое второе утверждение. Значит, все-таки не все так считают. Вообще, это плохая привычка говорить от лица всех.
Тут многое зависит не от самого термина, а от субъекта восприятия. Раз уж Вы убеждены в том, что Ваше мнение очевидно всем, то невольно напрашивается вопрос — чем Вы тогда здесь сейчас занимаетесь?
P.S.: просто хотел напомнить, что мы обсуждаем не значение термина ООП в понимании тех, кто не знаком с его сутью и историей, а:
то вы посягаете на первоисточность. Это немного не то, чтобы:
или
Что говорит нам ООП устами автора этого термина — я вам озвучил.