Обсуждение:Объектно-ориентированное программирование

↓

Пожалуйста, добавляйте новые темы снизу

Без названия

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

Shr 07:45, 1 Июл 2004 (UTC)

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

Свойства

Кажется, в классическом определении данные у класса называются аттрибутами. Или полями? Как-то так. А свойства это расширении ОО в языках типа Delphi, VB, C# - методы, которые выглядят как аттрибуты, но на самом деле вызывают методы для получения или установки значения. Хм? --firefly 16:59, 24 мая 2006 (UTC)

О! Даже Википедия определяет свойства как методы доступа к данным - Свойство (программирование) ;-) --firefly 17:35, 24 мая 2006 (UTC)

А я вот посмотрел как выглядит свойство под рефлектором и увидел что это методы обращающиеся к полям!

// так в оригинале на C#
private int myVar;
public int MyProperty
{
    get
    {
        return this.myVar;
    }
    set
    {
        this.myVar = value;
    }
}
//  а так под рефлектором на С#
public void set_MyProperty(int value)
{
    this.myVar = value;
}

и
public int get_MyProperty()
{
    return this.myVar;
}
//  а вот на Delphi тоже под рефлектором
procedure Program.set_MyProperty(value: Integer);
begin
    self.myVar := value
end;

и

function Program.get_MyProperty: Integer;
begin
    Result := self.myVar
end;

и на всех других языках

класс НЕ является типом объекта

собственно сабж.

А чем он является? Иван Шихалев

Класс ЯВЛЯЕТСЯ типом объекта. Это основы ООП. Дальше также идёт сплошная путаница понятий и выдуманных определений, в том числе у многих участников обсуждения. Кроме того, не надо путать совместимость типов и сами типы. Переменные интерфейсного типа совместимы по присваиванию им ссылки на объекты - но это вовсе не означает совпадения их типов с типами объектов. Отсылаю авторов критических замечаний (особенно - раз уж они ссылаются на Java) к своей методичке http://ru.sun.com/research/materials/Monakhov_Java.html Вадим Монахов 08:45, 4 февраля 2008 (UTC)

Класс не является типом объекта, класс является скорее классификацией множества объектов (множества похожих обьектов).

Классы есть "реализация" классификации объектов. И притом не очень хорошая реализация.

В идеологии OOП есть понятие объекта, сообщений между объектами, и практически всё, нет вообще понятие класса. Есть объктно-ориетированные языки где вообще нет классов, а только объекты (пример: self, js и т.д.).

А если вообще начинать говорить про класс (например привязываться к языку java), то класс это не "тип" объекта. К примеру: если обьявлена интерфейсная ссылка, то к этой ссылке можно привести объекты разных классов. Если класс реализует несколько интерфейсов - то какой у него тип? [пока не участник wiki]

«Если класс реализует несколько интерфейсов - то какой у него тип?» у класса нет типа, он сам _может_ являться типом объекта --NickShaforostoff 18:01, 20 мая 2006 (UTC)

Именно! Класс именно потому и не может иметь тип, что он сам является типом :) И соответственно, если он реализует несколько интерфейсов, то экземпляры этого классы будут иметь тип этого класса, а так же тип всех реализованных интерфейсов.--firefly 16:59, 24 мая 2006 (UTC)

• Лол, в Яве у класса тип - класс (java.lang.Class). А. Астафьев 11:42, 19 октября 2024 (UTC)

Если в языке нет возможности работать с классами – это не значит что классы(типы) не нужны. Вот когда-то в Бейсике не было возможности создавать собственные классы(сложные типы) и их создавали на С++ а на Бейсике пользовались объектами этих классов(типов). Отсутствие возможности создания классов в языке – это следствие недоразвитости языка, если он конечно не является каким либо специфическим языком, где понятие класса противоречит его назначению. 194.186.166.11 13:44, 2 июня 2008 (UTC)noname

Объектно-ориентированный подход

Программированием объектно-ориентированный подход не исчерпывается: предлагаю разделить статьи на теоретическую (общую), относящуюся к самому подходу, и практическую, относящуюся непосредственно к программированию. --Pers 17:41, 5 июня 2006 (UTC)

• Negative. "Подход" и "парадигма" - это синонимы - см.определение. Arachnelis 18:32, 10 января 2014 (UTC)

Объединение с объектно-оринтированными языками

Мне кажется это в корне неправильная мысль. Понятие "программирования" шире понятия "язык программирования". Скорее надо последовать совету Pers'а и разделить статью на 2: ОО подход и ОО программирование. Или даже 3: ОО подход, ОО программирование (краткое упоминание о ОО языках), ОО языки программирования (основаная статья о языках).

• А вот это верно. Один язык может хорошо воплощать парадигму, другой плохо. С другой стороны, применять парадигму можно и на языке, который вообще на неё не рассчитан (ну разве что неудобно, а то и бессмысленно). Самый детский пример: OOC. Пример по-серьёзнее: OO Programming Styles in ML. Arachnelis 18:36, 10 января 2014 (UTC)

Сбалансированность статьи

Раздел "Критика ООП" есть, но раздела "Преимущества ООП" нет. --Чобиток Василий 10:18, 6 августа 2007 (UTC)

• Его и в англоязычном разделе нет. Придётся самим писать Bibikoff 10:20, 6 августа 2007 (UTC)
• Предлагаю предварить критику замечанием, что ООП является общепризнанной основой прикладного программирования - иначе критика выглядит абсолютно неадекватно реальности. Вадим Монахов 08:47, 4 февраля 2008 (UTC)

В целом ваше замечание конечно верное. Но "общепризнанная основа" - достаточно пристрастное утверждение. Особенно с учётом имён скептиков упомянутых в разделе "критика". В тексте отметил ещё пару замечаний требующих ссылки на источник. Bibikoff 12:29, 4 февраля 2008 (UTC)

