OOP в университете и индустрии

[avva]

У факультета компьютерных наук в Carnegie-Mellon University очень высокая репутация, он известен как один из самых лучших в Америке - именно этот факультет, а не весь университет. Так вот, в нем, оказывется, решили не преподавать больше объектно-ориентированное программирование в вводных курсах. Те студенты, что захотят с ним познакомиться, смогут это сделать на факультативном предмете для второго курса:

Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic.

Этой новости уже два года - не знаю, как там у них с этим все вышло. В комментариях к этой блог-записи есть умеренно интересный спор о том, действительно ли ООП "anti-modular and anti-parallel by its very nature", в котором присутствует много академического жаргона.

Я не знаю, что думать конкретно об идее "не преподавать ООП на первом курсе CS". Профессор CMU утверждает, что одной из причин их решения было то, что они встретились с выпускниками CMU, работающими сейчас в Facebook, и те им сказали, что больше всего в университете им помог курс функционального программирования, так что они решили давать побольше этого. Проблемы с этим аргументом очевидны: FP необязательно должно целиком вытеснять OOP, а главное, эту информацию они получили от людей, которые будучи студентами как раз начинали с OOP-языка. Но с другой стороны, есть резон и в том, что факультет CS должен давать студентам теоретические начала, а также учить их думать и понимать, а не только обучать писать программы, и на престижном факультете, куда идут абитуриенты высокого уровня, может и лучше это делать с помощью императивных и функциональных языков, а OOP считать чем-то, что можно потом подучить.

Поскольку я вижу обе стороны этого спора, и не могу между ними решить (недостаточно данных), я напишу вместо этого о применении OOP в индустрии, которое хоть и повсеместно - это глупо отрицать, но довольно значительно изменилось за последние 20 лет. Мне кажется, что в этом - в том, как применять OOP - мы коллективно многому научились, хоть этот опыт плохо согласуется с "философией" OOP, скажем так.

Я думаю, что развитие OOP-языков и то, как они применяются на практике, особенно в больших проектах, показало за последние 20 лет следующую тенденцию. Главная польза OOP была и остается в том, как эта практика помогает модуляризации исходного кода. Под модуляризацией я понимаю в широком смысле все, что помогает программисту, с одной стороны, держать связанные друг с другом вещи вместе (как на экране, так и в уме), и с другой стороны, иметь дело с менее тесно связанными вещами раздельно. При этом "помогает" означает не только "делает возможным", но также - и даже более важно! - "делает обычным, очевидным, самым простым выбором".

Это может показаться на первый взгляд тривиальным утверждением, но не думаю, что оно совсем тривиально. Когда говорят о достоинствах OOP, упоминают всякие разные вещи. Например:
- моделирование проблемы или решения в виде иерархии объектов и их методов
- code reuse: использование уже написанного кода, который надо лишь немного изменить (или добавить в него), с помощью наследования
- энкапсуляция, скрытие внутренней имплементации от внешних пользователей

Я считаю, что эти вещи сами по себе важны намного меньше, чем то, насколько они помогают или мешают главной цели: модуляризации исходного кода. Именно это в конце концов решает то, стоит ими пользоваться или нет, и к этому в конечном итоге, путем проб и ошибок, приходит вся индустрия.

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

1. Начнем с самого основного: соединения кода и данных в одном классе. Это оказалось невероятно полезной идеей, которая, возможно, отвечает за львиную долю всей пользы от OOP вообще. При этом согласно академическим или пуристическим понятиям это даже необязательно OOP вообще, но это неважно. Представьте себе C++ без виртуальных функций, наследования и полиморфизма, просто с классами, в которых есть данные и методы. Неважно, что специалист по теории языков программирования скажет, что это не OOP вообще, а тривиальный синтаксический сахар (а что-то типа CLOS в Лиспе, где нет четкой привязки методов к классам, наоборот, самый что ни на есть OOP). Даже этот тривиальный синтаксический сахар сам по себе уже дает огромную пользу в смысле модуляризации. Оказывается, огромное количество решений, которые приходится писать на практике, естественным образом выглядят так: небольшое количество связанных друг с другом данных, и функции для работы именно с этими данными. Понятие класса помогает держать эти связанные вещи вместе, а не связанные вещи - отдельно, в другом классе (и другом файле обычно).

