Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 172
Холивар высосан из пальца, все, кроме заключения — интересно, а ссылочки в статье заставили отложить работу на часок :)
Трудночитаемо. Может переработать текст или представить графическом виде важные эпизоды развития ООП?
В графическом — это как? Со смайликами и картинками того, как выглядит наследование? :)
Нет. Представить, например, как представляются различные эры развития земли. А вместо временной шкалы, представить различные концепции, которые наиболее серьезно повлияли на развитие ООП и языков в целом. В квадратиках же написать названия языков и технологий с важными связями.
Извините, я на такое не способен. Отсутствует художественный вкус. А черчение я со школы не люблю :) Мне проще текстом мысли излагать. Жаль, что, наверное, это снизит количество тех, кому статья понравилась, но ничего не поделаешь. Каждому свое. Если нарисуете — вставлю с удовольствием.
Я думаю историю ООП надо представлять как дерево. Это не развитие от плохого к хорошему (типа Simula → Smalltalk → C++ → Java), создание новых идей и их развитие (Ruby, JS, Self и т. д.)
Вы еще забыли про Смолтолковский true message passing, когда описывали «чистый» ООП. А еще, что интересно, ООП может относиться не к языку, а к технологии. COM тому пример.
А тот «странный» человек, с которым вы спорили, в некотором смысле прав. Только он сильно путает принципы и реализацию, и еще фанатично уверен в том, что ООП бывает только прототипный.
Основа ООП — это message passing, что в современных скриптовых языках реализуется как динамическая типизация и механизм call-by-name, отсюда и его высказывания про то, что «динамизм — основа ООП».
Далее, в случае прототипного ООП исчезают сами классы, отсюда и наследование в классическом понимании тоже исчезает, потому он и говорит, что «наследование для ООП чужеродно».
Думаю, что фанатизма надо меньше, а терпимости к чужой точке зрения больше. Тем более, что, как ни странно, вы оба правы (пока дело не доходит до взаимных оскорбительных выпадов)
А тот «странный» человек, с которым вы спорили, в некотором смысле прав. Только он сильно путает принципы и реализацию, и еще фанатично уверен в том, что ООП бывает только прототипный.
Основа ООП — это message passing, что в современных скриптовых языках реализуется как динамическая типизация и механизм call-by-name, отсюда и его высказывания про то, что «динамизм — основа ООП».
Далее, в случае прототипного ООП исчезают сами классы, отсюда и наследование в классическом понимании тоже исчезает, потому он и говорит, что «наследование для ООП чужеродно».
Думаю, что фанатизма надо меньше, а терпимости к чужой точке зрения больше. Тем более, что, как ни странно, вы оба правы (пока дело не доходит до взаимных оскорбительных выпадов)
Кстати, я бы еще добавил, что сейчас границы ООП довольно сильно размыты. И никто точно уже не может сказать, каковы же его основные принципы так, чтобы вроде «вот эти — да, а остальные — нет»
Ну это не он уверен, это такая известная цитата Кея, в которой он говорит что есть только 2 тру OOP языка — Smalltalk и LISP, а остальные от лукавого.
Нашел кстати
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.
Cheers,
Alan
2003-07-23
Да, обратите внимание на «to me» и на год.
Ну это потому что из переписки. К нему обращается преподаватель программирования и говорит, что вот, под термином oop сейчас понимают черти что, а я сейчас пишу курс и поэтому хочу обратится к вам, человеку который ввел термин OOP и чтобы узнать что _вы_ вкладываете в этот термин. Поэтому логично что Key начинает ответ с to me.
Что касается года, то я не очень понял.
Разве за последние 7 лет что-то так кардинально в яве поменялось и она стала строго подходить под эти определения? Я на ней правда примерно с 2003 и не писал, но вроде слежу немного и не должен был пропустить революцию ).
Или вы имеете в виду, что может к 2010 Алан Кей одумался, понял каким дураком был 35 лет и осознал что был неправ и java это настоящее OOP? )
Что касается года, то я не очень понял.
Разве за последние 7 лет что-то так кардинально в яве поменялось и она стала строго подходить под эти определения? Я на ней правда примерно с 2003 и не писал, но вроде слежу немного и не должен был пропустить революцию ).
Или вы имеете в виду, что может к 2010 Алан Кей одумался, понял каким дураком был 35 лет и осознал что был неправ и java это настоящее OOP? )
Алан не говорит, что «ООП вообще — это то-то и то-то». Он говорит «ООП для меня — это то-то и то-то», а это разные вещи. Алан говорит о своем мнении, он не устанавливает догм. Поэтому логично, что он говорит «to me». Он не говорит о том, что настоящее, а что нет. Он говорит «ООП для меня».
Что касается года, я просто имел ввиду, что за 7 лет ООП шагнуло вперед. Наука ведь не стоит на месте. И говорить, что «вот там было ООП, а вот это уже непонятно что» по меньшей мере странно.
Вы не ответили на мой вопрос выше. Вы не согласны с моими рассуждениями по поводу того, что Алан не имеет монополии на термин ООП?
Что касается года, я просто имел ввиду, что за 7 лет ООП шагнуло вперед. Наука ведь не стоит на месте. И говорить, что «вот там было ООП, а вот это уже непонятно что» по меньшей мере странно.
Вы не ответили на мой вопрос выше. Вы не согласны с моими рассуждениями по поводу того, что Алан не имеет монополии на термин ООП?
Я вообще не очень понимаю что значит монополия на термин. Однажды человек взял и выделил некоторые принципы построение систем. Не обязательно комьютерных, у него по-моему в оригинале вообще приводился пример с клетками — Кей-то биолог в том чисе по образованию. Дал этому название.
Потом кто-то прочитал эти принципы, применил часть их в своем языке, который вышел в мейнстрим и все — теперь куча людей думает что ООП — это когда написано Class. А если его нет, то значит это и не ооп уже.
Потом кто-то прочитал эти принципы, применил часть их в своем языке, который вышел в мейнстрим и все — теперь куча людей думает что ООП — это когда написано Class. А если его нет, то значит это и не ооп уже.
Что удивительно, этому определению очень хорошо — прямо-таки идеально соответствует Erlang — язык, который _никогда_ не заявлял, что он имеет отношение к ООП
Согласен, кстати, про эрланг )
Посмотрите последнее интервью создателя Эрланга для InfoQ, там он говорит что понимал под ООП все время совершенно другое, пока не познакомился с идеями смолтока, и называет Эрланг ООП языком.
Ссылку можно? В Erlang ведь нет ни классов, ни объектов, по-моему. Какое же там ООП?
Самое настоящее, инкапсулированные сущности общающиеся сообщениями.
www.infoq.com/interviews/johnson-armstrong-oop
Joe Armstrong: "… Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism."
www.infoq.com/interviews/johnson-armstrong-oop
Joe Armstrong: "… Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism."
Не сказал бы, что самое настоящее, но, видимо, есть. Во всяком случае, что-то такое, что я даже назвать не могу :) Армстронг, во всяком случае там не так категоричен. Вот пример хороший:
weblog.plexobject.com/?p=1572
weblog.plexobject.com/?p=1572
Хаха. Честно, я когда писал выше комент про Class этого еще не читал, так что не воспримите как личный наезд пожалуйста. Но тем не менее отличная иллюстрация )
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
А в Erlang есть разве Local retention and protection and hiding of state process? Как это реализуется?
Local retention and protection and hiding of state process там есть: между акторами (Erlang-процессами) никакие сущности не разделяются, обмен между процессами идет только посредством посылки сообщений друг другу, чтобы использовать кодо-функцию из модуля, её надо импортировать.
Насчёт late-binding по отношению Erlang не могу сказать, о чем нужно тут говорить: но, например, аргументы импортированных из модулей функций не типизируются, и есть горячая замена кода
Насчёт late-binding по отношению Erlang не могу сказать, о чем нужно тут говорить: но, например, аргументы импортированных из модулей функций не типизируются, и есть горячая замена кода
если не требуются внешние ручки, то компилятор вполне может и статически всё слинковать на основе контрактов.
наследование — оно и в африке наследование. какая разница класс от класса наследуется или объект от объекта?
наследование — оно и в африке наследование. какая разница класс от класса наследуется или объект от объекта?
Чисто формальное замечание: мне кажется, блог «История ИТ» подошел бы больше.
Нет ну сказать что JAVA не ООП язык это сильно… Василий отжог… Он по любому не прав был когда это запостил. Динамизм динамизмом, ООП ООП )))))
а зомби зомби зомби:)
Java — не ООП ещё по нескольким причинам. )))))))))))))
</troll>
ООП, конечно, просто количество костылей немного сбивает с толку. )))))))))славалисперам))))))))))
ООП, конечно, просто количество костылей немного сбивает с толку. )))))))))славалисперам))))))))))
Какие например костыли? ) Мне кажется JAVA стройный, строгий и логичный )
Абстрактные классы, интерфейсы, примитивы vs. объекты-оболочки (с autoboxing), декораторы для метапрограммирования — всё это «лишнее», его пришлось добавить чтобы прийти к статической типизации.
Если смотреть на оригинальные ООП-языки (и их идеологические потомки в виде Ruby и т. д.), то там всё это не нужно.
Если смотреть на оригинальные ООП-языки (и их идеологические потомки в виде Ruby и т. д.), то там всё это не нужно.
Хм, не нужно это не значит бесполезно. Я лично с трудом представляю крупный проект без абстрактных классов и интерфейсов.
Дело в том, что они нужны только для статической типизации. Если ваши методы могут работать с любым объектом (имеющим нужный метод), то нет необходимости и в лишних слоях наследования, которые просто гарантируют что-то компилятору (гарантировать нужно разработчику с помощью автоматических тестов :) ).
Кривые руки конечно и в Африке кривые руки, но чем плоха дополнительная гарантия?
Тем что ради неё нужно вводить целый ряд не нужный слоёв в программе и абстракций в языке. И тем что это гарантия ничего не даёт если у нас есть нормальные тесты (без которых говорить об надёжности не имеет смысла).
Я согласен, что проверка компилятором лучше, чем отсутствие проверки. Но усложнение программ и языка идёт гораздо больше, чем мы получаем преимуществ.
Я согласен, что проверка компилятором лучше, чем отсутствие проверки. Но усложнение программ и языка идёт гораздо больше, чем мы получаем преимуществ.
Я не согласен. На мой взгляд, как абстрактные классы, так и интерфейсы в некотором роде документируют и улучшают понимание кода, который вы читаете. В Ruby они не нужны, но я предпочитаю иметь возможность видеть отделение интерфейса от реализации. Например, у нас есть проект, в нем есть различные драйверы БД. В PHP я бы реализовал для драйвера интерфейс или абстрактный класс. Он получился бы маленьким и легким для понимания. Все остальные драйверы его бы реализовывали (или наследовались бы от него). Пришел бы другой программист, которому нужно было бы понять, как выглядит слой абстракции БД в данном проекте. Вуаля. Он смотрит только на интерфейс и все понимает. А если интерфейса просто нет за ненадобностью? Зачем он нужен, если везде dynamic dispatch?
Причем, это еще и средство автоматической проверки на ошибки. Допустим, выходит Major релиз проекта, в котором интерфейс меняется и я отвечаю за доработку всех драйверов для его поддержки. Меняем абстрактный интерфейс и все перестает компилироваться, пока мы не согласуем интерфейс драйвера с его абстракцией.
Причем, это еще и средство автоматической проверки на ошибки. Допустим, выходит Major релиз проекта, в котором интерфейс меняется и я отвечаю за доработку всех драйверов для его поддержки. Меняем абстрактный интерфейс и все перестает компилироваться, пока мы не согласуем интерфейс драйвера с его абстракцией.
Согласен, что иногда удобно ввести определённый слой. Но что мешает сделать это с помощью обычных классов? ;)
Про автоматическую проверку я уже говорил. Она конечно полезна, но автоматических тестов не заменяет. А имея автоматические тесты проверка не нужна.
Про автоматическую проверку я уже говорил. Она конечно полезна, но автоматических тестов не заменяет. А имея автоматические тесты проверка не нужна.
Если в данном случае сделать это обычными классами, будет неясно, что данный класс не следует инстанцировать и почему. Все нужно будет документировать отдельно.
А автоматические тесты — это прекрасно, но не всегда. Да и не всегда их удобно постоянно запускать, например, если проект сильно распределенный. Кроме того, TDD требует особого мышления разработчиков и не все крупные проекты ее внедряют.
А автоматические тесты — это прекрасно, но не всегда. Да и не всегда их удобно постоянно запускать, например, если проект сильно распределенный. Кроме того, TDD требует особого мышления разработчиков и не все крупные проекты ее внедряют.
Но проблема в том, что в статической типизации у разработчика нет выбора, ему надо внедрять слои абстракции и там, где это не удобно. В динамической типизации есть специальные расширения (типа abstract для Ruby), которые можно использовать там, где это действительно нужно.
Но без тестов бессмысленно приводить надёжность в пример, так как большая часть ошибок совсем другого рода, нежели смена API.
Но без тестов бессмысленно приводить надёжность в пример, так как большая часть ошибок совсем другого рода, нежели смена API.
Кстати, динамические языки на мой взгляд, более медленны и менее надежны (например, для серьезного программирования вроде контроллеров ядерного реактора :) ). Надеюсь, еще никому не пришло в голову написать программу для работы двигателя космического корабля на Ruby? :)
Все же динамическая типизация привносит в проект свободу, которую потом трудно загнать снова в клетку с помощью тестов. В абстрактном проекте хорошо говорить, что код должен быть покрыт тестами на 100%, но в реальной жизни так бывает редко. Так что помощь компилятора весьма кстати.
А еще кстати :) Я предпочитаю, чтобы меня контролировали :) Я не люблю фреймворки и языки с БЕЗГРАНИЧНОЙ СВОБОДОЙ. Свобода — это хорошо, но лишь до определенной степени. Я люблю структуру, правила и четкость. Скажем, меня всегда путали тучи синонимов методов в Ruby типа size? и length?.. Люблю PHP, но терпеть его не могу за то, что каждый раз я вспоминаю: «так, тут у нас str_pos или strpos? А вот здесь первым параметром haystack или все же needle?».
Все же динамическая типизация привносит в проект свободу, которую потом трудно загнать снова в клетку с помощью тестов. В абстрактном проекте хорошо говорить, что код должен быть покрыт тестами на 100%, но в реальной жизни так бывает редко. Так что помощь компилятора весьма кстати.
А еще кстати :) Я предпочитаю, чтобы меня контролировали :) Я не люблю фреймворки и языки с БЕЗГРАНИЧНОЙ СВОБОДОЙ. Свобода — это хорошо, но лишь до определенной степени. Я люблю структуру, правила и четкость. Скажем, меня всегда путали тучи синонимов методов в Ruby типа size? и length?.. Люблю PHP, но терпеть его не могу за то, что каждый раз я вспоминаю: «так, тут у нас str_pos или strpos? А вот здесь первым параметром haystack или все же needle?».
Тогда вам больше понравится Python :). Там есть правило, что должен быть только один способ сделать это (в Ruby придерживаются альтернативного пути, поэтому и несколько методов).
Да, Питон мне не нравится по другим всяким причинам :)) Видно, мне вообще трудно угодить. Нравился C#, но вот уже некоторое время я начинаю думать, что его чрезмерно усложняют, наводняя всякими новомодными штучками, чтобы не зря выпустить новую версию :) Удобными штучками, спору нет, но learning curve… Java вроде более консервативна, но с тех пор, как она попала к Oracle… Неизвестно, что там получится.
Не думаю, что надёжность — это свойство динамических языков. Есть вещи, которые влияют на надёжность гораздо сильнее.
Например, стоит гораздо больше волноваться, что ПО ядерного реактора не имеет тестов (я согласен, что иногда лень покрывать тестами бизнес-приложения, но тут как раз хороший пример :) ).
Ну и опять же, помощь компилятора гораздо меньше, чем мне требуется помогать ему (достаточно просто посчитать, сколько лишних символов надо вводить, чтобы указывать везде типы и сколько лишних интерфейсов).
Например, стоит гораздо больше волноваться, что ПО ядерного реактора не имеет тестов (я согласен, что иногда лень покрывать тестами бизнес-приложения, но тут как раз хороший пример :) ).
Ну и опять же, помощь компилятора гораздо меньше, чем мне требуется помогать ему (достаточно просто посчитать, сколько лишних символов надо вводить, чтобы указывать везде типы и сколько лишних интерфейсов).
Я думаю, про нашу помощь компилятору вы не правы. Ввод символов — чепуха. Программист думает в первую очередь головой. А если скорость печати начинает влиять на производительность… что это, машинные коды? Это программист, в конце концов, или машинистка?
То, что «есть вещи...» я понимаю. Но вы согласны, что динамическая типизация все же снижает надежность кода? При равном количестве тестов, скажем?
То, что «есть вещи...» я понимаю. Но вы согласны, что динамическая типизация все же снижает надежность кода? При равном количестве тестов, скажем?
Если тестов нет, то надёжность в дин. языках ниже. Но моя точка зрения в том, что разница невелика, а если есть нормальные тесты, то надёжность одинакова.
Например, в нашем Ruby on Rails проекте за пару прошедших месяцев (у нас Hoptoad записывает все исключения на сервере) все NoMethodError связаны только с тем, что был передан nil (аналог null) вместо объекта (в Java это было бы NullPointException). То есть на реальном проекте за пару месяцев не было ошибок связанных с динамической типизацией.
Например, в нашем Ruby on Rails проекте за пару прошедших месяцев (у нас Hoptoad записывает все исключения на сервере) все NoMethodError связаны только с тем, что был передан nil (аналог null) вместо объекта (в Java это было бы NullPointException). То есть на реальном проекте за пару месяцев не было ошибок связанных с динамической типизацией.
Когда кажется, креститься надо :)
Будь он простым, стройным и логичным, не нужны были бы ни книги вроде Java Puzzlers, ни Generics FAQ.
Будь он простым, стройным и логичным, не нужны были бы ни книги вроде Java Puzzlers, ни Generics FAQ.
Надеюсь в своей реплике Вы не противопоставляли динамизм ООПу? ;)
Нет, мне кажется эти понятия вообще не стоит сопоставлять. Динамизм как грица динамизмом… А принципы принципами…
Ну тут как подходить к вопросу :). Если под термином ООП мы понимаем Smalltalk и первые реализации ООП, то там объекты не вызывали методы друг друга, а посылали события. Технически это выглядит как динамическая типизация (не примитивов, а объектов). Так что исторически эти две вещи связаны.
Ну… ООП это ведь скорее идеология и она только исторически связана со Smalltalk etc. Если Smalltalk более ранний язык в стиле ООП, это же совсем не значит что он должен быть шаблонным…
Ну там как раз дело в идеологии. Вместе со Smalltalk была идеология ООП — что всё должно быть объектами, которые обмениваются сигналами. Это конечно было давно, но всё же динамическая типизация связана с ООП, хотя бы историей (первыми определениями).
По моему ООП уже давно вышла за рамки Smalltalk :)
Каким образом? По-моему дальше уже просто некуда… :) Это ж надо, вообще все — объект. Даже сами блоки программы :) :)
К сожалению то, что называется ООП везде никогда в рамки смолтока не входила. Еще создатели симулы были в удивлении от того что язык все используют не верно и не ловят сути.
Факты пожалуйста. Что называется, кто удивлялся, что говорил, в какие рамки.
«I still think that many people who refer to Simula only grasp parts of it. In fact, those who understand Simula best are not the people in programming research, but rather Simula's simulation users. The computer scientists like Simula as a vehicle for implementing abstract data types.» Nygaard and Dahl, «Development,» p. 485.
То же и со смолтоком было, проблема не столько в языках, столько в идеологии.
Абстрактные типы данных и классы – разные вещи.
Наследование и расширения типа – разные вещи.
То же и со смолтоком было, проблема не столько в языках, столько в идеологии.
Абстрактные типы данных и классы – разные вещи.
Наследование и расширения типа – разные вещи.
Мне кажется, вы искажаете факты.
«Я по-прежнему думаю, что многие, кто ссылаются на Simula, понимают ее лишь частично. На самом деле, лучше всего понимают ее не исследователи парадигм программирования, а те, кто пользуется ей для симуляции процессов. Компьютерным специалистам она нравится в качестве предмета для реализации абстрактных типов».
И речи не идет о Smalltalk или ООП вообще. Как и о том, что все используют язык неверно. Давайте будем оставаться корректными.
«Я по-прежнему думаю, что многие, кто ссылаются на Simula, понимают ее лишь частично. На самом деле, лучше всего понимают ее не исследователи парадигм программирования, а те, кто пользуется ей для симуляции процессов. Компьютерным специалистам она нравится в качестве предмета для реализации абстрактных типов».
И речи не идет о Smalltalk или ООП вообще. Как и о том, что все используют язык неверно. Давайте будем оставаться корректными.
Симула выдвинула идеи симуляции реальных сущностей. Смолток выдвинул эту идею на новый уровень и предоставил механизмы для этого.
Люди же используют эти механизмы для реализации абстрактных типов данных.
Цитата из книги Кента Бека «Smalltalk Best Practice Patterns»:
Some of the biggest improvements [of using Beck's patterns] come from figuring out how to eliminate … structural code, where one object treats another as a data structure. … It is much preferable to give an object more responsibility rather than have it act like a data structure.
Люди же используют эти механизмы для реализации абстрактных типов данных.
Цитата из книги Кента Бека «Smalltalk Best Practice Patterns»:
Some of the biggest improvements [of using Beck's patterns] come from figuring out how to eliminate … structural code, where one object treats another as a data structure. … It is much preferable to give an object more responsibility rather than have it act like a data structure.
Давайте не отклоняться от центра дискуссии.
Я по-прежнему не вижу никаких доказательств этой позиции. Вы также не пояснили, что имеете ввиду под «называется ООП везде» и «рамки Smalltalk».
И я, кстати, не понимаю, как к нашей дискуссии относится ваш последний комментарий. Как вообще относятся между собой идеи симуляции сущностей и абстрактные типы данных?
К сожалению то, что называется ООП везде никогда в рамки смолтока не входила. Еще создатели симулы были в удивлении от того что язык все используют не верно и не ловят сути.
Я по-прежнему не вижу никаких доказательств этой позиции. Вы также не пояснили, что имеете ввиду под «называется ООП везде» и «рамки Smalltalk».
И я, кстати, не понимаю, как к нашей дискуссии относится ваш последний комментарий. Как вообще относятся между собой идеи симуляции сущностей и абстрактные типы данных?
Ох, какие доказательства вы от меня хотите? Вы ожидаете что я приведу числа исследования реальных проектов на предмет принадлежности кода к ООП? Я не приведу такие и вообще сомневаюсь что подобные числа хоть где-то есть.
Я пытаюсь указать на то, как задумывалось использовать механизмы ооп и то, как их используют и реализуют.
Вся суть в обязательствах:
Вы не просите в Java строку напечатать себя, вы её используете как хранилище данных. Это не ооп подход.
В большенстве случаев код на современных языках не уходит от C-style handle based программирования, просто для удобства функции привязывают к конктретному типу:
string_split(myString, ...) и myString.split(...) семантически одинаковы и не оопэшны
Я пытаюсь указать на то, как задумывалось использовать механизмы ооп и то, как их используют и реализуют.
Вся суть в обязательствах:
Вы не просите в Java строку напечатать себя, вы её используете как хранилище данных. Это не ооп подход.
В большенстве случаев код на современных языках не уходит от C-style handle based программирования, просто для удобства функции привязывают к конктретному типу:
string_split(myString, ...) и myString.split(...) семантически одинаковы и не оопэшны
Ну вот так бы сразу и сказали :) А то наукообразие какое-то развели :)
Понятно, что то, как мы пишем исходный код на современных языках, оставляет желать много лучшего. Правда, это имеет мало общего вообще с языками как таковыми.
А вариант с myString.split() мне кажется вполне себе ООП. Мы просим строку, чтобы она разделилась. Чего там такого не ООП-шного?
Понятно, что то, как мы пишем исходный код на современных языках, оставляет желать много лучшего. Правда, это имеет мало общего вообще с языками как таковыми.
А вариант с myString.split() мне кажется вполне себе ООП. Мы просим строку, чтобы она разделилась. Чего там такого не ООП-шного?
ооп вообще сосёт, когда у нас есть более одного объекта. есть принтер, есть строка. метод печати строки на принтере должен храниться в принтере или в строке? printer.print( str ) или str.print( printer )?
что-то мне подсказывает, что это одинаково внешняя для обоих объектов функция:
Print str To printer
функция Print-To параметризированная двумя переменными: строкой str и принтером printer
что-то мне подсказывает, что это одинаково внешняя для обоих объектов функция:
Print str To printer
функция Print-To параметризированная двумя переменными: строкой str и принтером printer
Вы не хотите оставить свою невыразимо тупую и грубую манеру общаться?
Кто вам сказал, что на заданный вами вопрос должен обязательно существовать однозначный ответ?
Кто вам сказал, что на заданный вами вопрос должен обязательно существовать однозначный ответ?
Очень резкое заявление.
Однозначно будет нечто вроде Sting.printOn(aPrinter);
принтнер никак не может знать как печатать строку, в этом суть инкапсуляции, строка сама знает как печататься на принтере.
Тут проблема в, на первый взгляд, неинтуитивности подобных решений.
Однозначно будет нечто вроде Sting.printOn(aPrinter);
принтнер никак не может знать как печатать строку, в этом суть инкапсуляции, строка сама знает как печататься на принтере.
Тут проблема в, на первый взгляд, неинтуитивности подобных решений.
Честно говоря я бы по другому сделал… Что-то типа…
aPrint.print(aString, printMethod);
Потому что в данном конкретном случае принтер определяет каким методом печатать, по скольку вероятно таких методов n-число, ограниченное возможностями самого принтера…
aPrint.print(aString, printMethod);
Потому что в данном конкретном случае принтер определяет каким методом печатать, по скольку вероятно таких методов n-число, ограниченное возможностями самого принтера…
Я бы тоже не сделал как я написал выше, потому что это в тупик людей ставит. Но вопрос стоит о том, что OOP а что нет.
А почему метод печати принадлежащий принтеру не является ООП?.. По моему если отойти от абстракции, как раз таки принтер и определяет метод печати…
метод печати у принтера это ооп, но не принтер печатает строку на себе, а строка себя на принтере. Он про строку ничего знать не может, как он из нее символы достанет, к ним не у кого доступа нет. А строка знает публичный интерфейс принтера, и что надо подергает.
Ну, я немного другое имел в виду говоря про метод… Принтер разумеется про строку ничего не знает. Но если методом является — «цветная печать» или скажем «черно-белая», то такой метод безусловно принадлежит принтеру… :)
Просто если опять таки отойти от абстракции… То какие методы печати могут быть у строки?...)
а строка точно также не может знать как печататься на конкретном принтере. у меня есть принтер, который печатает не более 255 символов за раз. как строка узнает, что ей нужно порубиться на части по 255 символов?
Вы о мультиметодах слышали?
Мне кажется, сначала нужно определиться, с какими примитивами умеют работать принтеры. Если это строки, то принтеры должны уметь печатать строки. Если это какие-то еще меньшие или просто другие примитивы, то должен быть класс, отвечающий за трансляцию строк в примитивы понятные принтеру. В любом случае, у принтера должен быть метод вроде
printer.printPrimitives(), которому на вход подается примитив / примитивы, которые все принтеры должны уметь печатать.
printer.printPrimitives(), которому на вход подается примитив / примитивы, которые все принтеры должны уметь печатать.
у каждого принтера свои примитивы.
Может быть, вы перестаните корчить из себя умника? :) Мы что с вами пытаемся проектировать? Windows или простейшую абстрактную систему классов, которая умеет печатать простые строки? Если Windows — так давайте уже тогда со смешных строк, которые умеют печатать слезем, а? Что за глупость-то? А если не Windows — тогда не нужно делать вид, будто все так сложно, так сложно, что только вы один это и понимаете :)
строки — они не простые. существует множество их форматов и кодировок
Ну так это от платформы зависит. В .NET, скажем, очень даже простые. Unicode строки.
msdn.microsoft.com/en-us/library/system.string.aspx
Неплохо троллим, кстати :) Так держать!
msdn.microsoft.com/en-us/library/system.string.aspx
Неплохо троллим, кстати :) Так держать!
+ msdn.microsoft.com/ru-ru/library/system.text.stringbuilder.aspx
+ различные вариации byte[] для которых поленились реализовать объекты и предлагают для обработки перекодировать в string
msdn.microsoft.com/ru-ru/library/system.text.asciiencoding.aspx
msdn.microsoft.com/ru-ru/library/system.text.unicodeencoding.aspx
msdn.microsoft.com/ru-ru/library/system.text.utf32encoding.aspx
msdn.microsoft.com/ru-ru/library/system.text.utf7encoding.aspx
msdn.microsoft.com/ru-ru/library/system.text.utf8encoding.aspx
+ различные вариации byte[] для которых поленились реализовать объекты и предлагают для обработки перекодировать в string
msdn.microsoft.com/ru-ru/library/system.text.asciiencoding.aspx
msdn.microsoft.com/ru-ru/library/system.text.unicodeencoding.aspx
msdn.microsoft.com/ru-ru/library/system.text.utf32encoding.aspx
msdn.microsoft.com/ru-ru/library/system.text.utf7encoding.aspx
msdn.microsoft.com/ru-ru/library/system.text.utf8encoding.aspx
Вот давайте только не «эквивалентить» :) «первые реализации ООП» и Smalltalk. Симула была языком гораздо более статическим, чем он, а появилась первой.
Да, Симула сильно портит историческую картину динамическому ООП :). Но всё равно первые шаги ООП тесно связаны с динамикой.
Кстати, а в Симуле были методы или сообщений?
Кстати, а в Симуле были методы или сообщений?
Если вы имеете типизацию — то статическая, как я понимаю. Иначе зачем методы помечать как виртуальные.
Я конкретно о проверке компилятором наличия метода у объекта. Потому что есть языки со статической типизацией примитивов, но с возможностью делать method_missing и другие динамические штуки в объектах.
Проверка компилятором наличия метода у объекта как-то плохо у меня согласуется с method_missing. Можете пример привести?
Obj-C. Так как у него ООП модель от Smalltalk, то объекты просто принимают сообщение, как строку. Так что если метода с таким же именем нет, то есть отдельный перехватчик.
Вообще-то он динамический по умолчанию, а статическая типизация должна указываться там отдельно с помощью протоколов, насколько я понимаю:
en.wikipedia.org/wiki/Objective-C#Dynamic_typing
en.wikipedia.org/wiki/Objective-C#Dynamic_typing
ява — классово ориентированный язык.
Отличная статья в духе «Хабр — торт» :). Хотя бы вы вынес краткое изложение в виде небольшого списка (может даже в самое начало статьи), для тех кто читает Хабр быстро и ограничен по времени на восприятие большого текста.
Только для того чтоб автор залез таки в гугл (и как следствие написал эту статью) его пришлось изрядно потроллить…
(А пока не пнёшь никто же в гугл не полезет, все будут думать что и без гугла они самые умные, прямо с рождения) =D
(А пока не пнёшь никто же в гугл не полезет, все будут думать что и без гугла они самые умные, прямо с рождения) =D
«В споре рождается истина» :D
А у вас не так? Вы всегда сами по любому поводу лезете в гугл? :) Тогда, наверное, вы очень умный человек, раз все вопросы в мире вы уже задали себе сами до того, как они возникли у ваших собеседников.
Мне и не нужно задавать «все вопросы в мире», но те что у меня возникают (те что так или иначе меня интересуют) я сначала задаю специалистам, или если таковых нет в моём кругу общения то гуглу, и только потом уже делаю для себя выводы (не факт что правильные, но основанные на информации, а не на стереотипах и личных педпочтениях)
Вы уклонились от ответа. Бывает так, что ваш собеседник о чем-то спрашивает или рассуждает, а у вас нет ответа или информации по этому вопросу и вы лезете в гугл или задаете вопрос специалистам?
Бывает так…
1.1 — На форуме кто-то спрашивает, если у меня нет ответа (и вопрос меня не заинтриговал) я не отвечаю.
1.2 — Если вопрос заинтриговал, и я на форуме (т.е у меня есть время залезть в гугл) то я лезу в гугл.
2.1 — Если задают вопрос мне лично, но мне не интересно это обсуждение, я так и говорю «я не знаю этого»
2.2 — Если вопрос мне интересен, и я хочу его обсудить, я говорю прямо «я не знаю правильного ответа, но пологаю что ...»
P.S. — Прошу прощения за задержку с ответом, могу писать только одина раз в час.
1.1 — На форуме кто-то спрашивает, если у меня нет ответа (и вопрос меня не заинтриговал) я не отвечаю.
1.2 — Если вопрос заинтриговал, и я на форуме (т.е у меня есть время залезть в гугл) то я лезу в гугл.
2.1 — Если задают вопрос мне лично, но мне не интересно это обсуждение, я так и говорю «я не знаю этого»
2.2 — Если вопрос мне интересен, и я хочу его обсудить, я говорю прямо «я не знаю правильного ответа, но пологаю что ...»
P.S. — Прошу прощения за задержку с ответом, могу писать только одина раз в час.
И снова вы уклонились от ответа. Больше я вас мучать не стану, раз вам неприятно, но в следующий раз, пожалуйста, думайте, прежде, чем говорить ерунду вроде вот этой:
Не нужно пытаться исказить или опошлить совершенно нормальные вещи. До появления господина tenshi я действительно много не знал об истории ООП. И на мой взгляд, ничего такого, что заслуживало бы вашего язвительного высказывания, в этом нет. Мне стало интересно — я полез в гугл за информацией. Вот и все. Это совершенно нормальный процесс и выставлять его в виде «пинков, которые надо давать всем» просто глупо.
Только для того чтоб автор залез таки в гугл (и как следствие написал эту статью) его пришлось изрядно потроллить…
(А пока не пнёшь никто же в гугл не полезет, все будут думать что и без гугла они самые умные, прямо с рождения) =D
Не нужно пытаться исказить или опошлить совершенно нормальные вещи. До появления господина tenshi я действительно много не знал об истории ООП. И на мой взгляд, ничего такого, что заслуживало бы вашего язвительного высказывания, в этом нет. Мне стало интересно — я полез в гугл за информацией. Вот и все. Это совершенно нормальный процесс и выставлять его в виде «пинков, которые надо давать всем» просто глупо.
>>> действительно много не знал об истории ООП
Вот и я об этом, не знали, но в спор вступили!!!
Респект вам за то что всё-же здравый смысл восторжествовал, и гугл расставил все точки над «i» (но без троллинга со стороны tenshi хабр не досчитался бы отличной статьи класса «Хабр — торт»)
PS — не надо недооценивать важность «троллинга» он бывает полезен
Вот и я об этом, не знали, но в спор вступили!!!
Респект вам за то что всё-же здравый смысл восторжествовал, и гугл расставил все точки над «i» (но без троллинга со стороны tenshi хабр не досчитался бы отличной статьи класса «Хабр — торт»)
PS — не надо недооценивать важность «троллинга» он бывает полезен
Да, вы и сами, я смотрю, троллите будь здоров :) Передергиваете постоянно.
Я вступил в спор, попросив оппонента привести его аргументы и начитавшись гугла. Разве не так нужно делать?
P.S. Не нужно недооценивать полезность мышьяка для здоровья. Иногда он улучшает цвет лица.
Я вступил в спор, попросив оппонента привести его аргументы и начитавшись гугла. Разве не так нужно делать?
P.S. Не нужно недооценивать полезность мышьяка для здоровья. Иногда он улучшает цвет лица.
Я да, тоже тролль… (хобби моё такое)
Но пока вас не вывели из себя, вы не написали эту самую статью (которая выше) и которая весьма хороша… (без таких людей как я, а точнее в данном случае без такого человека как «тенши» не было бы этой статьи)
PS — кстати по поводу «Бьярне Страуструпа» учитывая что он из Дании, я бы назвал его скорее Бярном (без мягкого знака)
Но пока вас не вывели из себя, вы не написали эту самую статью (которая выше) и которая весьма хороша… (без таких людей как я, а точнее в данном случае без такого человека как «тенши» не было бы этой статьи)
PS — кстати по поводу «Бьярне Страуструпа» учитывая что он из Дании, я бы назвал его скорее Бярном (без мягкого знака)
1. Бьярне Строуструп.
2. В Обероне не было классов, там были модули и записи, и это было правильно.
2. В Обероне не было классов, там были модули и записи, и это было правильно.
1. Что за «Бьярне Строуструп»? Он, бедный, не привык к таким страшным кличкам…
2. Это вы так решили, что так правильно?
2. Это вы так решили, что так правильно?
1. «Hello, my name is B[ja]rn[e] Str[ou]str[u]p», не?
2. Необходимый и достаточный минимум, на базе которого можно построить всё.
2. Необходимый и достаточный минимум, на базе которого можно построить всё.
2. «Необходимый и достаточный минимум» и «правильно» — совсем разные понятия. Если руководствоваться вашей логикой, то CISC процессоры — это неправильно.
2.i) Ладно, лично мне подход, который применён в конкретно Обероне, очень нравится, и моё мнение — он правильный. Не распространяю это мнение на Вас и даже не пытаюсь Вас в чём-то [пере]убедить.
2.ii) Конечно, CISC — неправильно, я любитель RISCов, и всё, что у меня по эмбеддерству, построено на RISC-процессорах :)
2.ii) Конечно, CISC — неправильно, я любитель RISCов, и всё, что у меня по эмбеддерству, построено на RISC-процессорах :)
1. Точнее, [ˈbjɑːnə ˈsdʁʌʊ̯ˀsdʁɔb]
Both of my names are pronounced with two syllables: Bjar-ne Strou-strup. Neither the B nor the J in my first name are stressed and the NE is rather weak so maybe Be-ar-neh or By-ar-ne would give an idea. The first U in my second name really should have been a V making the first syllable end far down the throat: Strov-strup. The second U is a bit like the OO in OOP, but still short; maybe Strov-stroop will give an idea.
ООП — это как «коммунизм есть Советская власть плюс электрификация всей страны». Сплели несколько ортогональных вещей одним из многих возможных способов, дали название и обожествили.
И процветает же. И никому не хочется диспетчеризацию по скольким хочешь параметрам, а не только по первому. Не хочется функции раскладывать по логике, а не по тому как они должны диспатчиться (а ведь требуется, есть даже костыль «Visitor» для этого). Не хочется данные прятать от кого нужно, а не от всех подряд.
Через это для меня ООП выглядит если и «научным подходом к программированию», то каким-то очень уж гуманитарным.
И процветает же. И никому не хочется диспетчеризацию по скольким хочешь параметрам, а не только по первому. Не хочется функции раскладывать по логике, а не по тому как они должны диспатчиться (а ведь требуется, есть даже костыль «Visitor» для этого). Не хочется данные прятать от кого нужно, а не от всех подряд.
Через это для меня ООП выглядит если и «научным подходом к программированию», то каким-то очень уж гуманитарным.
ООП, не ООП, какая разница? Удобная технология или язык — используйте ее.
Всегда считал, что холивары на тему трушности и ООП-ности какого из языков создаются теми, кто не занимается разработкой. Остальные же — просто выбирают наиболее им удобный или наиболее подходящий для проекта инструмент.
… и что Гослинг с Липпертом имеют… гм… проблемы
дожились… все-таки C# не Эрик создал :) если уж выделять отдельную личность, то это Андерс.
автобоксинг — это костыль, который создаёт видимость ооп, но на самом деле от него больше проблем, чем пользы. habrahabr.ru/blogs/java/104231/?reply_to=3249930
«геометрию лобачевского» никто не выдаёт за просто «геометрию» именно потому, что просто «геометрия» — это «геометрия евклида». аналогично и с ооп, аланом кеем и ко.
наследование — один из вариантов повторного использования кода. далеко не самый лучший, но с какого-то перепугу возведённый в ранг фундаментального. lj.rossia.org/users/ringill/10156.html
«геометрию лобачевского» никто не выдаёт за просто «геометрию» именно потому, что просто «геометрия» — это «геометрия евклида». аналогично и с ооп, аланом кеем и ко.
наследование — один из вариантов повторного использования кода. далеко не самый лучший, но с какого-то перепугу возведённый в ранг фундаментального. lj.rossia.org/users/ringill/10156.html
В объектно-ориентированном языке Javascript (ибо там есть объекты), однако, нет классов, следовательно, там нет и наследования. То же самое и в языке Self. Так что наследование не является неотъемлемой частью ООП.
«Чистое ООП» очень странный термин. Происхождение его туманно, а смысл затерялся в веках. На мой взгляд говорить о ООП вообще, а тем более о его чистоте в языке вообще бессмысленно. Говорить о ООП имеет смысл в рамках конкретной программы, или мышления конкретного программиста о конкретной проблеме.
На основании того, что я читал о ООП и того что я написал с его (как мне кажется (: ) использованием я могу сделать вывод, что ОО-подход к написанию программ включает в себя всего несколько простых вещей:
— представление программы как набора взаимодействующих «штук», каждая штука знает о нескольких соседях и может им что либо сообщать (просить для неё сделать);
— глубокое замыкание их в себе: восприятие изменений в мире только посредством полученных сообщений при минимуме предположений об устройстве этого мира;
— для каждой задачи (и подзадачи) решаемой программой тщательный выбор ответственного за неё объекта, предпочтение маленьких задач и зон ответственности большим.
Кто-то жалуется, что в Java ООП поддерживается недостаточно глубоко, но посмотрите на C! А ведь на нём написана отличная и любимая широкими массами ОО-библиотека GTK. Можно попробовать подумать о том минимальном наборе фич языка при котором каждая из приведённых выше характеристик поддерживается одной конструкцией языка. Это уже выглядит более похожим на науку и менее на философию. Получается три конструкции: создание объекта, присоединение к нему обработчика сообщения и отправка сообщения. Наименее выходят за рамки этого набора пожалуй Javascript и Smalltalk. О том насколько они чисты судить не берусь.
Кстати о классах и попутно типизации в ОО-языках. Как отмечено в тексте статьи, объекты имеют двух предков: типизированные записи из статьи Хоара, на которые ориентировались авторы Simula и лисповые замыкания, о которых всё время думали авторы Smalltalk. Их гены явно борются в современных языках, усиление одного ведёт к потери преимуществ другого, и кажется совсем недавно авторы языков начали учиться их дружить. Очень интересно наблюдать как две противоположные концепции (статическая типизация против динамической, протоколы против свободы способа вызова, предопределённые способы создания против использования любого лямбда-выражения, ограниченный набор доступных данных против динамического захвата пространства имён родителя) несмотря на неразрешённые противоречия породили доминирующую на рынке технику программирования.
На основании того, что я читал о ООП и того что я написал с его (как мне кажется (: ) использованием я могу сделать вывод, что ОО-подход к написанию программ включает в себя всего несколько простых вещей:
— представление программы как набора взаимодействующих «штук», каждая штука знает о нескольких соседях и может им что либо сообщать (просить для неё сделать);
— глубокое замыкание их в себе: восприятие изменений в мире только посредством полученных сообщений при минимуме предположений об устройстве этого мира;
— для каждой задачи (и подзадачи) решаемой программой тщательный выбор ответственного за неё объекта, предпочтение маленьких задач и зон ответственности большим.
Кто-то жалуется, что в Java ООП поддерживается недостаточно глубоко, но посмотрите на C! А ведь на нём написана отличная и любимая широкими массами ОО-библиотека GTK. Можно попробовать подумать о том минимальном наборе фич языка при котором каждая из приведённых выше характеристик поддерживается одной конструкцией языка. Это уже выглядит более похожим на науку и менее на философию. Получается три конструкции: создание объекта, присоединение к нему обработчика сообщения и отправка сообщения. Наименее выходят за рамки этого набора пожалуй Javascript и Smalltalk. О том насколько они чисты судить не берусь.
Кстати о классах и попутно типизации в ОО-языках. Как отмечено в тексте статьи, объекты имеют двух предков: типизированные записи из статьи Хоара, на которые ориентировались авторы Simula и лисповые замыкания, о которых всё время думали авторы Smalltalk. Их гены явно борются в современных языках, усиление одного ведёт к потери преимуществ другого, и кажется совсем недавно авторы языков начали учиться их дружить. Очень интересно наблюдать как две противоположные концепции (статическая типизация против динамической, протоколы против свободы способа вызова, предопределённые способы создания против использования любого лямбда-выражения, ограниченный набор доступных данных против динамического захвата пространства имён родителя) несмотря на неразрешённые противоречия породили доминирующую на рынке технику программирования.
А, по-моему, про ООП лучше всего, из того, что я читал (а читал я не так уж и мало) написано здесь: clojure.org/state Краткое содержание: ООП оно совсем не про методы, посылку сообщений, наследование и полиморфизм, а про попытку отделить динамические инварианты от концепции переменной. Лично я согласенс Хики, что попытка не особо удачная, и в итоге, закончившаяся С++ и Java, которые совсем не в тему, просто продвинутое модульное программирование, не более, IMHO.
Да. И ещё. ООП слишком раздуто. При чём искусственно, все говорят, что ООП круто, формально подтверждая это магическими словами: инкапсуляция и наследование, но никто так и не доказал, что инкапсуляция и наследование — это круто. А, ведь, кроме ООП есть ещё до кучи подходов к разработке систем, но современные программисты их агрессивно не хотят замечать.
А почему не хотят?
инкапсуляция и наследование, но никто так и не доказал, что инкапсуляция и наследование — это круто
Вы большие проекты когда-нибудь писали?..
Работа над Linux считается?
Смотря что вы там делали )
Ну… Что и все, баги правил, чинил какой-то косяк с infiniband. Ничего особо грандиозного. Ну… А вообще, что считается большим? Кстати, вот пример. Баги в Linux эти конкретные, были намного серьёзнее, чем один мелкий баг в большом пакете вычислительных программ, написанных на Си++ и мы просто убились эти баги выискивать, потому что они протаскивались через три или четыре уровня наследования. Это был один из самых неприятных experience в жизни.
А вообще, я, обычно, предпочитаю UNIX way в работе, и у меня нет процессов в приложении, чей код длиннее пары десятков тысяч строк. Хотя, я иногда кое-что пописываю для довольно больших OSS-игровых движков, в id3 около миллиона строк кода, но там тоже все обходятся Си. Общая rationale — мы ж не случайно к полям структур обращаемся, нафига нам защищаться от самих себя? :)
Как с этим дела обстоят в корпорациях, которые генерируют по 500 мегабайт нового кода ежегодно, я не знаю. Может быть, им действительно ООП нужно, чтобы защищаться от своих же программистов.
А вообще, я, обычно, предпочитаю UNIX way в работе, и у меня нет процессов в приложении, чей код длиннее пары десятков тысяч строк. Хотя, я иногда кое-что пописываю для довольно больших OSS-игровых движков, в id3 около миллиона строк кода, но там тоже все обходятся Си. Общая rationale — мы ж не случайно к полям структур обращаемся, нафига нам защищаться от самих себя? :)
Как с этим дела обстоят в корпорациях, которые генерируют по 500 мегабайт нового кода ежегодно, я не знаю. Может быть, им действительно ООП нужно, чтобы защищаться от своих же программистов.
По моему высокий уровень абстракции уменьшает время адаптации нового программиста. Не знаю какие у вас были проблемы с багами из-за большого кол-ва уровней наследования… В крайнем случае можно пользоваться дебагером…
Бывают конечно проблемы с этим, иногда очень много времени уходит пока все концы найдешь, но как-то мне кажется пользы все равно больше.
А вот что вы против инкапсуляции имеете, я вообще не понимаю.
Бывают конечно проблемы с этим, иногда очень много времени уходит пока все концы найдешь, но как-то мне кажется пользы все равно больше.
А вот что вы против инкапсуляции имеете, я вообще не понимаю.
Ага. Попробуйте использовать отладчик на кластере с полуторатысячами процессоров. Я не против инкапсуляции, вопрос только в том, так ли она полезна? И нужно ли тратить силы на решение того, что в каждом конкретном объекте делать private, а что public. Делать просто, как всегда говорят, данные закрытыми — не удобно. Иногда это превращается в полукилометровые вызовы get, кучи конструкторов копирования и прочие штуки. В программах со сложной структурой это быстро надоедает. В итоге, IMHO, нечто сложное по структуре гораздо более удобно писать на Си.
Иногда это превращается в полукилометровые вызовы get, кучи конструкторов копирования и прочие штуки.
Я бы не смешивал парадигму программирования и умение отдельно взятого программиста писать понятный код. Я вам и без ООП лапши наверну столько, что разбираться будете год.
Не уверен. Ибо я видел кучу 'правильного' С++ кода (лично я на нём не пишу), который просто даже воспринимать сложно, из-за такого доступа к данным. И видел несколько 'неправильных' проектов (в основном движки игровые, где люди гоняются за производительностью), которые читаются легко и приятно, потому что нет там такой фанатичной гиперинкапсуляции. Так что… ПОнятно, что написать можно по-разному, но Си++ толкает на плохой стиль. В Си нет никаких private и public, и никто не заморачивается, просто всё со временем постепенно гармонизируется, для сложных и согласованных оценок состояний объекта, мы пишем функцию, для доступа к простым счётчикам или флагам, пользуемся просто доступом к структуре, и т.д. и т.п. Си++ же склоняет к необходимости разделить всё на private/public/protected, и люди начинают этим заморачиваются, и стараются предугадать (в большинстве случаев некорректно), что же надо скрыть, что открыть. Это всё в итоге приводит к нечитаемому коду, потому что менять уже нечто поздно, ибо понаписано N килострок с текущими абстракциями, вот и начинаются wrapper'ы, proxy, шаблоны и прочая маловнятная ерунда, только ради того, чтобы прочитать какой-нибудь простой флажок.
Каковы ваши критерии оценки «правильного» кода? Я так понимаю, у вас императивный взгляд на программирование, несовместимый с ООП подходом. Как же вы можете оценивать правильность подхода, в котором не разбираетесь и к которому вы предвзято относитесь?
Ну, в общем-то ООП старается моделировать мир. По-своему конечно. Главное в программировании — управление сложностью. private/protected сложность скрывают, позволяя в каждый момент времени держать в голове только ограниченное количество кода.
Вообще-то, если вам приходится угадывать, что нужно открыть, а что закрыть, скорее всего, вы плохо представляете себе предметную область, которую моделируете.
Классический пример кода, написанного программистом, который понятия не имеет о рефакторинге. Только к ООП это отношения не имеет. Все, что вы приводите в пример, может быть аналогично повторено неграмотным программистом на чистом С.
Cи++ же склоняет к необходимости разделить всё на private/public/protected,
Ну, в общем-то ООП старается моделировать мир. По-своему конечно. Главное в программировании — управление сложностью. private/protected сложность скрывают, позволяя в каждый момент времени держать в голове только ограниченное количество кода.
и стараются предугадать (в большинстве случаев некорректно), что же надо скрыть, что открыть.
Вообще-то, если вам приходится угадывать, что нужно открыть, а что закрыть, скорее всего, вы плохо представляете себе предметную область, которую моделируете.
Это всё в итоге приводит к нечитаемому коду, потому что менять уже нечто поздно, ибо понаписано N килострок с текущими абстракциями, вот и начинаются wrapper'ы, proxy, шаблоны и прочая маловнятная ерунда, только ради того, чтобы прочитать какой-нибудь простой флажок.
Классический пример кода, написанного программистом, который понятия не имеет о рефакторинге. Только к ООП это отношения не имеет. Все, что вы приводите в пример, может быть аналогично повторено неграмотным программистом на чистом С.
У меня нет никаких критериев. Просто по коду всегда видно, какой набор правил пытаются соблюдать люди. Есть просто классический набор рекомендаций на тему 'как правильно писать на Си++'. Так вот, эта правильность и бросается сразу же в глаза.
В подходах я разбираюсь очень хорошо, не нужно отождествлять моё стремление к простоте с невежеством :) Но если уж вы отождествляете, вот вам ответный булыжник в огород: противопоставлять императивное программирование и ООП это примерно то же самое, что противопоставлять мокрое и длинное :) Учите матчасть, всё такое.
О. Вы что, в самом деле думаете, что Линус держит весь код Linux в голове, потому что у него нет private и public? :) Я завидую вашей наивности, нет, честно. Когда-то, в молодости, я тоже был таким идеалистом-формалистом, и был счастлив. К счастью, реальный мир намного сложнее, и попытки моделировать его при помощи ООП — это как минимум от незнания современной физики, и вообще полный fail.
ООП не мир моделирует. ООП, пытается моделировать процесс мышления склонных к гиперформализации западных программистов. Они абсолютно уверены, что ООП — это абсолютная истина, потому что, IMHO, такой стиль мышления действительно соответствует их восприятию мира. Но такое восприятие, как минимум, не особо соответствует действительности. И всё-равно приводит к генерации километров невнятного кода.
Вот в этом-то и главный философский диссонанс. Проблема не в том, что кто-то что-то плохо себе представляет, проблема в квантовой механике: если вы вмешиваетесь своими программами в предметную область, то предметная область меняется. А кроме нас с нашими программами в предметную область вмешиваются до кучи других людей. Нужно быть гибким, чтобы соответствовать этим изменениям. ООП же своим упором на инкапсуляцию и абстракцию интерфейсов не даёт достаточно гибкости для реального мира.
Хм. То есть, вы сейчас говорите, для программирования на Си++ человеку надо заморачиваться не только насчёт public/private, но ещё и думать о том, как он потом это всё рефакторить будет? :) И это, типа, лучше, чем просто решать поставленную задачу? И это декларируется как преимущество подхода? Мне это кажется несколько иррациональным.
Конечно, и на Си можно написать подобную кашу. Но вероятность того, что кто-нибудь именно её напишет мала. Потому что Си не ограничивает, и там очень часто доступы к данным выходят, даже у начинающих программистов, по крайней мере, не запутанными. Они могут быть не оптимальными, могут быть наивными, но редко бывают малопонятными и запутанными для стороннего созерцателя, который вполне может всё поправить.
В Си просто гораздо больше design-time динамике, потому он, как мне кажется и хорош. ООП эту всю динамику убивает, и не понятно, с какой целью. IMHO на этот счёт: с целью защиты от собственных же программистов. Бальзам на душу для мэнеджеров, но превращает процесс программирования в полный не-fun.
В подходах я разбираюсь очень хорошо, не нужно отождествлять моё стремление к простоте с невежеством :) Но если уж вы отождествляете, вот вам ответный булыжник в огород: противопоставлять императивное программирование и ООП это примерно то же самое, что противопоставлять мокрое и длинное :) Учите матчасть, всё такое.
Ну, в общем-то ООП старается моделировать мир. По-своему конечно. Главное в программировании — управление сложностью. private/protected сложность скрывают, позволяя в каждый момент времени держать в голове только ограниченное количество кода.
О. Вы что, в самом деле думаете, что Линус держит весь код Linux в голове, потому что у него нет private и public? :) Я завидую вашей наивности, нет, честно. Когда-то, в молодости, я тоже был таким идеалистом-формалистом, и был счастлив. К счастью, реальный мир намного сложнее, и попытки моделировать его при помощи ООП — это как минимум от незнания современной физики, и вообще полный fail.
ООП не мир моделирует. ООП, пытается моделировать процесс мышления склонных к гиперформализации западных программистов. Они абсолютно уверены, что ООП — это абсолютная истина, потому что, IMHO, такой стиль мышления действительно соответствует их восприятию мира. Но такое восприятие, как минимум, не особо соответствует действительности. И всё-равно приводит к генерации километров невнятного кода.
Вообще-то, если вам приходится угадывать, что нужно открыть, а что закрыть, скорее всего, вы плохо представляете себе предметную область, которую моделируете
Вот в этом-то и главный философский диссонанс. Проблема не в том, что кто-то что-то плохо себе представляет, проблема в квантовой механике: если вы вмешиваетесь своими программами в предметную область, то предметная область меняется. А кроме нас с нашими программами в предметную область вмешиваются до кучи других людей. Нужно быть гибким, чтобы соответствовать этим изменениям. ООП же своим упором на инкапсуляцию и абстракцию интерфейсов не даёт достаточно гибкости для реального мира.
Классический пример кода, написанного программистом, который понятия не имеет о рефакторинге. Только к ООП это отношения не имеет. Все, что вы приводите в пример, может быть аналогично повторено неграмотным программистом на чистом С.
Хм. То есть, вы сейчас говорите, для программирования на Си++ человеку надо заморачиваться не только насчёт public/private, но ещё и думать о том, как он потом это всё рефакторить будет? :) И это, типа, лучше, чем просто решать поставленную задачу? И это декларируется как преимущество подхода? Мне это кажется несколько иррациональным.
Конечно, и на Си можно написать подобную кашу. Но вероятность того, что кто-нибудь именно её напишет мала. Потому что Си не ограничивает, и там очень часто доступы к данным выходят, даже у начинающих программистов, по крайней мере, не запутанными. Они могут быть не оптимальными, могут быть наивными, но редко бывают малопонятными и запутанными для стороннего созерцателя, который вполне может всё поправить.
В Си просто гораздо больше design-time динамике, потому он, как мне кажется и хорош. ООП эту всю динамику убивает, и не понятно, с какой целью. IMHO на этот счёт: с целью защиты от собственных же программистов. Бальзам на душу для мэнеджеров, но превращает процесс программирования в полный не-fun.
У меня нет никаких критериев.
Если у вас нет критериев оценки правильного кода, тогда зачем в посте выше вы судите о том, что вы видели «правильный код» на C++?
Есть просто классический набор рекомендаций на тему 'как правильно писать на Си++'. Так вот, эта правильность и бросается сразу же в глаза.
У кого он есть? Чьи это рекомендации и в чем заключаются? Вы считаете, что их достаточно, чтобы отличать правильный код от неправильного? Почему?
противопоставлять императивное программирование и ООП это примерно то же самое, что противопоставлять мокрое и длинное :) Учите матчасть, всё такое.
Это вы расскажете авторам языка Closure: clojure.org/state. Наверное, они вместе со мной плохо учили матчасть.
О. Вы что, в самом деле думаете, что Линус держит весь код Linux в голове, потому что у него нет private и public? :)
Вы напрасно передергиваете и цепляетесь к словам. И в С и в С++ есть другие способы сокрытия сложности.
К счастью, реальный мир намного сложнее, и попытки моделировать его при помощи ООП — это как минимум от незнания современной физики, и вообще полный fail.
Вы прекрасно поняли, что я имею ввиду. Так или иначе, программируя на чем угодно, мы моделируем окружающий мир, предметную область. Разумеется, любое такое моделирование — моделирование неполное, как и моделирование на компьютере любого физического процесса. Не уводите разговор в сторону, пожалуйста.
ООП не мир моделирует.
Откуда вы знаете? Я моделирую небольшую часть этого мира сейчас с помощью ООП, разрабатывая фреймворк.
ООП, пытается моделировать процесс мышления склонных к гиперформализации западных программистов.
ООП — объект неодушевленный и не может само что-то моделировать. Оно — неживое.
Они абсолютно уверены, что ООП — это абсолютная истина, потому что, IMHO, такой стиль мышления действительно соответствует их восприятию мира. Но такое восприятие, как минимум, не особо соответствует действительности. И всё-равно приводит к генерации километров невнятного кода.
Мне очень нравится, что вы сейчас ответили за всех западных программистов. Кажется, по степени информированности вы не уступаете Создателю, не так ли?
Вот в этом-то и главный философский диссонанс. Проблема не в том, что кто-то что-то плохо себе представляет, проблема в квантовой механике: если вы вмешиваетесь своими программами в предметную область, то предметная область меняется.
То есть, если гидрометеоцентр моделирует погоду, то она меняется из-за этого? А если они моделируют ее не на ООП — то, видимо, не меняется? Они ведь ее на компьютерах моделируют. Не смешите меня. Или вы думаете, что я о принципе неопределенности Гейзенберга никогда не слышал?
ООП же своим упором на инкапсуляцию и абстракцию интерфейсов не даёт достаточно гибкости для реального мира.
Да, в общем, никто и не утверждает, что ООП — царь мира. Однако, как вы определяете «достаточность гибкости» в данном смысле? И на чем вы основываете такой вывод?
Хм. То есть, вы сейчас говорите, для программирования на Си++ человеку надо заморачиваться не только насчёт public/private, но ещё и думать о том, как он потом это всё рефакторить будет?
Вы знаете, что такое «рефакторинг»? Это процесс улучшения качества существующего кода. Вы считаете, что об этом не надо думать? public/private не требуют, чтобы на их счет «заморачивались». Обычно, их расстановка вытекает из предметной области.
Конечно, и на Си можно написать подобную кашу. Но вероятность того, что кто-нибудь именно её напишет мала.Вы можете как-то подкрепить свой вывод? Выглядит довольно голословно. У вас есть исследования, подтверждающие ваш вывод относительно такой вероятности? Или она просто обязана быть очевидна всем, а если не очевидна — то только слепым и бездарным? :)
ООП эту всю динамику убивает, и не понятно, с какой целью.
Что вы подразумеваете под динамикой? Проиллюстрируйте, пожалуйста, как ООП ее убивает.
IMHO на этот счёт: с целью защиты от собственных же программистов.
Не говорите об ООП как о живом предмете, пожалуйста. Вы меня беспокоите.
(1) Разве Том Хики пишет о том, что императивный стиль противопоставляется ООП парадигме? Он пишет о том, что решать те задачи, которые ставились перед ООП попытками введения ООП в императивные языки — это fail, это не верно.
Хотя, конечно, если вы считаете, что C++ и Java — это не ООП, вы в праве говорить о противопоставлении. Но что-то мне сдаётся (раз речь заходит о больших корпоративных проектах), под ООП вы понимаете не только Haskell и Clojure.
А раз так, то учите матчасть. Любой язык, где в основе лежит последовательное изменение состояний переменных является императивным. И даже в Smalltalk переменные были и менялись. Там было многократное присваивание и последовательное действие. Так что, либо вы сами себе в угаре спора противоречите, либо всё человечество ошибается на тему того, что считать императивным, а что — нет.
(2) От моделирования погоды она, естественно, очень сильно меняется. Например, у нас не падают и не взрываются ракеты, которые мы без моделирования не запускаем в ураганы. Мыслите масштабнее. Вы не можете всё в мире разбить на изолированные сущности. Именно вера в это является основным косяком ООП. Да. И принцип Гейзенберга он совсем не в тему, говоря о квантовой механике я говорил не об неопределённости (что является следствием), а о том, что измерение влияет на систему. Моделирование же — это часть процесса измерения.
(3) ООП убивает динамику очень просто: вы формализуете интерфейс, проходит N недель разработки, потом выясняется, что всё не так, как вы предполагали (а такое сплошь и рядом, люди меняются, техника меняется, конфигурация оборудования, удобство пользователя). Но у вас уже понаписаны тысячи строк с этим интерфейсом. И менять код, который основан именно на этой абстрактной модели на порядки сложнее: меняя интерфейс, вы меняете протокол, вам приходится менять вообще почти всё. ad-hoc, локальные изменения, вспомогательные функции практически невозможны. И это снижает ту скорость, с которой можно было бы разрабатывать код.
Не. ПОнятно, что в проектах, которым лет по 20, все интерфейсы уже подогнаны к действительности, и там достаточно просто добавлять и менять функциональность, потому что уже известно, в каком русле течёт Дао (ну, не подобрал лучшего слова) этого проекта.
Но в новых проектах. ООП просто нафиг всё убивает. Дольше думаешь о том, как сделать этот код правильно, а не о том, как заставить правильно работать систему. В итоге люди просто начинают лепить всякую ахинею: с одной стороны у них код содержит всякие головоломные ООП-шные конструкции, с другой, он написан поперёк ООП-стиля, потому что этот ООП совсем не в тему, когда задача новая и предметная область неизведана (а фиг её исследуешь чисто умозрительно и при помощи UML-диаграмм).
(4) Больше мне сказать нечего. Как бы, я уже повторяюсь. Вы меня не переубедите, потому что, видимо, у нас совсем разный опыт программирования. Вам хорошо ООП, мне — крайне плохо. Но принцип: каждому своё — никто не отменял.
Просто я выражаю свою точку зрения для тех, кто выбирает сейчас для своих проектов стиль работы и инструменты, и они должны знать, что ООП — это не серебрянная пуля. Там есть свои сложности, вызванные именно его жёсткостью, которая всё черезмерно может усложнить. Плюс при разработке нужно учитывать кроме, собственно, особенностей процесса вычисления ещё и особенности сложной внутренней жизни классов и объектов. И это отнимает и мозги, и время.
Буду рад, если кто-то это услышит и осознает. И хотя бы постарается посмотреть в сторону от индустриальных монстров вроде C++/Java/C#.
Хотя, конечно, если вы считаете, что C++ и Java — это не ООП, вы в праве говорить о противопоставлении. Но что-то мне сдаётся (раз речь заходит о больших корпоративных проектах), под ООП вы понимаете не только Haskell и Clojure.
А раз так, то учите матчасть. Любой язык, где в основе лежит последовательное изменение состояний переменных является императивным. И даже в Smalltalk переменные были и менялись. Там было многократное присваивание и последовательное действие. Так что, либо вы сами себе в угаре спора противоречите, либо всё человечество ошибается на тему того, что считать императивным, а что — нет.
(2) От моделирования погоды она, естественно, очень сильно меняется. Например, у нас не падают и не взрываются ракеты, которые мы без моделирования не запускаем в ураганы. Мыслите масштабнее. Вы не можете всё в мире разбить на изолированные сущности. Именно вера в это является основным косяком ООП. Да. И принцип Гейзенберга он совсем не в тему, говоря о квантовой механике я говорил не об неопределённости (что является следствием), а о том, что измерение влияет на систему. Моделирование же — это часть процесса измерения.
(3) ООП убивает динамику очень просто: вы формализуете интерфейс, проходит N недель разработки, потом выясняется, что всё не так, как вы предполагали (а такое сплошь и рядом, люди меняются, техника меняется, конфигурация оборудования, удобство пользователя). Но у вас уже понаписаны тысячи строк с этим интерфейсом. И менять код, который основан именно на этой абстрактной модели на порядки сложнее: меняя интерфейс, вы меняете протокол, вам приходится менять вообще почти всё. ad-hoc, локальные изменения, вспомогательные функции практически невозможны. И это снижает ту скорость, с которой можно было бы разрабатывать код.
Не. ПОнятно, что в проектах, которым лет по 20, все интерфейсы уже подогнаны к действительности, и там достаточно просто добавлять и менять функциональность, потому что уже известно, в каком русле течёт Дао (ну, не подобрал лучшего слова) этого проекта.
Но в новых проектах. ООП просто нафиг всё убивает. Дольше думаешь о том, как сделать этот код правильно, а не о том, как заставить правильно работать систему. В итоге люди просто начинают лепить всякую ахинею: с одной стороны у них код содержит всякие головоломные ООП-шные конструкции, с другой, он написан поперёк ООП-стиля, потому что этот ООП совсем не в тему, когда задача новая и предметная область неизведана (а фиг её исследуешь чисто умозрительно и при помощи UML-диаграмм).
(4) Больше мне сказать нечего. Как бы, я уже повторяюсь. Вы меня не переубедите, потому что, видимо, у нас совсем разный опыт программирования. Вам хорошо ООП, мне — крайне плохо. Но принцип: каждому своё — никто не отменял.
Просто я выражаю свою точку зрения для тех, кто выбирает сейчас для своих проектов стиль работы и инструменты, и они должны знать, что ООП — это не серебрянная пуля. Там есть свои сложности, вызванные именно его жёсткостью, которая всё черезмерно может усложнить. Плюс при разработке нужно учитывать кроме, собственно, особенностей процесса вычисления ещё и особенности сложной внутренней жизни классов и объектов. И это отнимает и мозги, и время.
Буду рад, если кто-то это услышит и осознает. И хотя бы постарается посмотреть в сторону от индустриальных монстров вроде C++/Java/C#.
Разве Том Хики пишет о том, что императивный стиль противопоставляется ООП парадигме? Он пишет о том, что решать те задачи, которые ставились перед ООП попытками введения ООП в императивные языки — это fail, это не верно.
Он сравнивает подходы. И перевирать его слова не надо. Он пишет «typical OO has imperative programming baked into it! OO doesn't have to be this way, but, usually, it is (Java/C++/Python/Ruby etc).» — «типичное объектно-ориентированное программирование имеет в себе императивное. Для ООП это не является необходимостью, но тем не менее, такова ситуация во многих языках программирования.»
Хотя, конечно, если вы считаете, что C++ и Java — это не ООП
Странно, что вы так подумали :) Я так далеко не считаю.
От моделирования погоды она, естественно, очень сильно меняется. Например, у нас не падают и не взрываются ракеты, которые мы без моделирования не запускаем в ураганы. измерение влияет на систему. Моделирование же — это часть процесса измерения.
Если у вас закончились аргументы, в споре лучше вообще проигнорировать оппонента, чем выдавать подобную чушь по поводу погоды :) Принцип неопределенности, который вы хотели выдать за свой аргумент, прежде всего говорит о том, что само присутствие в системе наблюдателя меняет состояние системы. То есть, от того, что я присутствую в данном месте в данное время температура за счет моего присутствия может немного измениться, потому что мое тело излучает тепло. Поэтому завтра, когда вы выйдете из дома вы скажете себе: «Не буду слушать прогноз погоды. Она ведь меняется каждый раз, когда FractalizeR входит на Хабр и фиг его знает, 12 градусов сегодня будет в городе или 40». Мы не можем моделировать или даже просто изучать этот мир со 100% детальностью. Однако нам людям вполне достаточно определенной точности. Ни одна программа не может смоделировать окружающий мир на 100% точно даже на вашем любимом С. Однако это не значит, что нам вообще не нужно предсказывать погоду, наводнения или еще что. Это не значит, что мы не можем смоделировать предметную область с приемлемой точностью.
Но у вас уже понаписаны тысячи строк с этим интерфейсом. И менять код, который основан именно на этой абстрактной модели на порядки сложнее
То есть, интерфейса вообще никакого не должно быть? И абстрактной модели тоже? Боб Мартин с вами не согласен. Да и Линус Торвальдс тоже. Посмотрите на интерфейс Ядра линукса. Что, его нет?
Но в новых проектах. ООП просто нафиг всё убивает.… потому что этот ООП совсем не в тему, когда задача новая и предметная область неизведана
Вы еще долго будете в меня швыряться голословными утверждениями? :) От того, что вы едите морковь, ваш нос зеленеет. А прогулки на свежем воздухе мешают спать людям на другом конце Земли. Как вам такие утверждения? :)
они должны знать, что ООП — это не серебрянная пуля. Там есть свои сложности
Я рад, что вы в чем-то признали абсурдность ваших хаяний ООП и переместились к более мягкой позиции. Вот в этом я с вами согласен. Вы так долго со мной спорили ни о чем, что уже забыли с чего все начиналось. Я не апологет ООП, не слепой догматик, каким, вероятно, являетесь вы, который выбрал себе один подход и слепо сидит на нем, заявляя всему миру, что то, чем он пользуется — это круто, а все остальное — это гавно, не стоящее внимания. Мне нравится изучать все подходы. И чисто императивный, и ОО и функциональный подходы — они все имеют свои преимущества и недостатки. Я собираюсь изучать и пользоваться всеми. А вы можете дальше сидеть на каком-то одном и кричать, что все остальное не стоит вашего драгоценного внимания. За время нашего спора вы не привели ни одного аргумента о том, что в ООП есть что-то плохое. А такие аргументы, наверняка, есть.
Буду рад, если кто-то это услышит и осознает. И хотя бы постарается посмотреть в сторону от индустриальных монстров вроде C++/Java/C#.
Я тоже был бы этому рад. Я, скажем, в текущий момент смотрю в сторону Haskel. И мне просто ЖУТКО ИНТЕРЕСНО. А вы можете сидеть на вашем любимом С и дальше (кстати, между нами — отличный язык!), не оглядываясь по сторонам. Всего хорошего :)
Извините, но вы уже гоните. И я сейчас не сдержусь, и начну хаять Вас.
(1) Перечитайте свой перевод (отвратительный, кстати) высказывания Хики, и укажите, какая именно фраза в нём противопоставляет ООП и императивную парадигму (а именно об этом часть наших разногласий).
(2) При чём тут моделирование вообще? Я говорил о динамичности окружающего мира и о том, что к изменениям надо подстраиваться. И что ООП не даёт быстро к ним подстраиваться.
Моё высказывание насчёт квантовой механики было о том, что самым важным постулатом в КМ является то, что наблюдение отчасти определяет систему. Не существует систем, не зависящих от наблюдателя. Это прямо явно в математической модели прописано, в том месте, где они отказываются от наблюдаемых, привычных для классической механики.
Это вообще не вопрос точности и влияния на систему наблюдателя. Это говорит о том, что наблюдение — это часть самой системы. А наблюдение — это выделение инвариантов. И когда вы пишете программу, вы такие инварианты в системе выделяете. Но когда система начинает пользоваться вашей программой, то она сама меняется уже, меняются инварианты.
Точность моделирования тут совершенно ни при чём. Важен сам факт моделирования. Да, конечно, если вы наблюдаете чего-нибудь вроде сверхмассивной чёрной дыры, то вы вряд ли многое измените своим наблюдением, система крайне симметрична и пофигична. Но вот прогноз погоды определённо влияет на саму погоду. Ещё раз, вдумайтесь: допустим, мы не прогнозируем погоду, и начинаем запускать наши космические ракеты, руководствуясь лишь показаниями термометров, мы их запускаем в ураганы и штормы, они ломаются, сбиваются с курсов, взрываются. А объекты эти высокоэнергетические, они вполне способны вызвать изменения в течении ветров. Может быть, не глобальные, небольшие, но могут. Следовательно, наши прогнозы погоды влияют на погоду. И это очевидно. Я уж не говорю о таких прозаических вещах, как разгон облаков где-нибудь или принудительный сброс лавин. Всё же делается на основании прогнозов.
Если вы не можете выстроить в голове у себя такую простую логическую цепочку, какой нафиг вы программист?
(3) Хотя, как кажется, вы из КМ знаете только о принципе Гейзенберга, поэтому все эти ассоциации для вас пустые. Хорошо, менее возвышенный пример. Вы пишите программу визуализации для математика. Он что-то насчитал по своей математической модели. Он уверен (на 100%), что показать вы ему должны именно такие параметры. Вы пишете программу, вы выделяете классы, вы инкапсулируете данные правильно и корректно, в полном согласии с тем, что вам сказал математик. Вы строите 3D-объекты, которые отражают модель.
Вы ему показываете это всё, и он мгновенно понимает, что ошибался. И нужно смотреть на другие параметры, потому что в итоге, то, что он просил показать, просто сфера. Потому что всё симметрично. Ему это полезно, конечно. Он теорему докажет. Но вам придётся переписывать программу, чтобы построить другие сечения, чтобы использовать другие данные, чтобы крутить в 3D другие объекты. И вот тут вы убьётесь от рефакторинга и переписывания своих навороченных интерфейсов.
Если вы программируете в какой-нибудь особо устоявшейся области, таких проблем не возникает. Паттерны известны, интерфейсы тоже. Все знают, например, что такое параграф при вёрстке текста. Есть 20 стандартов и 100 рекомендаций по проектированию. Но если область непонятная, динамичная, то вы ничего не знаете, и уже пытаетесь всё инкапсулировать. Это лишь тратит силы и приводит к каше в коде, когда придётся всё менять и подстраивать под изменившуюся реальность.
И именно поэтому я говорю, что в ООП меньше динамизма, ООП мешает писать программы, в развитии которых нужна гибкость.
(5) Я умею (реальные проекты) программировать на Си, Haskell, Clojure, Bash, Go (отличная, кстати, демонстрация того, что обычный ООП — отстой, что в нём не хватает динамики, Goшный подход с интерфейсами, которые можно лепить для всего, без всяких теорий и правил, прямо на месте гораздо продуктивнее), Си++, Lua, на куче ассемблеров, Javascript, PHP, Python. Если это называется сидеть на одном и кричать, что только это круто, то что называется не сидеть на одном? :) Это как вы? Не знать левым полушарием о том, какой бред рождается в правом? Ну так, чтобы жизнь скучной не казалась?
И моя критика ООП основана не на пустом месте, а на опыте. Я пытаюсь его как-то выразить словами, а вы почему-то какие-то галлюцинации при этом видите. Где я, например, сообщил, что Си является единственным и неповторимым? Где я сообщил, что не нужно ничего другого изучать? Не приписывайте свой фантазии мне.
(6) Аргументы закончились у вас, ибо вы переходите на личности: мол я не знаю того, не знаю сего, говорю чушь, не имею аргументов и т.д. и т.п. Вы ни разу не возразили по существу. Кроме невнятных попыток написать что-то про точность моделирования, что вообще иррелевантно.
(7) Не надо вам Haskell. У вас навыков восприятия печатных текстов не хватит. И с вашей фанатичностью (хоть вы и утверждаете обратное, но на самом деле, вы — типичный фанатик, судя по эмоциональному накалу ваших постов) и не готовностью вдумываться в чужое мнение, просто впустую потратите время. Haskell не так прост. Да. И ещё спасёте Haskell сообщество от себя-любимого. Там фанатиков и без того хватает.
(1) Перечитайте свой перевод (отвратительный, кстати) высказывания Хики, и укажите, какая именно фраза в нём противопоставляет ООП и императивную парадигму (а именно об этом часть наших разногласий).
(2) При чём тут моделирование вообще? Я говорил о динамичности окружающего мира и о том, что к изменениям надо подстраиваться. И что ООП не даёт быстро к ним подстраиваться.
Моё высказывание насчёт квантовой механики было о том, что самым важным постулатом в КМ является то, что наблюдение отчасти определяет систему. Не существует систем, не зависящих от наблюдателя. Это прямо явно в математической модели прописано, в том месте, где они отказываются от наблюдаемых, привычных для классической механики.
Это вообще не вопрос точности и влияния на систему наблюдателя. Это говорит о том, что наблюдение — это часть самой системы. А наблюдение — это выделение инвариантов. И когда вы пишете программу, вы такие инварианты в системе выделяете. Но когда система начинает пользоваться вашей программой, то она сама меняется уже, меняются инварианты.
Точность моделирования тут совершенно ни при чём. Важен сам факт моделирования. Да, конечно, если вы наблюдаете чего-нибудь вроде сверхмассивной чёрной дыры, то вы вряд ли многое измените своим наблюдением, система крайне симметрична и пофигична. Но вот прогноз погоды определённо влияет на саму погоду. Ещё раз, вдумайтесь: допустим, мы не прогнозируем погоду, и начинаем запускать наши космические ракеты, руководствуясь лишь показаниями термометров, мы их запускаем в ураганы и штормы, они ломаются, сбиваются с курсов, взрываются. А объекты эти высокоэнергетические, они вполне способны вызвать изменения в течении ветров. Может быть, не глобальные, небольшие, но могут. Следовательно, наши прогнозы погоды влияют на погоду. И это очевидно. Я уж не говорю о таких прозаических вещах, как разгон облаков где-нибудь или принудительный сброс лавин. Всё же делается на основании прогнозов.
Если вы не можете выстроить в голове у себя такую простую логическую цепочку, какой нафиг вы программист?
(3) Хотя, как кажется, вы из КМ знаете только о принципе Гейзенберга, поэтому все эти ассоциации для вас пустые. Хорошо, менее возвышенный пример. Вы пишите программу визуализации для математика. Он что-то насчитал по своей математической модели. Он уверен (на 100%), что показать вы ему должны именно такие параметры. Вы пишете программу, вы выделяете классы, вы инкапсулируете данные правильно и корректно, в полном согласии с тем, что вам сказал математик. Вы строите 3D-объекты, которые отражают модель.
Вы ему показываете это всё, и он мгновенно понимает, что ошибался. И нужно смотреть на другие параметры, потому что в итоге, то, что он просил показать, просто сфера. Потому что всё симметрично. Ему это полезно, конечно. Он теорему докажет. Но вам придётся переписывать программу, чтобы построить другие сечения, чтобы использовать другие данные, чтобы крутить в 3D другие объекты. И вот тут вы убьётесь от рефакторинга и переписывания своих навороченных интерфейсов.
Если вы программируете в какой-нибудь особо устоявшейся области, таких проблем не возникает. Паттерны известны, интерфейсы тоже. Все знают, например, что такое параграф при вёрстке текста. Есть 20 стандартов и 100 рекомендаций по проектированию. Но если область непонятная, динамичная, то вы ничего не знаете, и уже пытаетесь всё инкапсулировать. Это лишь тратит силы и приводит к каше в коде, когда придётся всё менять и подстраивать под изменившуюся реальность.
И именно поэтому я говорю, что в ООП меньше динамизма, ООП мешает писать программы, в развитии которых нужна гибкость.
(5) Я умею (реальные проекты) программировать на Си, Haskell, Clojure, Bash, Go (отличная, кстати, демонстрация того, что обычный ООП — отстой, что в нём не хватает динамики, Goшный подход с интерфейсами, которые можно лепить для всего, без всяких теорий и правил, прямо на месте гораздо продуктивнее), Си++, Lua, на куче ассемблеров, Javascript, PHP, Python. Если это называется сидеть на одном и кричать, что только это круто, то что называется не сидеть на одном? :) Это как вы? Не знать левым полушарием о том, какой бред рождается в правом? Ну так, чтобы жизнь скучной не казалась?
И моя критика ООП основана не на пустом месте, а на опыте. Я пытаюсь его как-то выразить словами, а вы почему-то какие-то галлюцинации при этом видите. Где я, например, сообщил, что Си является единственным и неповторимым? Где я сообщил, что не нужно ничего другого изучать? Не приписывайте свой фантазии мне.
(6) Аргументы закончились у вас, ибо вы переходите на личности: мол я не знаю того, не знаю сего, говорю чушь, не имею аргументов и т.д. и т.п. Вы ни разу не возразили по существу. Кроме невнятных попыток написать что-то про точность моделирования, что вообще иррелевантно.
(7) Не надо вам Haskell. У вас навыков восприятия печатных текстов не хватит. И с вашей фанатичностью (хоть вы и утверждаете обратное, но на самом деле, вы — типичный фанатик, судя по эмоциональному накалу ваших постов) и не готовностью вдумываться в чужое мнение, просто впустую потратите время. Haskell не так прост. Да. И ещё спасёте Haskell сообщество от себя-любимого. Там фанатиков и без того хватает.
«динамические инварианты от концепции переменной» — это values и identities в терминах статьи?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Коротко об истории объектно-ориентированного программирования