Утверждение "ООП является в настоящее время основой всей индустрии прикладного программирования" является не критикой ООП, а похвалой. ;) Поэтому её надо перенести в раздел "Преимущества ООП". Оставьте раздел "критика" критикам. ;) --beroal 01:43, 5 февраля 2008 (UTC)

Форматирование структуры текста

Форматирование названий пунктов и подпунктов, для наглядности, желательно различать между собой индексацией и выравниванием. 5 декабря 2007г. ESS Женя

Ссылки

Коллеги, вы уверены, что нам нужно 3 ссылки на ресурсы с кратким описанием принципов ООП? Принципы ООП и собственно в статье описаны не менее подробно. Моё мнение, что эти ссылки представляют из себя пиар достаточно малозначительных ресурсов и им не место в статье. Bibikoff 08:11, 26 июня 2008 (UTC)

Единственная как для меня польза Википедии в наличии в статьях подборок тематических ссылок. --Чобиток Василий 21:28, 26 июня 2008 (UTC)

По правилам, статьи в Википедии должны содержать ссылки на источники. Другое дело, что чем авторитетнее источник, тем лучше (и в случае наличия в статье большого количества ссылок на источники с дублирующейся информацией менее авторитетные можно удалять). --Eugenius 04:08, 27 июня 2008 (UTC)

Полностью согласен, что хорошие ссылки в статье могут быть очень ценны. Но вы по ссылкам этой статьи ходили? Все 3 это просто посты в беззвестных блогах, где в объёме 1 машинописной странички рассказывается, что такое инкапсуляция, полиморфизм и наследование. В статье эти вопросы раскрыты не хуже. Соответственно ценность этих конкретно ссылок - околонулевая. Bibikoff 13:36, 28 июня 2008 (UTC)

Дело в том, что Википедия - не первичный источник информации, и поэтому ссылки и нужны - чтобы было понятно, откуда взяты те или иные утверждения. И ни в коем случае удалять ссылки только на основании того, что в них не сказано ничего нового (по сравнению с тем, что есть в статье). --Eugenius 15:47, 28 июня 2008 (UTC)

Теория?

Ни слова о сущностно-теоретических аспектах ООП, таких, как понятие сложности. (вследствие чего ООП, собственно, и позволяет легко разрабатывать и использовать даже очень большие системы и даже большим группам людей - поэтому оно поработило мир, а не потому, что его рекомендуют маркетологи). (класисческая литература - Г.Буч). Это должно, конечно, по-хорошему подробно объясняться в "ОО Проектирование", но здесь - хотя бы упомянуто? 213.87.81.7 08:02, 10 ноября 2008 (UTC)

Кстати, этой классической книги (Г.Буч Объектно-ориентированный анализ и проектирование) вообще нет в списке литературы снизу. Добавлю. Или есть основания этого не делать? 92.62.52.226 10:45, 10 января 2009 (UTC)

Статью править будем ?

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

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

Что писать знаю, технологию предварительного согласования изменений и порядок их внесения нет. Симонов С.М. 16:06, 11 декабря 2011 (UTC)Симонов С.М. 16:13, 11 декабря 2011 (UTC)

Основные понятия - копивио с хабрахабра?

Что-не совсем понял. Получается, раздел об основых понятиях взят из блога с Хабрахабра?! Это, мне кажется, нужно исправить. Уж на тему ООП источников пруд пруди. РоманСузи 10:31, 2 сентября 2012 (UTC)

Название статьи

В названии указано "Объе́ктно-ориенти́рованное, или объектное, программи́рование". Это не синонимы. Указанное определение относится к объектному программированию. ООП требует не только поддержки классов и объектов, но и наследование классов. Так, JavaScript - объектный язык, но объектно-ориентированным его назвать нельзя. 84.237.53.14 09:10, 22 сентября 2012 (UTC)

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

• В англоязычных академических кругах термина "объектное программирование" не существует - только ООП. Иногда все эти "-oriented" трансформируют в "-based", но на образ мышления это не влияет (хотя на английской вики почему-то написано, что это не одно и то же). Смысл этих слов в том, что при решении проблемы человек делает упор на выделение того ключевого понятия, что стоит в названии парадигмы, т.е. психолингвистически это тожественно. На русских быдлокодеров можете не ссылаться. Arachnelis 18:43, 10 января 2014 (UTC)
• Вообще, ООП - единственная парадигма, в которой "парадигма", "программирование", "анализ" и "проектирование" считаются разными понятиями. Во всех остальных это одно и то же. Поэтому я за объединение соответствующих статей, и не важно как там на английском проекте. Arachnelis 19:07, 10 января 2014 (UTC)

"Сложности определения"

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

Для более яркого восприятия данной концепции разберу все сказанное на отвлеченном (замечу, тоже условно) примере. Возьмем за основу, скажем, дерево (очень даже тривиальное, обычное дерево или если хотите одуванчик), как "законченный программный продукт" и более подробно рассмотрим его "программный код". При первом рассмотрении его можно поделить на несколько глобальных объектов (макрообъектов): листья, кора, сердцевина дерева (если провести аналогию, то это похоже на общеизвестную технологию .NET или объекты Java). Далее направим свой взор внутрь макрообъектов и рассмотрим из чего они состоят. Состав же оных, представляет собой бесконечный набор клеток схожих по типу и выполняющих определенные действия в пределах поставленной задачи. Это и есть объекты в их традиционном понимании. В частности эти объекты состоят из набора "функций" макро- и микробиологического обмена, из чего собственно обычно и состоят объекты и классы. Наследование класса - это формирование клетки на основе существующего генетического кода. Генетический код содержит в себе полную информацию о функционале той или иной клетки но никогда не выполняется. После наследования класса и его инициализации рождается "клетка". Мутации - есть "runtime" формирование прототипа объекта.