Конечно, для этого не обязательно иметь OOP или понятие класса. Мне приходилось иметь дело с большими проектами, написанными на C; в них обычно оказывалось, что во многих исходных файлах определена одна-две небольших структуры, хранящие связанную друг с другом информацию, и рядом - функции для работы с этой структурой. Имена функций и структур подчеркивают их связь; часто складывается конвенция, что функции получают указатель на структуру первым аргументом. Все это работает, но чтобы это поддерживать, нужно стараться. Если не стараться (или если поручить дело слабенькому программисту), со временем функции для работы с этой структурой растекутся в другие файлы, имена будут не очень ясные, итд. Классы дают эту модуляризацию практически бесплатно и поддерживают ее тоже почти бесплатно. В одном этом уже - огромное их преимущество. Это также главная причина, по которой C++ победил C.

2. Наследование по интерфейсу помогает модуляризации. Определяется контракт, и он разделяет в пространстве (исходного кода) и уме (программиста) имплементацию и использование этого контракта. В больших проектах это незаменимо. Должен быть какой-то способ решить: я делаю это, а ты делаешь это, и мы потом вот по этой линии стыкуемся. Эта линия будет контрактом, как ее ни назови; но моделировать ее в виде интерфейса или абстрактного класса очень удобно (в динамических OOP-языках происходит то же самое, просто контракт задается неявно или в документации, а не в виде типа). Кстати, в небольших проектах это тоже необходимо, даже если есть только один программист: "я" и "ты" просто означает "я сегодня" и "я завтра". Должна быть возможность думать только о части системы.

Полиморфизм помогает модуляризации в той мере, в какой он обеспечивает удобную работу с контрактом, т.е. наследованием по интерфейсу.

3. Наследование кода (implementation inheritance) мешает модуляризации, и поэтому почти всегда оказывается плохой идеей. Я не могу окинуть взглядом одну штуку (класс) и понять ее поведение, мне нужно учитывать другие штуки (классы), которые написаны обычно в другом месте, в другом файле. Одного этого достаточно, чтобы навредить модуляризации. Этот вред обычно оказывается значительнее, чем польза от code reuse. Говоря в терминах Джавы, implements намного полезнее extends. Множественное наследование (multiple inheritance) в этом смысле еще хуже, и вреда от него - в реальном мире и с реальными программистами, а не в идеальном мире, населенном гуру - намного больше, чем пользы. Решение Джавы отказаться от множественного наследования кода вообще в этом смысле закономерно. Триумф STL, в которой практически нет наследования кода, над другими потенциальными стандартными библиотеками для C++ - закономерен.

Все это про интерфейсы, наследование итд. никто не понимал в начале 90-х, а сейчас понимают многие, а может, это уже и стало общим местом, не уверен. Так что прогресс налицо.

Comments

[angerona.livejournal.com]

sophomore — это второй курс

[avva.livejournal.com]

да, спасибо, я вечно это забываю. Сейчас исправлю.

[cmm.livejournal.com]

относится ли энкапсуляция к инкапсуляции как эмиграция к иммиграции?

[asox.livejournal.com]

Тогда это должна быть экскапсуляция...

[nec-p1us-u1tra.livejournal.com]

Я ни разу не, но

> Неважно, что специалист по теории языков программирования скажет, что это не OOP вообще, а тривиальный синтаксический сахар

да, сахар и не требует концепции класса или объекта. ср. перловое

{
my $var;
sub1 {};
sub2 {};
}

вполне изолированный набор из данных и кода, вдобавок данных скрытых от внешнего мира.

[tlkh.livejournal.com]

а можно таких штук создать несколько экземпляров?

