Не происходит ли следующая ситуация: есть контекст ООП, в рамках этого контекста - вводится определение объекта - как некого компонента - который реализуется на уровне языка и который инкапсулирует в себе данные и методы работы над этими данными.
(именно объекта, а не класса)
Т.е. есть контекст обсуждения про ооп языки - типа есть ли инкапсуляция в питоне , если там на уровне языка не поддерживаются private/protected методы. В таком контексте - да инкапсуляция в js и питоне есть, data hiding'a нет.
А есть контекст который больше про проектирование. И там уже понятие инкапсуляции размыто. Конкретный язык выступает лишь как средство достижения поставленных целей. Имеет ли смысл объединение данных и методов работы над этими данными, без возможности запретить изменять данные из вне, т.е. не из этих вот методов - вот этот вопрос актуален именно в этом контексте. Считать ли инкапсуляцию в js и python не настоящей? Если там можно прям вот взят и поменять свойство объекта в обход методов этого объекта? Вот тут имхо лютый субъективизм .
У
@fes0r отличный пример про инкапсуляцию в контексте проектирования, на примере транзакций. Но это имхо актуально именно в контексте проектирования.
Попытка же дать формулировку термину инкапсуляция без привязки к контексту - бессмысленно и беспощадна.
Т.е. тут некий аналог ddd c bounded context - одна и та же языковая конструкция, может сильно по разному восприниматься в разных контекстах. И нужно топить не за унификацию понятия, а за то что бы четко очерчивать контексты и их границы.