P.S.: Объектное-ориентирование - это не стиль или тенденция, а способ мировосприятия. Всё вокруг нас представляет собой объекты. (Прошу прощения за лирику :D) Thomas Ginsburg 10:08, 16 ноября 2013 (UTC)

• Найдите авторитетный источник (в данном случае желательно не связанный с конкретным языком или платформой) и смело правьте определение. Ваше определение — это скорее определение модуля. Тем не менее, ООП уже может пониматься достаточно однозначно (и скорее всего давно могло бы) и достаточно взять хороший теоретический учебник. По моему мнению, наиболее емко выразил идею объектно-ориентированного языка Алан Кэй (цит. задесь http://people.cs.aau.dk/~torp/Teaching/E02/OOP/handouts/introduction.pdf ). В вашем определении не отражена самостоятельность объектов, возможность обмена сообщениями, обладание памятьи и т.п. Можно противо- или со-поставлять ООП со структурным программированием, а можно проследить тенденцию развития абстракций, начиная с неструктурного императивного, структурного, модульного и заканчивая(?) ООП, особенно хорошо заметную на фоне стремления ко все большему сокрытию информации (инкапсуляция в терминах ООП) и грануляризации декомпозиции программы. К сожалению, пока что не нашел АИ на эту тему.

Что касается прототипного программирования, то часть это или нет, но достойно отдельной статьи. РоманСузи 11:11, 16 ноября 2013 (UTC)

• По моему я изложил тоже самое (цит. задесь http://people.cs.aau.dk/~torp/Teaching/E02/OOP/handouts/introduction.pdf) Thomas Ginsburg 22:31, 23 ноября 2013 (UTC)

• У Вас конкретное предложение по улучшению статьи? Биологическая аналогия ну совсем здесь ни при чём (особенно по части наследования), даже для объяснения. Насчёт «все вокруг объекты» — это глубокий философский вопрос, который связан именно с восприятием мира, его моделями и языком описания, а не некими платоническими объектами (хотя зависит от Вашего философского взгляда). РоманСузи 07:56, 24 ноября 2013 (UTC)
• Извините, труд не читал, но цитату «все вокруг объекты» не могу не прокомментировать. Не буду уходить в глубокие материи, а сошлюсь на статьи по языку Haskell. В языке отсутствуют переменные с изменяемым состоянием (вообще отсутствуют, нет такого элемента языка), всё программирование происходит в терминах констант и математически чистых функций (т.е. функций, которые для одних и тех же значений входных параметров всегда дают идентичный результат, не допуская побочных эффектов). При этом язык предоставляет возможности легко работать с бесконечными структурами данных. Как следствие, например, моделирование процессов во времени в языке представляется всем множеством точек на оси времени, каждой точке соответствует определённая конфигурация реальности. Анимация графики представляется функцией, которая принимает на входе момент времени и порождает кадр - это называется (eng) Функциональным Реактивным Программированием (ФРП). Мораль: всё вокруг процессы. Вселенная - это не столько композиция объектов, сколько функция времени. В то же время Хаскел позволяет эмулировать изменяемое состояние, если очень хочется. Мораль: моделировать объекты посредством процессов можно. А вы попробуйте наоборот - и быстро обнаружите существенную разницу между представлением агентной модели на том или ином языке. Arachnelis 18:04, 10 января 2014 (UTC)

Вот что нашёл:

Luca Cardelli - Theory Of Objects (book)

Foundations of Object-Oriented Languages

Лука Карделли, Бенджамин Пирс, Дэвид Тёрнер и Филлип Вадлер - авторитетные чуваки, много работают по теориям типов. Этих людей игнорировать нельзя. Arachnelis 17:30, 1 июня 2014 (UTC)

Терминология

Терминология - вообще вопрос крайне болезненный. Предлагается: давайте сперва немного уточнимся с терминологической базой.

Arachnelis осуществил следующее высказывание: "подход", "парадигма", "анализ", "проектирование" - психолингвистически тождественные понятия. Честно скажу, такое высказывание ввергает меня в лёгкий культурный шок. Я сейчас сделаю ссылки от этих слов на Викисловарь и мы попробуем начать. Там, к сожалению, этот словесный блок несколько далёк от законченности. Заодно и его и попытаемся усовершенствовать. И ещё слово "концепция" нахожу целесообразным ввести. Также, наверное слова "разработка" и "программирование" потребуются. --Goritconceptual 18:28, 15 января 2014 (UTC)

• Мои извинения за то, что прервался в процессе обсуждения вопроса. Был забанен, не имел физической возможности. Если не возражаете, обсуждение этого вопроса продолжит Участник:Goritconceptual. --Gorvzavodru 19:28, 12 января 2014 (UTC)
• Рад возможности продолжить с Вами беседу на эту, на мой взгляд, весьма актуальную тему. --Goritconceptual 19:29, 12 января 2014 (UTC)
• Параллельно выполняемые работы, к сожалению, могут периодически вынуждать меня отвлечься. Надеюсь, длительность проведения дискуссии критичной не является. --Goritconceptual 19:52, 12 января 2014 (UTC)
• Да я сам могу появляться раз в неделю, а то и реже. Хоть целый год спорить будем, лично мне не проблема. Arachnelis 14:38, 15 января 2014 (UTC)

• Терминологические споры я просто не люблю, так что энциклопедической поддержки (анализ этимологии по лингвистическим источникам и копание в библиотеках талмудов второсортных авторов, пересказывающих друг друга ради получения корочек) не окажу. А вот по сути — поспорю с удовольствием, и надеюсь, результат этот дискуссии как-то повлияет на изложение результата этих копаний. Я предпочитаю изложение «от правильного к обзорному», а не попытки разных догматиков перекричать друг друга. И уж тем более я считаю недопустимым, когда плагиаторов-искажателей ставят наравне с изобретателями. Как кто-то сказал, в одном универе защищено более тысячи дессертаций о Пушкине, хотя ни один из этих «учёных» не создал и миллиардной доли того, что создал в этом мире Пушкин. Arachnelis 20:32, 10 января 2014 (UTC)

• Ну и ладно. Даже и рад. Со свободной терминологией, в некоторых отношениях, даже лучше. --Goritconceptual 19:31, 12 января 2014 (UTC)

• Итак, по делу. Во-первых, «парадигма» — это некий принятый и применяемый в определённом сообществе подход. Если я один люблю забивать гвозди микроскопом — это не парадигма. А если издаются публикации, создаются кафедры, проводятся исследования, какой вид окуляра надо установить на микроскоп, чтобы инерция в момент касания шляпки гвоздя была оптимальна — то это уже парадигма. Слово «подход» можно считать более широким лишь в том смысле, что подход бывает индивидуальным и на парадигму не тянет. Но тогда это ОРИСС, увы. Получается, что либо мы слово «подход» вообще не используем, либо редиректим на парадигму. Далее. Получив задачу, я провожу её анализ. Если я вижу, что задача идеально ложится на некий известный мне подход (парадигму), то я его и применю для её решения. Например, если мне поставлена задача вбить гвоздь в стену, то рука сама потянется к молотку. Или, если стоит задача обхода графов (ну там восемь ферзей какие-нибудь, или составление расписаний), то сразу напрашивается логика предикатов, и, соответственно, Пролог. Нужен многопользовательский сервер — автоматом пи-исчисление, и, соответственно, Erlang. И так далее. Получается, что анализ — это процесс подбора подходящей к задаче парадигмы (до погружения в конкретную парадигму). Однако, если я всего-то и знаю что одну-разъединственную парадигму, то я начну пытаться исказить формулировку задачи так, чтобы эта парадигма оказалась пригодна. Это называется «квадратно-гнездовым складом мышления (КГСМ)» и следует лозунгу «когда под рукой нет ничего, кроме молотка, всё вокруг кажется гвоздями». В предыдущем параграфе я привёл пример — раз кинематика представляет координаты, скорость и ускорение как функции времени, то лучше всего будет реализовывать кинематические задачи реактивным, желательно функционально чистым (хотя я лично не фанат чистоты в этом смысле), программированием. Однако, если человек только и знает, что ООП, то он сделает с точностью до наоборот — будет ежесекундно рассылать сообщения всем объектам, чтобы они изменили свои кинематические данные. Вместо одного Вселенского времени будет тысяча копий микровремени (вспоминается бутылочное время Желязны :)), по одной на каждый объект. Если забыл кому отослать — он отстанет, но виноват будешь ты сам. Как видно, ООП здесь отвратительно подходит под задачу. И тем не менее, мы не должны путать ОО-анализ, ОО-дизайн и ОО-реализацию! И уж тем более — «объектно-ориентированные языки», «основанные на объектах языки» и «чисто объектные языки». Ладно, пусть пример негодный. Действительно, гвоздь ведь загнулся не потому, что микроскоп был изобретён напрасно. Переберём все мыслимые задачи, которые встают перед программистами, чтобы отыскать те, которые хорошо ложаться именно на ООП. Может, на них мы сможем разобраться с тем, где заканчивается анализ и начинается проектирование, и чем это проектирование отличается от программирования? Но об этом в следующей серии, страна, заполночь уже, я спать пошёл. Arachnelis 20:32, 10 января 2014 (UTC)

• Если не возражаете, по позициям. --Goritconceptual 19:33, 12 января 2014 (UTC)
• "«парадигма» — это некий принятый и применяемый в определённом сообществе подход". Согласен. Но склонен уточнить. Не просто применяемый, а господствующий, являющийся преимущественно применяемым (в конкретный период времени). Кстати, прошу сообщить, устраивает ли такое уточнение (а то, что то закрадываются у меня смутные сомнения, что может и не устроить). --Goritconceptual 17:38, 14 января 2014 (UTC)

• Нет, не устраивает. По вашим словам, ФРП (ФРП в Викисловаре) - не парадигма, только потому, что её знает скажем тысяча человек на планете, что намного меньше тех сотен миллионов, что знают ООП. Arachnelis 14:43, 15 января 2014 (UTC)

• ФРП теперь в Википедии и Викисловаре есть. Однако, "наступила ночь и Шахерезада прекратила дозволенные речи". Завтра день будет, однако. --Gorvzavodru 20:46, 15 января 2014 (UTC)

• "Слово «подход» можно считать более широким... (надеюсь, опущение уместно)". Тоже согласен. --Goritconceptual 19:45, 12 января 2014 (UTC)
• "подход бывает индивидуальным и на парадигму не тянет. Но тогда это ОРИСС, увы." Тоже согласен. Если подход применяется только одним индивидумом - то он (в случае если это оригинальный подход) ОРИСС этого индивидума. Но если это один из ранее использовавшихся, отвергнутых текущей парадигмой, подходов - то это уже не ОРИСС а, получается, как бы "ретроградство". --Goritconceptual 10:57, 14 января 2014 (UTC)

• Это всё получается как бы словоблудие. Arachnelis 14:43, 15 января 2014 (UTC)

• "либо мы слово «подход» вообще не используем". Так, получается, не использовать понятие "подход" нельзя. Поскольку соотносится с парадигмой как общее с частным. Подходов - много: часть - ретроградство; часть - соответствует текущей парадигме; часть - оригинальные подходы (ОРИСС). --Goritconceptual 16:52, 14 января 2014 (UTC)
• " либо редиректим на парадигму". Дык, аналогично. Нежелательно общее на частное редиректить. --Goritconceptual 11:04, 14 января 2014 (UTC)

• Я в своей точке зрения уверен. Arachnelis 14:43, 15 января 2014 (UTC)

• получается дилемма либо-либо в данном случае неуместна. И не использовать нельзя и редиректить не след. Нужно искать другие варианты. --Goritconceptual 11:04, 14 января 2014 (UTC)

• Редирект. Вы не напишете двух содержательно существенных и при том разных статей про ОО-подход и ОО-парадигму. Arachnelis 14:43, 15 января 2014 (UTC)

• Далее
• "Получив задачу, я провожу её анализ". Я - тоже. --Goritconceptual 11:15, 14 января 2014 (UTC)
• "Если я вижу, что задача идеально ложится на некий известный мне подход (парадигму), то я его и применю для её решения". Вот тут сложнее. Обычно парадигма давлеет (поскольку господствует). Да и здорово от господствующей парадигмы отклониться - обычно проблемы с её горячяйшими сторонниками поиметь. Не все на это решаются. И опять таки, отвергнутые подходы - это ретроградство, а оригинальные - ОРИСС.
• И сдаётся мне, есть вероятность, что оттолкнулись мы от не вполне корректной терминологии... Давайте уточнимся. --Goritconceptual 12:27, 14 января 2014 (UTC)
• Первый вопрос: Вы термин Парадигма трактуете в духе Куна (как признанные всеми научные достижения, которые в течение определенного времени дают научному сообществу модель постановки проблем и их решений) или в духе Парадигмы программирования (как систему идей и понятий, определяющих стиль написания компьютерных программ; как способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером)? Я было начал в духе Куна трактовать. Это устраивает? Или лучше было в духе Парадигмы программирования? Прошу ответить. А то как бы не получилось что каждый о своём говорит... --Goritconceptual 17:40, 14 января 2014 (UTC)
• И второй вопрос: а таки, как Вы соотносите понятия подход и парадигма? Как общее и частное; или как частное и общее? --Goritconceptual 12:28, 14 января 2014 (UTC)
• Потому как иногда говорят: внутри парадигмы (хоть по Куну хоть программирования) может существовать несколько подходов к решению встающих проблем, ставящихся задач. Если от такого высказываня Вас не корёжит - тогда мы имеем соотнесение парадигмы и подхода как общего и частного. А если Вы нормально относитесь и к этому высказыванию и к выше приведённым пассажам - так получается, мы оперируем двумя значениями слова подход: одно значение - как общее по отношению к парадигме; другое - как частное. Тогда нам надо уточнения к слову подход вводить... (что, кстати, в Викисловаре и наблюдается: одно значение так как способ решения; другое - как совокупность взглядов.) Прошу ответить. --Goritconceptual 12:23, 14 января 2014 (UTC)

• Если не трудно, поведайте, кто такой Кун, а то нет ни времени, ни желания его копать. Ибо по нему получается, что парадигма - это нечто навязчивое, обязывающее. Т.е. я как бы должен программировать в объектном стиле не потому, что он там чем-то хорош, а потому что стаи мартышек индийского происхождения так делают. Типа "кухарки могут управлять государством". Это чушь - если я выбираю другую парадигму, пусть и менее популярную, то это не орисс. Что же касается устаревания - то вот разговор о возрасте и будет самим ориссом. Для меня, например, ООП - это ретроградство, но для вас - нет. Энциклопедия должна писаться вне времени. Arachnelis 14:49, 15 января 2014 (UTC)
• Сама по себе величина суммарного объёма макулатуры по предмету никоим образом не увеличивает содержание предмета. Одна статья на 20 листов может излагать больше единиц информации, чем тысяча талмудов вместе взятых. Горе-авторы, которым лишь бы заявить о себе, готовы рассусоливать много буков на пустом месте, но содержательности это не прибавляет (это к вопросу "дают научному сообществу модель постановки проблем"). А в энциклопедии обозревать информацию следует согласно содержанию, а не пропорционально объёму. Размазывать один предмет по десятку статей - значит, в разы затруднять понимание предмета читателем. Arachnelis 15:12, 15 января 2014 (UTC)

• и всё равно далее
• "Получается, что анализ — это процесс подбора подходящей к задаче парадигмы (до погружения в конкретную парадигму)." Тут согласен. Я бы, пожалуй, лучше выразился: процесс подбора подходящего к задаче подхода (способа решения) - если это возможно и уместно, в рамках текущей отраслевой парадигмы (по Куну). Или, как вариант (и, пожалуй, так лучше): процесс подбора подходящей к задаче парадигмы программирования. (кстати, получается, Вам ближе понятие парадигмы как системы идей и понятий, определяющих стиль написания компьютерных программ (если я не ошибаюсь) ). Впрочем, всё это не суть и словоблудство. Согласен, короче. --Goritconceptual 13:07, 14 января 2014 (UTC)
• последовавший период - возражений не вызывает. --Goritconceptual 18:13, 14 января 2014 (UTC)
• " мы не должны путать ОО-анализ, ОО-дизайн и ОО-реализацию!". Однозначно. Спутывание этих понятий (по сути, этапов разработки) весьма нежелательно. --Goritconceptual 18:16, 14 января 2014 (UTC)
• "И уж тем более (путать) — «объектно-ориентированные языки», «основанные на объектах языки» и «чисто объектные языки»." То да. Это тоже нежелательно. --Goritconceptual 18:18, 14 января 2014 (UTC)

• У меня был сарказм, если вы не поняли. Это одно и то же. Есть языки, в которых ООП реализовано хорошо, есть - в которых плохо. "Чисто объектных" языков (в значении "языков, в которых кроме ООП ничего нет") так же мало, как и чисто функциональных, большинство промышленных языков являются гибридными. Уточню, чтобы избежать непонимания и последующего жонглирования словами: в Python прекрасно воплощено ООП, т.е. вы бы назвали его "чисто объектным", но это гибридный язык, стоящий одной ногой в функциональной парадигме (аккурат сегодня пришлось растолковывать одному человеку странности поведения списков при присваивании из-за того, что императивная мутабельность сделана поверх типично функциональной модели представления данных). Arachnelis 15:41, 15 января 2014 (UTC)

• Вот о чём речь:

x = [[]] * 4
x[0].append('a')
x[1].append('b')
x[2].append('c')

print(x)
>>[['a', 'b', 'c'], ['a', 'b', 'c'], ['a', 'b', 'c'], ['a', 'b', 'c']]

• Arachnelis 19:01, 22 января 2014 (UTC)

• "Может, на (примерах задач) мы сможем разобраться с тем, где заканчивается анализ и начинается проектирование, и чем это проектирование отличается от программирования?". Дык, чего бы и не смочь...
• Так только разрешите напомнить, мы, собственно, начали не с поиска границы между этими понятиями, а с моего удивления по поводу того, что " "подход", "парадигма", "анализ", "проектирование" - психолингвистически тождественные понятия". Если хотите, можем и про границы между этими и другими упомянутыми понятиями поговорить. Так только, я (в облике Gorvzavodru) всего лишь возражал: а) против удаления пометки как некорректного для редиректа от ОО подхода к ОО программированию; б) против установки редиректа от ОО проектирования на ОО программирование (да и ещё с удалением имеющегося, хотя и далёкого от совершенства, текста).
• Я закончил свои комментарии и вопросы к Вашему тексту. Ваш ход. --Goritconceptual 18:57, 14 января 2014 (UTC)