[kodt-rsdn.livejournal.com]

extends vs implements... проблемы начинаются, когда нужно позаимствовать готовое поведение.
Например: у всех окошек есть более-менее одинаковое оформление, функции перемещения и изменения размера, и т.д. и т.п., и у каждого - своя "бизнес-логика".
Сделать MyWindow implements IWindow и определить все методы этого IWindow, пускай даже как вызовы соответствующих системных функций-заготовок - поистине издевательство.

Для заимствования не так уж много хороших средств.
Это или миксины, или наследование.
Миксины заморачивают, а наследование развращает. Выбирайте! %)

[huzhepidarasa.livejournal.com]

Да, окошки очень хорошо укладываются в парадигму ООП, даже в ее темные и опасные углы. Благодаря чему ООП и завоевало мир, кстати.

[huzhepidarasa.livejournal.com]

В STL нет наследования и по интерфейсу тоже, там другие контракты.

[thedeemon.livejournal.com]

STL вообщне не ООП. Сам Степанов так говорил:
"STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people."

[timur0.livejournal.com]

хороший анализ, спасибо

[ushastyi.livejournal.com]

Все, что Вы написали, это все правильно, и здорово написано на самом деле, но этому как раз НЕ учат в курсах ООП. Это приходит или не приходит с опытом.

