Войти
ФлеймФорумПрограммирование

Вопрос по ООП

Страницы: 1 2 316 17 Следующая »
#0
(Правка: 3:42) 3:37, 16 дек. 2019

Например создаем некий объект на языке программирования с поддержкой синтаксиса ООП , например на JS:

var Foo = new Object();
Foo.field1 = 'anytext',
Foo.method = function(){ ... }

получаем:

  Foo.field1 // 'anytext'
  Foo.method // function

Теперь предположим у нас есть чисто процедурный язык программирования noname в котором в имени переменных разрешено использовать символ точки "."
То есть, написание имени переменной как my_var так и my.var эквивалентно, валидно и является обращением не к полям и методам, а как к обычной переменной.

Пример кода на noname:

var  Foo.field1 = 'anytext';
var  Foo.method = function(){...};

получаем тот же результат как и на JS:

  Foo.field1 // 'anytext'
  Foo.method // function


А теперь собственно вопрос: Является ли пример этого кода на языке noname объектно-ориентированным, хотя сам язык noname изначально строго процедурный?


#1
5:36, 16 дек. 2019

NetSpider
> Является ли пример этого кода на языке noname объектно-ориентированным, хотя
> сам язык noname изначально строго процедурный?
Нет, не является. Причем на JS тоже не является.

#2
(Правка: 7:34) 6:53, 16 дек. 2019

var Foo = new Object(); // Это не объектно-ориентированное программирование по версии youtube

Хорошо, я вас понял, ваш ответ принят. Жду еще интересных мнений

#3
7:38, 16 дек. 2019

NetSpider

Объектно-ориентированное это НЕ когда у структур появляются внедрённые в них методы. Сам такой синтаксис это лишь синтаксический сахар в рамках ООП, но не сам ООП.

В обычном процедурном и модульном программировании при наличии структур есть совершенно обычная идиома (не являющаяся ООП!) когда мы выделяем в отдельный модуль некую структуру и процедуры с ней работающие.
Например:

FILE *f = fopen( "name.txt", "rb" ); // FILE это "интересная структура"
fread( f, ... ); // и куча функций принимающих указатель на неё
fclose( f ); // и делающих самые разные вещи с ней
Файлы немного тут неудачный пример по причине которую я даже не буду упоминать чтобы не замыливать повествование. Этот подход в рамках процедурщины очень прагматичен - он замыкает некую сущность в некоем модуле - если нужно поправить работу с ней нужно сконцентрировать своё внимание только на его тексте. Если внешний код не лезет внутрь структуры, а работает с ней только через функции, то его автоматически перестаёт интересовать внутреннее содержание и при его изменении не надо переписывать внешний код - т.е. мы получаем инкапсуляцию и это действительно так с FILE - на любых операционках клиентский код не волнует что там скрыто внутри fopen - CreateFile, open или еще какая то срань - и таким образом мы получаем идиому:
Чётко выделяем код работающий с известной сущностью.
Эта идиома не является ООП, однако. Ни капли. Это простой и очень понятный прагматичный подход из процедурного программирования со структурами. Он так же часто встречается в виде когда идентификаторами объектов являются не указатели, а некие хендлы - но так или иначе библиотечный код через хендлы выходит на структуры.
Поэтому если мы добавим сюда синтаксического сахара и вместо:
fopen( f, ... );
fread( f, ... );
fclose( f );
будем писать:
f.open( ... );
f.read( ... );
f.close();
то... ничего по существу не изменится (но сразу обозначаю, что методы open/read/close не должны быть виртуальными для полной эквивалентности).
Т.е. по крайней мере на С++ код без виртуальных функций на объектах всегда эквивалентен коду на свободных функциях принимающих в качестве первого параметра указатель на структуру - эта эквивалентность даже формально закреплена в сущности неявного параметра this.

Т.е. главный вывод из всего этого - далеко не всякий код с каким то классом и методами у него является ООП-нутым. В очень многих случаях это просто посыпанная синтаксическим сахаром процедурная идиома "выделяем код работающий с известной сущностью".

ООП начинается когда эта идиома немножечко модифицируется. Буквально на две буквы: "выделяем код работающий с неизвестной сущностью".

#4
(Правка: 7:58) 7:51, 16 дек. 2019
Объектно-ориентированное это НЕ когда у структур появляются внедрённые в них методы

Разве  все усилия ООП не направлены на то что бы после Сreate появился объект как структура полей с методами?

Т.е. главный вывод из всего этого - далеко не всякий код с каким то классом и методами у него
является ООП-нутым

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

