Десять вещей, которые я терпеть не могу в ООП

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

Однако в реальном мире есть только объекты. Классы существуют только в нашем сознании. Можете ли вы привести хоть один пример из реального мира, что класс — это реальная, физическая сущность? Нет, не думаю.

Тут автор явно передергивает. Понятно, что классы существуют только в нашем сознании, но, о ужас, не только классы, но и функции, переменные и проч. Например, функция — это лишь некоторая процедура в коде, которая вызывается через CALL и возвращается RET. А если копнуть глубже, то окажется, что есть только ассемблерные команды, и там вообще нет таких понятий, как процедуры, а есть регистры и память. А если еще глубже копнуть, то окажется, и этого нет, а есть заряды и токи, потенциалы и поля. А потом оказывается, что и полей нет, т.к. поля — лишь удобный инструмент физиков для предсказывания реальности, но это уже философия. Поэтому говорить, что классы существуют только в нашем сознании — это все равно, что сказать, что вода — это жидкость. Ну да, и что плохого?

В процедурных программах процедуры вызывают другие процедуры. Процедурный код показывает… процедуры, вызывающие другие процедуры. Все хорошо и просто, так ведь?

В объектно-ориентированных программах объекты посылают сообщения другим объектам. Объектно-ориентированный код показывает… классы, наследующие другие классы. Ой. Кажется, что в ООП между исходным кодом и исполняемой программой нет никакой связи. Наши инструменты плохо помогают нам: IDE ведь показывают классы, а не объекты.

С тем же успехом можно утверждать, что параметры — вот они были объявлены my_param, а теперь вдруг при исполнении опа, и нет my_param, а есть лишь 0 в ячейке памяти. Неожиданно, правда? Так и с объектами, есть класс, который объявляет, что будет внутри, т.е. сосуд, а наполнение может быть самым разным. Это, на минутку, присуще всем языкам, ООП тут вообще ни при чем.

Честно говоря, методы я тоже терпеть не могу.

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

Примем во внимание то, что на чтение объектно-ориентированного кода мы тратим больше времени, чем на его написание.

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

Конечно, “бестиповых” языков не существует — существуют статически и динамически типизированные. Статически типизированные мешают писать код в некоторых случаях. В принципе, ничего плохого в этом нет.

Наверно, в функциональных языках нет типов? Или, может, в процедурных? Очевидно, там нет, поэтому положим минус в копилку ООП, говорит нам автор.

Можно еще долго комментировать это послание про ООП. Но, думаю, для начала достаточно.

Апелляция к авторитету — поскольку некто знаменитый, влиятельный либо уважаемый убеждён в чём-то, то оно обязано быть верным.

Knowledge oriented — это декларативное. Компьютеру нужны четкие процедуры, возможно с ростом AI и будет так. А по поводу литературных слов, так есть всякие DSL. Он на той же Scala можно DSL писать.

Причем здесь автор? Я вообще то высказывал свое мнение.

Ну, в C#, например, как попало функцию не кинешь не обернутую в класс.

Оскара не устраивает.

Информация о всех эмпирическая, полученная на основе анализа литературы по разработке и аудитории различных конференций.

Меня не устраивает термин ООП. Уже давно, почти с самого начала, это не объектное, а классовое и интерфейсно ориентированное программирование. И парадигма звучит не как «всё есть объект» а как «для всего есть абстракция и контракт». Именно в переходе от объектов к классам происходит смещение крыши у некоторых разработчиков и появляется ощущение пустоты в душе.

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

Возможно критики ООП просто плохие полемисты и вселенная ждёт своег спасителя который прийдёт и раскроет заговор оопэшников. Но пока сторонники функциональной парадигмы пишут своё ПО на IDE которое полностью оопэшное и запускают его на осях которые полностью оопэшные. И даже те кто программирует железо тоже пишут свой асемблер на оопэшном IDE.

Мир не-ООП вокруг крайне мал. А этот мир создают тысячи вендоров и миллионы разработчиков в жёсткой конкуренции. Сейчас ООП вчистую выигрывает эту конкуренцию, а значит — всех устраивает.

Странно немного это. Те, кто, к примеру, изучал Delphi, наверняка встречались с понятием «пяти уровней инкапсуляции». Это как раз 5 модификаторов доступа: public, private, protected, automated и published . В большинстве остальных языков таких модификаторов 3( что верно, ведь программисты Borland засунули в Delphi модификаторы automated и published для внутренних нужд самой IDE ). И вообще, в ООП даже нет такого понятия, как «сокрытие данных». Есть 4 основных понятия:

абстракция, полиморфизм, инкапсуляция и наследование

.

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

Но так было не всегда. Так, в языке smalltalk было два объекта, относящихся к булевому «классу», и их поведение принципиально различалось. Если переписать это на Java, то получится что-то вроде следующего:

public enum SmalltalkBool {
	FALSE {
		public SmalltalkBool And(SmalltalkBool arg) {
			return FALSE;
		}
		public SmalltalkBool Or(SmalltalkBool arg) {
			return arg;
		}
		public void If(Runnable arg) {
		}
	},
	
	TRUE {
		public SmalltalkBool And(SmalltalkBool arg) {
			return arg;
		}
		public SmalltalkBool Or(SmalltalkBool arg) {
			return TRUE;
		}
		public void If(Runnable arg) {
			arg.run();
		}
	};
	
	public abstract SmalltalkBool And(SmalltalkBool arg);
	public abstract SmalltalkBool Or(SmalltalkBool arg);
	public abstract void If(Runnable arg);
}

Если этот кусок кода проанализировать с точки зрения современных паттернов программирования, то мы увидим три класса — два одиночки (singleton), наследующих общий чисто абстрактный класс. Программист же на smalltalk или теоретик, изучающий модель акторов, увидят здесь два объекта с общим интерфейсом.

«Статические классы» — это противоположность ООП.

Сначала теоретики CS провозгласили «всё есть объект» и придумали ООП; потом практики CS — для удобства реализации — наложили ограничение «любой объект есть экземпляр некого класса»; потом все так сосредоточились на классах, что понятие класса, к которому не относится ни один объект перестало восприниматься как абсурд, и стало привычной частью ООП-языков.