А вот функциональное программирование очень хорошо учит именно программировать и думать. Поэтому не случайно, что классический MIT-овский курс по программированию был функциональным (http://mitpress.mit.edu/sicp/)

P.S. А к Carnegie-Mellon у меня сложное отношение. В Москве преподаватели оттуда читают иногда треннинги, и я был на нескольких. Правильные, хорошие. Но по большей части бесполезные в практической деятельности. Теоретики.

[javax-slr.livejournal.com]

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

[alexandre sorokine (from livejournal.com)]

Я думаю, что основная причина отказа от курса в отсутствии хорошей академической теории OOP какова, например, есть у функционалчного программирования (lambda calculus). Inheritance, incapsulatiоn, code reuse это скорее набор пожеланий сильно по-разному реализованный в разных языках.

[migmit.livejournal.com]

Гм... Theory of Objects, Абади-Карделли?

[juri-jurta.livejournal.com]

OOP is anti-modular and anti-moral by its very nature - http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

[avva.livejournal.com]

Это против Джавы более, чем против OOP.

[anton-solovyev.livejournal.com]

Мне кажется, уже стало общим местом. В тот момент, когда design patterns внезапно заменились просто refactoring.

И таки я абсолютно согласен -- ООП failed как его подавали вначале, и succeeded (практически) в той части где оно просто добавляет дополнительные scopes.

[xeno-by.livejournal.com]

Я бы хотел упомянуть, что качественное ООП это не просто scopes для термов (то, что обычно понимается под инкапсуляцией), а еще и scopes для типов (т.е. экзистенциальные типы): http://avva.livejournal.com/2581700.html?thread=93742788#t93742788.

2 cents

[a r (from livejournal.com)]

1. Энкапсуляция очень важна - когда 1000+ программистов на четырех континентах курочат общий код - очень помогает что некоторые вещи не могут быть сломаны без измения интерефейса - которое куда проще отследитью

2. Если не увлекаться хиерархиями - использование platform-independent base classes + platform-dependent derived ones, позволяет software пережить несколько поколений hardware.

3. Гарантированное выполнение деструктора (c++) очень очень большое дело для тех кто понимает как этим пользоваться.

Главная проблема - даже минимально приемлемый уровень реального знакомаства с тем же с++ не под силу примерно половине С программистов, что ставит практический крест на применении в больших организациях.

Re: 2 cents

[polter.livejournal.com]

Гарантированные выполнени деструктора и следующее из него raii - это, конечно, круто, но к ооп не имеет ну совсем никакого отношения.

[zumba.livejournal.com]

Пункт 3 - очень правильный.
Использование наследования обычно заканчивается на примерах из обучающей литературы.
Редкое исключение - инфраструктура, например Socket->TcpSocket->AsyncTcpSocket.
Множественное наследование - вообще ад.
А интерфейсы - как раз весьма полезная вещь. В особенности для выработки дисциплины чёрного ящика.

[xeno-by.livejournal.com]

А что делать с интерфейсами, рядом с которыми хочется положить еще и методы с конкретными реализациями?

[golos-dobra.livejournal.com]

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

[lyuden.livejournal.com]

Взгляд дилетанта.

У меня нет специального образования. Я не знаю четыре главных слова и т.д. Программировать я учился на Паскале, и до ООП мы не дошли. Потом в аспирантуре я писал в основном рассчетные программки на Питоне. Сейчас работаю фрилансером, конкректно сейчас перевожу разработанные математические модели на Питон, так чтобы они быстро и параллельно считались.


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

По поводу интерфейсов, возражение примерно такое же как и при холиваре cтатическая / динамическая типизация. Используя юнит тесты можно проверять соответсвие протоколу в критичных местах, и все. Поддерживать протокол везде - "неэкономично"

Особенность моей работы (у меня фактически нет начальников-программистов и большая часть кода уходит в "архив") позволяет мне творить некую функциональщину.
Которая просто получается короче и понятнее.

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

{"f1":f1v1,"f2":f2v1,"f3":f3v2,"f4":f4v1}

а то что они стоят на своих местах проверяется юниттестами тривиально.

Своих племянников я ООП учить не буду, до последней возможности.

[http://users.livejournal.com/_winnie/]

> Триумф STL, в которой практически нет наследования кода, над другими потенциальными стандартными библиотеками для C++ - закономерен.

Забудем про iostream, посмотрим на реализацию контейнеров в STL.

Там наследование для code reuse в полный рост, что бы четыре раза не реализовывать set, map, multiset, multimap. Не знаю почему именно через наследование.

Заглянул в lib/gcc/i686-pc/4.5.3/include/c++/unordered_set

unordered_set унаследован от __unordered_set,
__unordered_set от _Hashtable,
_Hashtable множественно унаследован аж от трёх классов _Rehash_base, _Map_base, _Equality_base

Т.е. унаследовать автомобиль от рулевого колеса и багажника в STL - это самое обычное дело

[meshko.livejournal.com]

Оно там вроде внутри, а наружу не пускают.

[meshko.livejournal.com]

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

По поводу параллелизма -- я на нынешнем проекте эксперементирую с immutable objects там, где есть concurrency. Очень непривычно и все время кажется, что все очень неэффективно, но на самом деле багов меньше и думать легче. У знакомых похожий опыт.
Пытаюсь отучить себя от использования inheritance как оружие борьбы с copy/paste. С этим пока успехов меньше, но очевидно, что нужно.

[xeno-by.livejournal.com]

Не все так просто с OOP. Коммьюнити ML + дальше Одерскому + (еще тем, кто участвовал, но я о них не знаю) понадобилось неслабое время, чтобы в удобном и понятном виде представить концепцию nested types. Реализовывается это тоже не за одну лекцию: http://avva.livejournal.com/2581700.html?thread=93742788#t93742788.

[mynine.livejournal.com]

К вашему посту, содержащему здравые мысли, у меня есть много замечаний, но боюсь, это надолго ;). Например, про язык СИ - там действительно очень часто используется связь кода и данных - функции изначально рассчитаны на работу со структуру и жестко с ней связаны (банальные fopen, fread, fwrite) фактически просто замена o.foo() на foo(o).
> но чтобы это поддерживать, нужно стараться.
Опыт показывает что если не стараться, то в С++ получается не менее худший код, просто несколько в другом направлении. Например, часта излишняя любовь к громоздким классам, где все поведение описывается в виде методов, вместо свободных функций, что уменьшает связывание и улучшаю инкапсуляцию. Кстати, такие функции нечлены тоже являются интерфейсом класса.

stl мало использует динамическое наследование (вроде только fstream, вдобавок множественное :), но широко использует статическое, для чего шаблоны и были созданы.

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

[migmit.livejournal.com]

Не соглашусь во многом:

1) Соединение кода и данных — замечательная штука, но не на уровне класса. Правильно — на уровне неймспейса. То, что в плюсах классы очень часто, по сути, эмулируют неймспейсы (это при наличии настоящих неймспейсов) — большая печаль.