#5
8:04, 16 дек. 2019

NetSpider

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

Объект в смысле ООП появляется когда мы вводим еще один слой изоляции между клиентским кодом и тем с чем он работает - динамическую диспетчеризацию.
ООП-нутый код характерен тем, что он, например, в рамках графического редактора естественно может обойти некий контейнер объектов и вызвать у них метод "отрисуйся" и объекты отрисуются, но... каждый по своему. Контейнер один, сущности в нём лежащие выглядят для клиентского кода одинаково (один и тот же набор методов), но ведут себя по разному потому что являются разными сущностями.
Еще раз внимание на краткое выражение идиомы ООП: "выделяем код работающий с неизвестной сущностью". В процедурном стиле так не получится. Потому что FILE это FILE и функции по работе с FILE * умеют работать только с FILE *. В этом и есть сила и преимущество объектно-ориентированной идиомы.

#6
(Правка: 8:21) 8:13, 16 дек. 2019

=A=L=X=

Что-то мне совершенно тяжело. Вы теперь утверждаете что один объект это не ООП, потому что он один, а вот когда их пачка, то они могут иметь различное внутреннее состояние, и тем самым это триггер по которому мы можем сказать что это ООП.

Аналогично, что объявив массив длиной 1, это не тип массив, а вот более, это массив:
var arr = [1]; // не массив;
var arr = [1,2]; // массив

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

#7
8:16, 16 дек. 2019

Педивикия:

Объе́ктно-ориенти́рованное программи́рование (ООП) — методология программирования,
основанная на представлении программы в виде совокупности объектов,
каждый из которых является экземпляром определённого класса,
а классы образуют иерархию наследования. 
И не нужно ничего придумывать.

#8
(Правка: 8:28) 8:24, 16 дек. 2019

nes

Это относится к ООП программированию, или нет?

var Foo = new Object(); 

Я из цитаты из педивикии понял что не является.

Тогда почему объект есть, а ООП нет.
Теперь триггер это наличие в коде классов.

#9
8:27, 16 дек. 2019

NetSpider
>Это относится к ООП программированию, или нет?
Посредственно, все зависит от того, что такое Object в данном контексте.

#10
8:27, 16 дек. 2019

NetSpider
Путаете мягкое с теплым, идиома, как выше написал Алекс, это одно,
а синтаксис - другое.

#11
(Правка: 8:31) 8:30, 16 дек. 2019

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

#12
(Правка: 8:50) 8:48, 16 дек. 2019

NetSpider
> один объект это не ООП

Нет, дело не в количестве, а в качестве.
Один объект может быть ООП если от клиентского кода всё-таки спрятано чем он конкретно является и выбор возможен в рантайме (динамическая диспетчеризация).
Например некоторые движки, особенно прошлого, могли поменять рендер на лету - с OpenGL перейти на Direct3D и обратно - в таких движках зачастую рендерер и был таким полиморфным единственным, но ООП-нутым объектом.
Главное в ООП - это полиморфизм. Инкапсуляция же, как выше было показано вообще является просто междисциплинарной хорошей практикой, а наследование - это деталь реализации конкретных языков программирования. В JavaScript, например, нечто аналогичное наследованию есть но работает совсем иначе, нежели в С++, и это никакой роли не играет.

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

#13
(Правка: 9:48) 9:46, 16 дек. 2019

=A=L=X=

Один объект может быть ООП если от клиентского кода всё-таки спрятано чем он конкретно является и выбор возможен в рантайме (динамическая диспетчеризация).

Функция тоже прячет внутренний код, имеет недоступные локальные переменные и даже объявление других функций (инкапсуляция) Наружу торчат только параметры и возвращаемый результат. Можно утверждать что по сути это и есть экземпляр объекта с единственным методом. Кстати разработчики JavaScript это сразу поняли и вообще так и сделали: фукция в JS это и есть класс

Главное в ООП - это полиморфизм.

Вики:

Полиморфизм в языках программирования и теории типов — способность функции обрабатывать данные разных типов

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

#14
(Правка: 9:49) 9:48, 16 дек. 2019

Безотносительно того, ООП или нет:

NetSpider
> Пример кода на noname:
>
> var Foo.field1 = 'anytext';
> var Foo.method = function(){...};
>
> получаем тот же результат как и на JS:
>
> Foo.field1 // 'anytext'
> Foo.method // function

А теперь делаем вот так:

var Bar = Foo;

Bar.field1 // ???
Bar.method // ???

Страницы: 1 2 316 17 Следующая »
ФлеймФорумПрограммирование