• Итак, краткое содержание предыдущей серии: выделение из "анализа" - "ОО-анализа" - это КГСМ. ОО-анализ - это просто некие особенности анализа, проявляющиеся при работе в рамках применения ОО-парадигмы, и не более того. Обратите внимание - в рамках. Представьте: проводим ОО-анализ, потом внезапно переключаемся на проектирование в процедурном стиле, тщательно прорабатываем всю последовательность GOTO-переходов, и, наконец, воплощаем построенную модель на Прологе. Бред, да? Это потому, что на самом деле программирование делится не на пятнадцать этапов, а всего на три. Сперва мы анализируем ТЗ и производим декомпозицию сложной задачи на систему простых. Затем, для каждой подзадачи, смотря по тому, является ли она структурной или вычислительной, соответственно, либо занимаемся проектированием (это больше творческий процесс), либо подбираем структуры данных и алгоритмы (это более формальный процесс). Arachnelis 15:25, 15 января 2014 (UTC)
• В первом случае (для задачи структурного плана) ООП служит инструментом обеспечения модульности и инкапсуляции, т.е. структурирования больших и сложных программ (я не говорю "систем", поскольку в большинстве случаев это не так). Проще говоря, это ООП-рамки (каркас), в которые оборачивается код реализации (решение алгоритмических задач). А сам этот код воплощает совершенно иные модели - либо процедурные, либо функциональные. В VisualProlog вообще получается, что внутри Simula style OOP идёт логика предикатов - Пролог, обутый в Delphi-проектирование. Откровенно говоря, для задачи обеспечения модульности и инкапсуляции ООП вовсе на самый лучший инструмент - средства функциональных языков даже при неумелом использовании с этим справляются несоизмеримо лучше - но это выходит за рамки данного обсуждения. Хорошо ли, плохо ли, но 90% случаев применения ООП в действительности - не более чем модульность+инкапсуляция, и лишь 10% полноценного объектного моделирования. И вот это полноценное объектное моделирование (что, повторюсь, встречается крайне редко) и служит инструментом решения алгоритмических задач. И единственная известная мне задача, для которой это действительно является вменяемым решением, а не забиванием гвоздей микроскопом,- это агентное моделирование. Заметьте, на ОО-анализ мы не наткнулись, хотя прошли от ТЗ уже к ОО-проектированию и ОО-реализации. Arachnelis 15:25, 15 января 2014 (UTC)
• Если же рассматривать и другие парадигмы на втором этапе, то такое разделение (на задачи проектирования и алгоритмические) даже не обязательно произойдёт. Почитайте ЯОП и обратите внимание на раздел про особенности подхода Хьюдака. Это фронтовая линия информатики, которая заключается в том, чтобы сделать спецификации непосредственно исполнимыми (безо всяких промежуточных генераций каркасов и прочих чисто программистских трюков). Говорить, что это не парадигма, нельзя, не важно, что она количественно не доминирует в мире. Короче, слово "господствующий" в определении слова "парадигма" является ошибкой. Даже когда небольшое сообщество (но большее, чем два друга на скамейке с пивом) работает в одном направлении, можно говорить о парадигме. Arachnelis 15:25, 15 января 2014 (UTC)
• Третий этап зависит от всего, что было на втором. Для ОО-проектирования мы начинаем вычерчивать простыни UML-ных картинок, причёсывать их паттернами и рефакторить. Для ОО-реализации мы берём язык, в котором ООП реализовано непосредственно (дилетанты обычно называют такие языки "чисто объектными") и кодируем. ОО-реализация возможна, даже если проектная часть общей задачи была решена не ОО-проектированием, а каким-то другим. Например, в Python превосходно реализована объектная парадигма, но Haskell-программа на Python намного лучше по многим показателям, чем C++/Java-программа на Python.
• Так что отделять ОО-программирование от ОО-языков можно (если напишем достаточно много про различия в реализации ООП в разных языках), но ОО-парадигму и ОО-подход следует направлять на ОО-программирование, а ОО-анализ рассматривать как его составную часть. Arachnelis 15:25, 15 января 2014 (UTC)
• Сообразил, что лучше так:

ОО-программирование

ОО-языки

ОО-проектирование, в нём разделом ОО-анализ

ОО-дизайн редиректим на на ОО-проектирование

ОО-подход и ОО-парадигму редиректим на ОО-программирование

Arachnelis 19:00, 15 января 2014 (UTC)

• К сожалению, Goritconceptual не сможет продолжить эту, столь увлекательную беседу. Насколько я понял, он забанен навечно. Придётся ему пока покоиться с миром. RIP. Мои извинения от имени Gorvzavodru. --Gorwikilinkonly 13:42, 18 января 2014 (UTC)

• Честно говоря, я так и не понял с каким количеством человек разговаривал, ну да ладно, надеюсь содержание разговора пойдёт на пользу статье. Хочу добавить: поглядите количество статей в английском разделе: en:Object-orientation. Никакого "approach" или даже "paradigm" нет - но есть "программирование", "проектирование", "моделирование" и пр. Обратите внимание, куда редиректится en:Object-oriented analysis - это как раз то, о чём я говорю. При входе на статью "программирование" сверху висит предупреждение о дисамбиге с ОО-языками. Но статьи "ОО-языки" как таковой нет, есть только en:List of object-oriented programming languages. Всё-таки там уровень CS-грамотности выше на несколько порядков, чем у нас. И хотя в данном конкретном случае, на мой взгляд, в английской тоже есть избыточность (я бы объединил первые две статьи в списке en:Object-orientation), я скажу, что в любом случае лучше просто перевести их статьи один-в-один. И совсем субъективно - про OOUI я бы удалил нафиг, но там больше десятка АИ, так что по здешним законам писать придётся, а разделом спорно куда втыкать - в "программирование" или в "проектирование", так что придётся тоже. Но, серьёзно, для раскрытия этой темы реально хватает визуального программирования и "моделирования", тем более, что она, к счастью, уже давно и планомерно отмирает в пользу чисто декларативного взгляда на GUI, а сейчас уже набирает обороты реактивный. Arachnelis 19:01, 22 января 2014 (UTC)

