?

Log in

No account? Create an account
Have you ever changed value of four - Журнал Витуса.
[Друзья] [Свежие записи] [Dreamwidth] [Фото] [Тексты] [Друзья Ирины] [Матерные писатели] [Сообщества] [3 круг]
October 3rd, 2009
10:51 pm
[User Picture]

[Link]

Previous Entry Share Next Entry
Have you ever changed value of four
Придется все же вернуться к разбору объектно-ориентированной парадигмы и еще раз уточнить, почему она мне не нравится.

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

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

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

Вот термин "число" это хороший термин. Зная что это число, мы уже очень много знаем об этом объекте. В частности мы знаем, что это число - объект immutable. Число четыре - всегда число четыре, в какую переменную его не засунь. В ранних версиях Fortran бывали ситуации, когда можно было по ошибке изменить значение константы 4 (отсюда и вопрос в hacker's test, вынесенный в заголовок поста), но это давно исправили.

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

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

Возьмем, к примеру, грузовик. Сегодня у него водитель Иванов, завтра - Петров. Сегодня он везет навоз, завтра - сено, после завтра вообще едет порожняком в областной центр за новой молотилкой.
И тем не менее, это тот же самый грузовик. Можно колесо поменять, но он останется тем же самым. Даже регистрационный номер можно поменять, но все равно это останется тот же самый грузовик. Правда, если мы поменяем двигатель, шасси и прочие нумерованные детали, у ГИБДД уже возникнут вопросы на тему того, тот же самый это грузовик или уже другой.

Кстати, вот эту разницу между объектом и переменной для хранения объекта весьма изящно учел Ларри Уолл в пятом перле. У него объектом становится (посредством применения оператора bless) ссылка на значение - хэш, скаляр или масси. Поэтому объект, пусть даже он вполне mutable, обязательно отвязан от переменной, через которую мы получаем к нему доступ. Видимо, лингвистичекое образование сказывается.

А вот в C++, где объекты выросли из структур данных весьма низкоуровневого языка C, путаница между объектом и местом для хранения - в полный рост. Тем более, наследство C дает в этом языке программисту доступ к менеджменту памяти.

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

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

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

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

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

Tags: ,

(75 comments | Leave a comment)

Comments
 
From:gds
Date:October 3rd, 2009 07:44 pm (UTC)
(Link)
в функциональщине есть термин "значение"/"value". И работать со значениями (из одних производить другие) -- очень удобно.
[User Picture]
From:vitus_wagner
Date:October 3rd, 2009 08:00 pm (UTC)
(Link)
Угу. тем, у кого хватило математического образования понять и осознать прелести функциональной парадигмы.
[User Picture]
From:blacklion
Date:October 3rd, 2009 07:50 pm (UTC)
(Link)
По сути, если отжать воду, докапался ты до терминологии а не до самой парадигым (которая не меняется не зависимо от терминологии, как не меняется грузовик как ты его не называй — грузовик, truck, или как-то ещё).

И экземпляр класса (AKA объект) чётко отделён от класса (который при этом в свою очередь может быть объектом, да) — как деталь отделена от своего чертежа (хотя сам чертёж — это тоже объект, класса чертежей).
[User Picture]
From:vitus_wagner
Date:October 3rd, 2009 07:59 pm (UTC)
(Link)
Ну, например в Python-е класс является экземляром класса "type". Что правильно, потому что над классами тоже определен ряд полезных операций.

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

К сожалению, использование в преподавании языков вроде C++ и Java очень способствует возникновению этой самой каши. К мультипарадигменным языкам вообще надо подпускать только после того, как все используемые в них парадигмы в чистом виде усвоены, и усвоена область применения каждой из них.

Но из этого следует практически невозможность изучения программирования посредством casual programming, в тех случаях когда именно мультипарадигменные языки (в том числе и Lisp и Perl с Python) являются наиболее доступным инструментом.
(Deleted comment)
[User Picture]
From:vitus_wagner
Date:October 3rd, 2009 08:03 pm (UTC)

Re: Как обычно, брюзжание

(Link)
Демагогия, потому что объект -- это экземпляр класса, он связан с системой классов и пр.машинерией.
Экземпляром какого класса является COM-объект WinHttp? А DBUS-объект org.bluez.Manager?
(Deleted comment)
(Deleted comment)
(Deleted comment)
From:vp
Date:October 3rd, 2009 08:00 pm (UTC)
(Link)
Ну аналогия в принципе верная, только мы можем сказать "едет грузовик", а можем сказать "едет автомобиль принадлежащий ООО СеноСолома, подразделения по перевозке навоза". Так и с объектами, это "экземпляр класса описывающего автомобиль".
Разный уровень детализации.
Про числа мы тоже можем дальше уточнить, это натуральное число, или еще какое. А все это - числа, да.
[User Picture]
From:vitus_wagner
Date:October 3rd, 2009 08:19 pm (UTC)
(Link)
Вопрос в том, от чего мы этот грузовик отличаем. Помнится, в каких-то стихах про финскую войну, читанных в детстве были такие строчки:

Смотрят белофины,
Ошеломлены
Мчит на них машина
С нашей стороны,
Но не танк, не грозный
Катит броневик,
А простой обозный
серый грузовик


В такой ситуации не важно какой именно грузовик, важно что не танк и не джип.

А в другой ситуации может оказаться как раз важным, что это не абстрактная фура мимо по шоссе едет, и не фермер дядя Вася в город за соляркой поехал, а фермер дядя Петя к нам на огород навоз везет.
[User Picture]
From:aceler
Date:October 3rd, 2009 08:23 pm (UTC)
(Link)
> И то - как максимум. Внешние по отношению к нашей программе COM или dbus-объекты этим свойством не обладают, а все равно - объекты.

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

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

Прототип, ага :)
[User Picture]
From:blacklion
Date:October 4th, 2009 06:35 am (UTC)
(Link)
Вообще же, ты тут не знаю на сколько намеренно путаешь в примерах мутабельность объекта и его identity.

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

