История изменений

> Object-oriented programming (OOP) is a programming paradigm based on objects … An OOP computer program consists of objects that interact with one another.

Объектно-ориентированное - то, что основано на объектах и состоит из объектов. А масло - то, что масляное и состоит из масла.

Вообще, каким был ООП 40 лет назад - это другая реальность. Современные популярные языки вроде C++/Java - не Smalltalk. Поэтому определение нужно более точное, поближе к тому, как именно языки реализуют ООП и как люди его используют и понимают. Мои «4 столпа» - определение упрощённое, но явно лучше тавтологии и достаточно, чтобы показать контраст на примере Си (именно в этом контексте было приведено определение).

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

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

Вообще, раз уж вы знаете понятие «инвариант», может быть вспомните такие понятия как white-box и black-box?

> То есть, даже когда они понимают, что делают что-то через жопу, их это совершенно не останавливает.

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

Наследование реализации - это концепция, которая совмещает в себе переиспользование кода (зависимость от деталей реализации родителя) и отношение вида is-a. Размывается разница между (внутренними) обязательствами и тем, что задумывалась как скрытая кухня класса. И даже если мы чётко задокументируем инварианты *всех* членов, мы всё равно по сути зависим от деталей реализации: мы знаем об объекте намного больше, чем тот инкапсулировал, просто теперь с гарантиями.

Правильное решение с точки зрения дизайна языка - не смешивать внутренний контракт и зависимость от деталей реализации. А не уповать на то, что программист всезнающий и следит за всеми инвариантами в каждый момент времени. Это аргумент вида «просто не присваивай null туда, где он не должен быть».

> Object-oriented programming (OOP) is a programming paradigm based on objects … An OOP computer program consists of objects that interact with one another.

Объектно-ориентированное - то, что основано на объектах и состоит из объектов. А масло - то, что масляное и состоит из масла.

Вообще, каким был ООП 40 лет назад - это другая реальность. Современные популярные языки вроде C++/Java - не Smalltalk. Поэтому определение нужно более точное, поближе к тому, как именно языки реализуют ООП и как люди его используют и понимают. Мои «4 столпа» - определение упрощённое, но явно лучше тавтологии и достаточно, чтобы показать контраст на примере Си (именно в этом контексте было приведено определение).

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

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

Вообще, раз уж вы знаете понятие «инвариант», может быть вспомните такие понятия как white-box и black-box? Гляньте ещё раз в профильную литературу.

> То есть, даже когда они понимают, что делают что-то через жопу, их это совершенно не останавливает.

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

Наследование реализации - это концепция, которая совмещает в себе переиспользование кода (зависимость от деталей реализации родителя) и отношение вида is-a. Размывается разница между (внутренними) обязательствами и тем, что задумывалась как скрытая кухня класса. И даже если мы чётко задокументируем инварианты *всех* членов, мы всё равно по сути зависим от деталей реализации: мы знаем об объекте намного больше, чем тот инкапсулировал, просто теперь с гарантиями.

Правильное решение с точки зрения дизайна языка - не смешивать внутренний контракт и зависимость от деталей реализации. А не уповать на то, что программист всезнающий и следит за всеми инвариантами в каждый момент времени. Это аргумент вида «просто не присваивай null туда, где он не должен быть».