Первоисточники?

Господа писатели, слышал ли кто-нибудь из вас как определяет «Объектно-ориентированное программирование» автор? 5.228.253.182 16:48, 31 декабря 2014 (UTC)

• Встречный вопрос (должный ответ был бы просто подарком): у вас есть АИ, который бы подчеркнул, что в свете Симулы термин «Объектно-ориентированное ПРОГРАММИРОВАНИЕ» вообще не использовался, а появился только у Кэя? Если дадите источники, я бы уж сформулировал статью так, что ни один фанат потомков Алгола не подкопается. Arachnelis 16:44, 2 января 2015 (UTC)

Вопросы и предложения

Изменил ссылку «Интерфейс(ООП)» на «Интерфейс» в определении класса. Правка была отклонена с комментарием от Oleg3280 «статья об ООП, ссылка была правильной. откройте тему на СО)». В итоге у меня получился такой текст.
1. Понятия не имею, что такое «СО». И думаю, если сам уважаемый Oleg3280 попробует построить запрос для поисковика на тему «СО» и найти этого зверя, он столкнется с трудностями. Отсюда простой совет. Если вы пытаетесь побудить другого человека к ответному действию, и тем более, если предъявляете ему претензии, убедитесь, что он вас понимает. Обычно для этого достаточно использовать слова русского языка, либо, если есть какие-либо внешние ограничения, хотя бы подходящие ключевые слова. Если вы конечно рассчитываете на диалог, то есть если речь не идет о злонамеренном вандализме. Например, если «СО» означает «Страница Обсуждений», то «на Обсуждениях» будет в 100500 раз лучше, чем на «на CO». «лучше в 100500 раз» - это значит «обратное нельзя категорически, можно только детям».
2. Волей случая, я являюсь автором текущего определения класса на этой странице, соответственно мне все таки лучше знать, какой именно «интерфейс» я имел в виду. И если это вызывает несогласие, то именно с этой претензии здесь должна начинаться тема, а не с моих объяснений. Тем более, если это повторное (увы, первое просмотрел) несогласие по фрагменту цельного текста. Это не только приличней, но и логичней, даже в условиях Википедии.
3. Само определение любого предмета – интерфейс (неизбежный посредник) публичного понимания сути этого предмета. Не имея полноценного определения, вы не можете нормально ссылаться на это понятие, так как на вопрос «а что это?» останется только тыкать пальцем на предмет, подразумевая свой опыт общения с ним, возможно даже очень богатый, но неизвестный снаружи. То есть «обычный» интерфейс достаточно фундаментальное и элементарное понятие, чтобы использовать его в определениях.
4. Вообще, чем более общая терминология используется в определении, тем оно лучше. Некоторые нюансы смысла есть только в общих понятиях: именно благодаря порождению из общего интерфейса набора специальных, можно использовать сочетание «интерфейсная природа». Внутренняя же, специальная терминология может использоваться только если нужен смысл именно этого конкретного термина, то есть исключительно по месту. Но при этом такой термин должен быть структурно более элементарным и уже определенным здесь же, но раньше текущего определения. Определение предмета из себя же или из равноуровневых предметов – наихудшее, так как уже для понимания собственно текста, нужно очень хорошо и непосредственно знать предмет, фактически, это вообще не определение, в этом качестве такой текст использоваться не может в принципе. И в любом случае, если можно дать определение, понятное не только ООПрограммистам, то именно его и нужно давать.
5. Наконец, собственно по ссылке «Интефейс(ООП)». Очень сильное подозрение, что первый раз ее добавили случайно только потому, что там есть «(ООП)». Потом ее случайно почти год не меняли обратно. Наконец, во второй раз ее случайно добавили только по причине первых двух причин. То есть «Интефейс(ООП)» - совершенно параллельное классу понятие, в котором делается упор на «обязательство по отложенной реализации», и что оно делает в определении класса (=почему «ссылка была правильной») как раз должны были бы сначала объяснить авторы перечисленных правок.
Почему все наоборот? — Эта реплика добавлена с IP 89.239.190.23 (о) 10:14, 29 июня 2017 (UTC)