Легко можно написать немутабельный объект. И тогда он в смысле "переопределить" не будет отличаться от числа 4. Вот мы его создали (вызовом метода, не записью литерала — но это НЕ ВАЖНО) и всё, ЭТОТ ОБЪЕКТ (экземпляр класса) всегда такой. Можем положить его в одну переменную, можем в другую — ОБЪЕКТ не поменять, нет у него в контракте методов для изменения.

При этом любой (что мутабельный, что немутабельный) объект точно так же может иметь identity.

Вот ты пишешь: “это тот же самый грузовик”. Ну да, тот же самый — identity сохранён — но при этом его перекраксили и заменили покрышки — объект ТОТ ЖЕ САМЫЙ но ИЗМЕНИЛСЯ, он мутабельный. Это две РАЗНЫЕ характеристики а ты попробовал их смешать в одно.
[User Picture]
From:kouzdra
Date:October 4th, 2009 01:34 pm (UTC)
(Link)
Мутабельность объекта напрямую связана с его identity - без оной вообще говоря различить экземпляры значения становится невозможно (если нет специальных операций) - и в SML и Haskell это так и есть.

Свойство называется referential transparency (а его известный аналог в логике - принцип тождества неразличимых, который собственно и есть стандартное определение равенства в логике)
[User Picture]
From:poor_sysadm
Date:October 4th, 2009 08:46 am (UTC)
(Link)
давайте уничтожать все общие термины, потому что они плохие!
зачем говорить плохое слово "снег", когда в эскимосском языке десятки гораздо более лучших и точных?!
From:silly_sad
Date:October 4th, 2009 04:04 pm (UTC)
(Link)
потому что НЕ снег существует!
а НЕ объекта не существует.

множество необъектов строго пусто.
слово "объект" имеет пустой смысл
(Deleted comment)
(Deleted comment)
[User Picture]
From:metaclass
Date:October 5th, 2009 03:26 pm (UTC)
(Link)
Базовая проблема - упаковка сложности. Мы не хотим видеть внутренности объектов и работать с ними, мы хотим видеть только его интерфейс.
Дальше - обобщение, некоторые виды действий можно выполнять одинаково над различными видами сущностей, поэтому мы хотим эти действия написать один раз и дальше использовать.

Ну а статическая проверка или вывод типов это в сущности, не к ООП, она везде должна быть, т.к. сильно облегчает жизнь программисту.
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
My Website Powered by LiveJournal.com