Про объекты

[vitus_wagner]

beldmit тут мне задал несколько вопросов про объектно-ориентированное программирование. Которое я систематически ругаю, за то что его использут не по делу.

Ответы я выношу в отдельный пост, поскольку внутри 200-комментной дискуссии их вряд ли кто-нибудь кроме него прочитает.

если каждый продвинутый тиклер писал свою объектную систему, то не следует ли из этого, что объектный подход таки естетсвенен и удобен?

Объектный подход, очевидно, имеет свою нишу. В которой он таки да, естественнен и удобен. Но вот GUI этой нишей не является.

Далее, существует несколько видов объектного подхода. Даже в компилируемых языках на базе C есть Objective-C и C++ с существенно разными объектными подходами. А если мы рассмотрим, скажем, SmallTalk, Python и Ruby, разница будет еще больше. Или можно сравнить несколько объектных систем Tcl, входящих в tcllib. Они существенно разные.

Разбирать, чем именно разные, и в каких конкретно случаях удобна та или иная разновидность, мне сейчас лень.

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

чем тебе не объектное API fopen/fread/fclose?

Тем что FILE * нельзя унаследовать. Вернее, может быть оно и объектное API, но использование объектного API и объектно-ориентированное программирование - разные вещи.

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

Плохой объектно-ориентированный подход, это когда объект НЕОБХОДИМО наследовать чтобы получить уникальный экземпляр. Например, интерфейсы Turbo Vision были устроены так, что для каждого приложения было необходимо порождать наследника от TApplication, а для каждого диалогового окошка - наследника от TDialog.

Еще один пример плохого OO-дизайна - объект SocketServer в стандартной библиотеке Python.

Ему при инициализации передается имя класса-наследника RequestHandler, и он сам порождает экземпляр этого класса. Если бы ему передавался инициализированный экземпляр, было бы гораздо удобнее. Можно было бы написать один RequestHandler, который работал немножко по-разному. в зависимости от переданных при инициализации данных.

Хороший объектно-ориентированный подход это когда в большинстве случаев ты можешь рассматривать объекты как данность, как такие встроенные типы. А наследовать их - только когда задача ДЕЙСТВИТЕЛЬНО нетривиально.

Даже если у тебя вся остальная программа объектная, и есть какая-то своя иерархия классов, наследовать стандартные классы из библиотек тебе ни к чему. Ими и так можно пользоваться, производят необходимую кастомизацию с помощью параметров и делегирования.

Примером хорошего объектно-ориентированного подхода являются перловые модули CGI и DBI.

Плохим объектно-ориентированным языком является такой, где нельзя унаследовать int (или другой встроенный базовый тип). Вы уж или штаны наденьте, или крестик снимите. Или у вас объектный язык, тогда от любого используемого типа данных можно породить наследника, переопределив часть его свойств, либо не заикайтесь об ООП.

Comments

[elzhov.livejournal.com]

> Плохим объектно-ориентированным языком является такой, где нельзя унаследовать int (или другой встроенный базовый тип).

Это скорее примитивный тип. Наличие примитивных типов в С-шных языках связано, подозреваю, с наличием автоматической памяти (обычно стека), которую допустимо инициализировать копированием:

int x = f();

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

{
int x = 8;
}

пришлось бы писать

{
NSNumber *x = [[NSNumber numberWithInt:8] autotelease];
}

:-) Полагаю, для чистой ОО-программы записи

Type x = g();

вообще не должно быть (в С++-ном смысле), равенство должно возвращать ссылку на объект справа, а не "копировать" его, ибо под "копированием" можно понимать все, что хочешь.

[zabivator.livejournal.com]

Это скорее примитивный тип. Наличие примитивных типов в С-шных языках связано, подозреваю, с наличием автоматической памяти (обычно стека), которую допустимо инициализировать копированием
С++ - расширение Си (с точностью но неинтересных отличий).
В Си все типы POD (plain old data - типы, допускающие копирование побайтовым копированиеи).
С++ просто унаследовал POD и их семантику.

Так что надо ставить вопрос "с чем связано наличие примитивных типов в Си". А это вопрос вроде простой - интегральные типы соответствуют типам процессора, а пользовательские типы данных - простые Sum Types (enum) хорошо мапятся на "массив байт", Structures просто конкатенация её членов, а union - суть кусок памяти sizeof(some_union)=max(sizeof(Xi)), где Xi - i-ый элемент union.

[elzhov.livejournal.com]

> В Си все типы POD (plain old data - типы, допускающие копирование побайтовым копированиеи).

Это не так для структур, если С-шная структура содержит указатель на что-то там. Побайтовое-то копирование, конечно, законно, но это далеко не всегда то, что пользователь понимает под "создать копию объекта".

> Так что надо ставить вопрос "с чем связано наличие примитивных типов в Си". А это вопрос вроде простой

Не, с этим вопросом проблем нет :-) я отвечал скорее на вопрос, почему ненаследуемые типы оставили даже для спроектированных с нуля языков - Java, C#: в ряде случаев их использование ведет к более привычному и читаемому коду (не говоря уж об эффективности), чем использование "чистокровных" объектов.