Ответы

• СО — это стандартное сокращение, которое значит Страница Обсуждения (статьи или участника). Полностью комментарий не получился бы, так как есть ограничение на длину комментария к правке. Oleg3280 (обс.) 13:25, 29 июня 2017 (UTC)

• лично для меня это замечательная возможность запомнить значение слова «Глоссарий» и то, что на Википедии он есть. Но в целом проблему это не решает. Априори, редактирующий содержание местной статьи все же не обязан быть посвящен в местный редакторский(модераторский) жаргон. Как минимум один раз должна быть явная ссылка из правки. При всех условностях и ограничениях, в Инете все должно быть удобно и быстро. 89.239.190.23 15:23, 30 июня 2017 (UTC)

• Страница Интерфейс (объектно-ориентированное программирование) раскрывает это понятие с точки зрения ООП, тогда как Интерфейс даёт общее представление. Ещё есть дизамбиг Интерфейс (значения). Кроме того, принято давать внутреннюю ссылку на статью, которая наиболее точно раскрывает суть темы, а не на общую, обзорную статью. Oleg3280 (обс.) 13:25, 29 июня 2017 (UTC)

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

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

Отдельно хочу обратить внимание на выбор «внутренних ссылок». Развивая свой п.4 , хотелось бы по крайней мере понятно обозначить свою личную позицию на этот счет. Специализация должна касаться в первую очередь темы и только в последнюю очередь языка, то есть терминология должна оставаться максимально общей в смысле общедоступной. Это в данном случае волюнтаристский, но имхо стратегический момент для Википедии. Где-то выше в обсуждениях встретил сочетание «изложение «от правильного к обзорному»». Могу согласиться, если есть общепринятое «правильное» или явно наилучшее по простоте. Если же в каждом учебнике определение видоизменяется, то местное все равно придется делать достаточно обзорным. В любом случае, чем быстрее в статье будет понятно изложена основная идея, тем лучше.

