Виктор "Витус" Вагнер (vitus_wagner) wrote,
Виктор "Витус" Вагнер
vitus_wagner

Categories:

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: ung, компьютерное
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 75 comments