этот тред делает меня грустной пандой. я хочу дожить до тех времён, когда людей, утверждающих что инкапсуляция — это квалификатор private, будут линчевать на глазах у ликующей толпы
не за что. если что, единственным ключевым аспектом ООП является ad-hoc полиморфизм, всё остальное варьируется: вместо классов может быть прототипная система (Io, Self), вместо наследования может быть делегирование (Snit), вместо вызовов методов может быть отправка сообщений (Smalltalk, Erlang), вместо виртуальных функций может быть паттерн Visitor (Haskell, F#). и, вообще говоря, наиболее кривая реализация ООП как раз в C++ (ну и PHP), объектная модель JS вполне себе консистентна [табличка: недовольство, свирепость, но в то же время грусть и недоумение]
Ну тогда уж и полиморфизм необязателен. Это всё в теории. На практике бессмыссленно использовать ООП без инкапсуляции и наследования с полиморфизмом. Впрочем, спорить с ФП-фагом я не буду. ФП накладывает неизгладимый отпечаток...
нет, без ad-hoc полиморфизма не будет позднего связывания, и не будет возмозможности трактовать объекты как чёрные ящики. я не буду отвечать на выпады ad hominem. удачи тебе и побольше практики — особенно той, в которой нет разницы между объектами и экземплярами классов, а так же полиморфизм необязателен для реализации ООП
в случае использования позднего связывания, ты (в статике) не знаешь, к объекту какого типа ты обращаешься по некоторому интерфейсу — и, соответственно, ничего не можешь сказать о его внутреннем устройстве. в Erlang, например, ты фиксируешь только структуру сообщения, по которой и будет выполнена диспетчеризация — а как будет выглядеть обрабатывающий объект (и не будет ли он меняться в процессе работы приложения), ты не знаешь
В рамках твоего примитивного мирка можно привести такой пример: struct A { Integer a; A(Integer _a) { a = _a; } Integer getA() { return a; } } interface IA { Integer getA(); } … IA ia = new A(10);
Тогда работа с ia a priori скрывает внутреннее содержимое A несмотря на то, что оно не инкапсулировано.
20 comments
recommend
bookmark
subscribe
И правильно делает.
Всегда это было одно и то же.
В жабаскрипте, например, и класс объект, и экземпляр класса тоже объект, и массив, и словарь.
Мы об ООП, а не о сомнительных его реализациях в JS или PHP.
Понятно. Кроме говножабки и плюсцов ничего не видели и видеть не хотим.
Я писал в объектно-ориентированном стиле на JS. О каком ООП может идти речь без инкапсуляции, например?
Есть там инкапсуляция. Подход немного отличается, но она там есть, так что не пизди.
"A class is used to create new instances (objects) by instantiating the class."
instance — это экземпляр
Ок, почитаю справку. Мб, улучшу стиль своего js-кода, ибо многие поля хотелось сделать приватными
этот тред делает меня грустной пандой. я хочу дожить до тех времён, когда людей, утверждающих что инкапсуляция — это квалификатор private, будут линчевать на глазах у ликующей толпы
свойство объекта быть чёрным ящиком же
да, вот это верно
спасибо [табличка: сарказм]
не за что. если что, единственным ключевым аспектом ООП является ad-hoc полиморфизм, всё остальное варьируется: вместо классов может быть прототипная система (Io, Self), вместо наследования может быть делегирование (Snit), вместо вызовов методов может быть отправка сообщений (Smalltalk, Erlang), вместо виртуальных функций может быть паттерн Visitor (Haskell, F#). и, вообще говоря, наиболее кривая реализация ООП как раз в C++ (ну и PHP), объектная модель JS вполне себе консистентна [табличка: недовольство, свирепость, но в то же время грусть и недоумение]
Ну тогда уж и полиморфизм необязателен. Это всё в теории.
На практике бессмыссленно использовать ООП без инкапсуляции и наследования с полиморфизмом.
Впрочем, спорить с ФП-фагом я не буду. ФП накладывает неизгладимый отпечаток...
нет, без ad-hoc полиморфизма не будет позднего связывания, и не будет возмозможности трактовать объекты как чёрные ящики. я не буду отвечать на выпады ad hominem. удачи тебе и побольше практики — особенно той, в которой нет разницы между объектами и экземплярами классов, а так же полиморфизм необязателен для реализации ООП
#hsifo/8 — это по сабжу
Ну и как ты себе представляешь чёрный ящик без инкапсуляции? Это уже не черный ящик, а серый или даже прозрачный.
в случае использования позднего связывания, ты (в статике) не знаешь, к объекту какого типа ты обращаешься по некоторому интерфейсу — и, соответственно, ничего не можешь сказать о его внутреннем устройстве. в Erlang, например, ты фиксируешь только структуру сообщения, по которой и будет выполнена диспетчеризация — а как будет выглядеть обрабатывающий объект (и не будет ли он меняться в процессе работы приложения), ты не знаешь
Неизгладимый отпечаток широкого взгляда на мир и образованности
В рамках твоего примитивного мирка можно привести такой пример:
struct A {
Integer a;
A(Integer _a) { a = _a; }
Integer getA() { return a; }
}
interface IA {
Integer getA();
}
…
IA ia = new A(10);
Тогда работа с ia a priori скрывает внутреннее содержимое A несмотря на то, что оно не инкапсулировано.