Возвращаясь от общих вопросов по Википедии к конкретной проблеме, остается только (на всякий случай еще раз) добавить, что смысл «интерфейса(ООП)» - описание будущего взаимодействия с будущим «черным ящиком», это совершенно независимая от класса сугубо интерфейсная сущность – обязательство на потом себе же (набросок, который можно уже полноценно использовать при проектировании окружения или пока оставить как закрытый этап, переключаясь на совершенно другие, более важные направления), под которым класс может подписаться, а может и не подписываться: тогда на его интерфейс (обычный, который все равно есть) никаких предварительных условий не будет. Поэтому «интерфейс(ООП)» никоим образом не может «наиболее точно раскрывать суть» класса, хотя некоторая рифма есть. 89.239.190.23 15:23, 30 июня 2017 (UTC)

• Поэтому правка была отменена. Oleg3280 (обс.) 13:25, 29 июня 2017 (UTC)
• Призываю на помощь участника Arachnelis, так как боюсь, что корректно ответить с точки зрения программирования не смогу. Oleg3280 (обс.) 13:25, 29 июня 2017 (UTC)

• верно, хотя и запоздало. 89.239.190.23 15:23, 30 июня 2017 (UTC)

еще раз про определение ООП

Удручает вид заглавного определения ООП. Прежде всего неясно, зачем нужны 2 ссылки (номера 2 и 3) на одну цитату, которая тут же дословно повторяется с третьей ссылкой туда же. В книжке такое дублирование текста выглядит еще более-менее нормально, в начале же вики-статьи выглядит как «sic!». То есть текст тратится малопродуктивно. Ссылка номер 1 вообще невразумительна, даже в виде примечания такое описание второстепенного исключения при недописанном правиле выглядит странно.
С другой стороны, как раз для такого сложного понятия стоило бы сразу за определением дать некоторую «культурологическую справку» с ответами на вопросы вроде «откуда взялось?», «зачем нужно?», «почему именно такое?», «ну и что?», то есть определение в широком смысле и общих терминах – вообще говоря в совершенно другой плоскости (даже при частичном буквальном пересечении с заглавным определением и основным содержимым статьи). Эту свою идею, уже высказанную как принцип в предыдущей теме, я бы хотел проиллюстрировать на примере данного определения.
Соответственно - добавил правку. По поводу возможных ОрИсс-претензий могу сказать только, что старался излагать наиболее очевидные вещи в достаточно общей форме, возможно есть более удачный вариант решения этой задачи.
Даже если не приживется, хотелось бы, чтобы это имелось в виду

лишний принцип - абстракция

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

Нужен источник, откуда взяли абстракцию как принцип ООП. При том, что сама по себе абстракция в любых парадигмах существует, сама по себе "переменная" - это абстракция для именованной области памяти. Если речь про соединение данных и методов - то это уже инкапсуляция 95.31.181.35 11:01, 16 октября 2022 (UTC)

• Поставить запрос источника на утверждения с абстракцией. Если источники не будут указаны, то через 2 недели удалить эти утверждения. — Mike Somerset (обс.) 09:44, 24 октября 2022 (UTC)

Откуда вообще взялись типы в ООП?

Взять, для примера, Smalltalk. Где там типы?

Да, посколько в сознании масс закрепилась идея, что "без типов плохо", то пишут про "динамическую типизацию". Но по факту никакой типизации нет! Любому объекту можно послать любое сообщение. На какие-то сообщения объект ответит, связав это сообщение с методом и выполнив его, на какие-то ответит через #doesNotUnderstand:. Но где тут типизация? Chaetal (обс.) 15:10, 5 июня 2024 (UTC)

Билеберда в определении

Вот этот текст откуда взялся? Что за ерунду в статью воткнули? Считаю надо чистить, править. Какое отношение эти определения имеют к теме статьи? Ознакомьтесь с кратким определением терминов. А. Астафьев 12:35, 19 октября 2024 (UTC)