2) Наследование по интерфейсу — а точнее, РЕАЛИЗАЦИЯ интерфейса — великая вещь, согласен.

3) Наследование кода — плохая вещь, тоже согласен, но STL победила не поэтому. STL победила потому, что была завязана на параметрический полиморфизм. Ну, насколько C++ его вообще умеет (на самом деле, ни насколько, но прикидывается довольно прилично). При этом изначально ООП задумано именно как средство наследования кода.

И неймспейсы, и реализации интерфейса, и параметрический полиморфизм — такие вещи, которые в курс ФП легко вкладываются. Во всяком случае, все они уже есть в древнем Haskell98.

[avva.livejournal.com]

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

3) Параметрический полиморфизм - это просто фраза, которую >99% пользователей STL не знают и знать не хотят. STL победила потому, что дала им легкую возможность 1) положить штуки в контейнер 2) найти их в контейнере 3) вынуть их из контейнера 4) отсортировать контейнер, и при этом кроме собственно выбора контейнера НИЧЕГО БОЛЬШЕ НЕ НАДО ЗНАТЬ. Ну это не совсем верно, надо помнить, что такое итераторы и pair, но это легко. В OOP-версии подобной библиотеки нужно было бы знать и понимать в основных чертах иерархию, знать, из чего что наследовать итд.

[plutoid-id.livejournal.com]

Скажите, в Гугле используют блок-схемы алгоритмов? Мой преподаватель в этом убеждён.

[http://users.livejournal.com/_winnie/]

Да, выглядят как-то так - http://dobrokot.ru/pics/i2013-03-13__05-34-11_714kb.jpg

[cryinstone.livejournal.com]

"Object-oriented programming... is both anti-modular (!) and anti-parallel (?!) by its very nature"
---
WTF?

[migmit.livejournal.com]

За параллельность не скажу, но насчёт anti-modular — чистая правда.

[kblcbka.livejournal.com]

Спасибо! Я думала похожее, очень приятно найти подтверждение.

[gxk10.livejournal.com]

Я недавно слушал лекцию по ООП, и преподаватель утверждал что это практически консенсус в наши дни: код наследовать нельзя, можно только интерфейсы. Если несколько классов делят имплементацию какой-то функции, это выносится наружу (Utilities, Strategy pattern).

[migmit.livejournal.com]

К сожалению, это консенсус (и то не совсем) среди тех, кто понимает, что делает.

[potan.livejournal.com]

Классы типов (Go, Haskell, Mercury) лучше подходят для описания интерфейсов, чем интерфейсы/абстрактные классы из ООП.

[xeno-by.livejournal.com]

Почему?

[vit-r.livejournal.com]

Так вот, в нем, оказывется, решили не преподавать больше объектно-ориентированное программирование в вводных курсах.

Мой приятель преподавал Яву и экзамены принимал. Но вот сам в программе из пяти строк запутается.

Это я к тому, что профессора слишком далеки от индустрии, чтобы кричать о тенденциях. Люди до сих пор на Коболе пишут.

[norian.livejournal.com]

+100500

во многих случаях агрегация лучше наследования

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

шаблоны и операторы рулят - опять же, если не злоупотреблять
намного понятнее когда в коде написано d = a[i] + b[j] + c, чем ProcessCoeff2(d1,GetValue(a,i),GetValue(b,j)); ProcessCoeff2(d,d1,c);
к сожалению, количество операторов ограничено

[itman.livejournal.com]

Плюсую, агреграция + generics/templates хорошо работают.