LINUX.ORG.RU

В чём суть ООП?


3

5

С точки зрения манеры проектирования, а не особенностей реализации С++ там CLOS. Вот например я использую определения классов и даже иногда наследование как узнать пишу ли я в ООП стиле?

★★★★★

Ответ на: комментарий от drBatty

Не уводи обсуждение в сторону - против буферизации ещё никто не выступал.

Но-но-но. Ты сказал, что ООП для ввода/вывода ВООБЩЕ не нужно и бесполезно.

Dudraug ★★★★★ ()
Ответ на: комментарий от drBatty

Ах да. Проверка ошибки чтения... Как ты сделаешь ее через scanf?

Расскажи давай. Потом когда расскажешь сравни с тем, как это делается в Си++ и почувствуй разницу.

Dudraug ★★★★★ ()
Ответ на: комментарий от LamerOk

Все трое не имеют прямого отношения к модели ООП.

GObject с GObjectIntrospection не имеют? Классы есть, наследование есть, сигналы есть. Про Java и Objective-C - это больше относительно их графических библиотек, которые вполне ОО.

А если не забывать, то нужно ещё вспомнить крякающе прототипное ООП ECMAScripta.

то скорее Erlang и микроядра

Конкурентность и распределённость шире чем ООП - в некоторых случаях похоже, но и только.

quasimoto ★★★★ ()
Ответ на: комментарий от son_of_a_gun

С каких пор объекты в C++ получили собственные методы? Походу ты и представление о С++ не имеешь...

что, думаешь у объектов в C++ нет методов? ВНЕЗАПНО: они там были изначально. Мало того, нестатические методы вообще смысла не имеют в отрыве от объектов. Без объекта можно использовать только статические методы, но мы не о них. Подучи матчасть пожалуйста.

drBatty ★★ ()
Ответ на: комментарий от drBatty

Методы определяются для класса. Для конкретного объекта С++ их не определяет.

son_of_a_gun ()
Ответ на: комментарий от drBatty

Инкапсуляция там есть. У нас есть методы работы с FILE - fopen/fgetc/fprintf/fscanf/fclose. Нам не нужно трогать struct FILE. Более того нам это не нужно! Вся работа с ним осуществляется через интерфейс. Доступ к полям FILE -это хак. Хаки мы не считаем за нормальное использование. FILE полностью защищен! Все возможные операции с ним доступны через интерфейсы. Пойми ты уже наконец, что инкапсуляция это не private/public. Ты не понимаешь ООП! А полиморфизм в данном случае, как и наследование не нужны.

ООП не утверждает, что каждый объект должен отвечать этим трем требованиям. Ты опять же не понимаешь ООП.

Dudraug ★★★★★ ()
Ответ на: комментарий от drBatty

Без объекта можно использовать только статические методы, но мы не о них.

Ну если говорить о Си++ то можно вполне себе вызвать.

((Object *) NULL).funct();

Dudraug ★★★★★ ()
Ответ на: комментарий от drBatty

Дошли уже до того, что у нас FILE это ООП...

Это ты упоротый и не хочешь признать себя проигравшим.

Dudraug ★★★★★ ()
Ответ на: комментарий от drBatty

А ostream::operator<<() это _как_ выводить?

Я уже говорил, что не ostream::operator<<, а operator<<(ostream&, T).

cout.operator<<()

RTFM.

Begemoth ★★★★★ ()
Ответ на: комментарий от son_of_a_gun
 From: Alan Kay <alank@wdi.disney.com>
 Date: 1998-10-10 07:39:40 +0200
 To: squeak@cs.uiuc.edu
 Subject: Re: prototypes vs classes was: Re: Sun's HotSpot


 Folks --


 Just a gentle reminder that I took some pains at the last OOPSLA to try to
 remind everyone that Smalltalk is not only NOT its syntax or the class
 library, it is not even about classes. I'm sorry that I long ago coined the
 term "objects" for this topic because it gets many people to focus on the
 lesser idea.


 The big idea is "messaging" - that is what the kernal of Smalltalk/Squeak
 is all about ...

http://c2.com/cgi/wiki?AlanKayOnMessaging

LamerOk ★★★★★ ()
Ответ на: комментарий от Dudraug

А полиморфизм в данном случае, как и наследование не нужны.

Необязательны, FILE может представлять не только поток, связанный с файлом, но и с буфером в памяти.

Begemoth ★★★★★ ()
Ответ на: комментарий от son_of_a_gun

Да? Тогда, походу, ты не знаешь что это значит.

а... Значит «drBatty не знает C++» отменяется, теперь выходит «drBatty знает C++, но не понимает!». Так?

Что мешает сделать свой метод, принимающий формат и ссылку на ostream?

ничего не мешает. Кроме того, что это будет уже не ostream и не ООП.

Фишка ООП в том и состоит, что fopen открывает _только_ FILE, а fclose закрывает _только_ его же. Если-бы FILE был классом, то мы могли-бы сделать свой FILE, причём fopen и fclose с ним-бы прекрасно работали. Но... Не судьба.

drBatty ★★ ()
Ответ на: комментарий от Dudraug

Не уводи обсуждение в сторону - против буферизации ещё никто не выступал.

Но-но-но. Ты сказал, что ООП для ввода/вывода ВООБЩЕ не нужно и бесполезно.

ООП нужно для буферизации?

drBatty ★★ ()
Ответ на: комментарий от drBatty

ВООБЩЕ

вообще для ostream не нужно ООП. «ВООБЩЕ» это уж на лоре додумали...

drBatty ★★ ()
Ответ на: комментарий от drBatty

ООП нужно для буферизации?

А для чего нужно не ООП? Чем оно лучше?=)

Dudraug ★★★★★ ()
Ответ на: комментарий от Dudraug

Ах да. Проверка ошибки чтения... Как ты сделаешь ее через scanf? Расскажи давай. Потом когда расскажешь сравни с тем, как это делается в Си++ и почувствуй разницу.

расскажи, как она сделана в istream, и в чём разница?

drBatty ★★ ()
Ответ на: комментарий от drBatty

а... Значит «drBatty не знает C++» отменяется, теперь выходит «drBatty знает C++, но не понимает!». Так?

Там написано что «ты не знаешь», одно другому не мешает, но не суть. Смысл сводится к твоим словам, что operator<< не универсален, а применим только для cout. Это не так.

ничего не мешает. Кроме того, что это будет уже не ostream и не ООП.

ostream& T::out(ostream&, FormatType format);
son_of_a_gun ()
Ответ на: комментарий от drBatty

Ты нам 3 день доказываешь, что для i/o ООП не нужно. Раз ты так упорен, то значит считаешь, что ВООБЩЕ. Или уже не считаешь?

Dudraug ★★★★★ ()
Ответ на: комментарий от drBatty

Лучше ты напиши как она сделана и ощути разницу.

Dudraug ★★★★★ ()
Ответ на: комментарий от drBatty

ООП нужно для буферизации?

Ты прикидываешься? То, что потоки могут выводить данные, в файл, в память, в никуда, сжимать, и т.д. ты просто исключаешь? В libc как минимум есть потоки для вывода в файл и в память.

Begemoth ★★★★★ ()
Ответ на: комментарий от son_of_a_gun

Методы определяются для класса. Для конкретного объекта С++ их не определяет.

методы вызываются для объекта. Обычные методы без объекта не вызвать. Если ты не понял, мы сейчас обсуждаем вызов методов вроде cout.operator<<(), а не детали их определения.

drBatty ★★ ()
Ответ на: комментарий от drBatty

вообще для ostream не нужно ООП. «ВООБЩЕ» это уж на лоре додумали.

да ладно

ostream_iterator<T>(ostream, delim);
copy(collection.begin(), collection.end(), ostream_iterator<int>(cout, "<>"));
Довольно таки удобно

Boy_from_Jungle ★★★★ ()
Ответ на: комментарий от drBatty

Обычные методы без объекта не вызвать

вызвать-вызвать, статические методы вызываются для класса -)

Boy_from_Jungle ★★★★ ()
Ответ на: комментарий от Boy_from_Jungle

Не, не, ключевой аспект ООП - динамический полиморфизм, а то мы так придём к тому, что шаблоны С++ - тоже ОО язык.

Begemoth ★★★★★ ()
Ответ на: комментарий от quasimoto

GObject ... Про Java и Objective-C - это больше относительно их графических библиотек

В этом смысле - да, вполне ОО. Но это не языки как таковые, а библиотеки, доступные из этих языков.

LamerOk ★★★★★ ()
Ответ на: комментарий от drBatty

Я к тому, что нужно говорить о ostream, а не конкретно о cout.

cout.operator<<()

Нет такого оператора/метода. Есть T::operator<<(ostream&).

son_of_a_gun ()
Ответ на: комментарий от Dudraug

Инкапсуляция там есть. У нас есть методы работы с FILE - fopen/fgetc/fprintf/fscanf/fclose. Нам не нужно трогать struct FILE.

не нужно трогать

нам это не нужно!

а... ну если ты ЭТО называешь «инкапсуляцией»... Тогда с тобой всё ясно. А я называю инкапсуляцией X ситуацию, когда клиенту даже в голову не придёт трогать этот X, хотя-бы потому, что он про него даже не знает. Вот это - инкапсуляция, а не твоё «не нужно».

Доступ к полям FILE -это хак. Хаки мы не считаем за нормальное использование. FILE полностью защищен!

это называется «защита на честном слове», клиент дал тебе своё честное-пионерское слово, что он не будет смотреть на твой FILE. НИКОГДА!!!11один-один (:

Самому не смешно?

Все возможные операции с ним доступны через интерфейсы.

а где полиморфизм? где возможность использовать данный интерфейс со своими файлами, которые чем-то отличаются от твоих? Нет такой возможности.

Пойми ты уже наконец, что инкапсуляция это не private/public.

нет, это ты пойми. Я и так это знаю. private/protected это не инкапсуляция, это костыль, который в т.ч. обеспечивает инкапсуляцию.

и наследование не нужны.

наследование - тоже костыль, который реализует ООП в C. (и за счёт наследования, из C получается C++)

ООП не утверждает, что каждый объект должен отвечать этим трем требованиям. Ты опять же не понимаешь ООП.

тогда расскажи нам, что твоё ООП утверждает?

drBatty ★★ ()
Ответ на: комментарий от Dudraug

можно вполне себе вызвать. ((Object *) NULL).funct();

может попробуешь?

drBatty ★★ ()
Ответ на: комментарий от drBatty

а... ну если ты ЭТО называешь «инкапсуляцией»... Тогда с тобой всё ясно. А я называю инкапсуляцией X ситуацию, когда клиенту даже в голову не придёт трогать этот X, хотя-бы потому, что он про него даже не знает. Вот это - инкапсуляция, а не твоё «не нужно».

Вот именно ты ничего не понимаешь в ООП просто. Инкапсуляция с private/public это средства языка организующие инкапсуляцию на уровне языка. Но это не есть сама суть инкапсуляции, это не инкапсуляция.

Dudraug ★★★★★ ()
Ответ на: комментарий от drBatty

Попробую, и оно даже работает. Если метод funct не обращается к реальным полям объекта.

Dudraug ★★★★★ ()
Ответ на: комментарий от Begemoth

Я уже говорил, что не ostream::operator<<, а operator<<(ostream&, T).

какая разница, как operator<< перезагружать, в контексте нашего спора?

drBatty ★★ ()
Ответ на: комментарий от drBatty

Самому не смешно?

При чем тут клиент? Тут есть программист. Который должен осознавать, что как надо или не надо делать. Использование полей структуры содержимое которой не документировано, а использование по доке возможно только через интерефейсы - это хак. Через хаки вообще можно очень многое сделать, ооочень многое. Но хак - это не нормальный способ работы. Хак это хак.

Dudraug ★★★★★ ()
Ответ на: комментарий от son_of_a_gun

Есть T::operator<<(ostream&).

Ну как он будет использоваться? std::declval<T>() << std::declval<ostream>(), а надо, чтобы операнды были в обратном порядке.

Begemoth ★★★★★ ()
Ответ на: комментарий от Dudraug

А для чего нужно не ООП? Чем оно лучше?

время экономится. Выше я уже давал пример с коллекцией, которая без изменений может работать с новыми элементами. С FILE так не получается очевидно...

drBatty ★★ ()
Ответ на: комментарий от son_of_a_gun

Там написано что «ты не знаешь», одно другому не мешает, но не суть. Смысл сводится к твоим словам, что operator<< не универсален, а применим только для cout. Это не так.

этот оператор применим только для ostream&, например для cout. И всё. Не для какого иного типа, кроме типа ostream& данный оператор не применим.

drBatty ★★ ()
Ответ на: комментарий от drBatty

тогда расскажи нам, что твоё ООП утверждает?

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

Dudraug ★★★★★ ()
Ответ на: комментарий от drBatty

Разница в том, что мой вариант расширяется для новых типов данных.

Begemoth ★★★★★ ()
Ответ на: комментарий от drBatty

Ты мне лучше прямо сейчас напечатай обработку ошибок чтения из файла для ООП и для не ООП (scanf). Или уже сам осознал разницу? Тогда можно не печатать, да.

Dudraug ★★★★★ ()
Ответ на: комментарий от Dudraug

Ты нам 3 день доказываешь, что для i/o ООП не нужно. Раз ты так упорен, то значит считаешь, что ВООБЩЕ. Или уже не считаешь?

если ты ещё не понял, то повторяю: я считаю, что ООП ненужно для потоков i/o вроде iostream. Или скажем FILE. А вообще для i/o - ничего я не считаю, т.к. i/o бывает РАЗНОЕ, как и задачи.

drBatty ★★ ()
Ответ на: комментарий от Begemoth

Ты прикидываешься? То, что потоки могут выводить данные, в файл, в память, в никуда, сжимать, и т.д. ты просто исключаешь? В libc как минимум есть потоки для вывода в файл и в память.

пусть они выводят что угодно, и _куда_ угодно. Вывод определённого типа данных никак к этому не относится. Особенно форматированный. Код, который выводит дробные числа должен знать, что это за числа, и как они представлены. Потому этот код должен быть прибит к этим дробным числам. А не к ostream, как вы здесь предлагаете. Именно по этой причине запись x->output() кошерная, а запись operator(ostream &cout, x) - некошерная.

drBatty ★★ ()
Ответ на: комментарий от drBatty

А не к ostream, как вы здесь предлагаете

Врать перестань, внимательный ты наш.

Begemoth ★★★★★ ()
Ответ на: комментарий от Boy_from_Jungle

вызвать-вызвать, статические методы вызываются для класса -)

выше уже сказано, что «обычные» в C++ являются НЕ статическими. Перед статическими ещё static писать надо. Так то.

drBatty ★★ ()
Ответ на: комментарий от son_of_a_gun

Главное что операцию определяет не ostream, а T.

Тогда надо вынести оператор из класса T и при необходимости сделать его другом. Учитывая ADL, этот оператор будет частью интерфейса класса T.

Begemoth ★★★★★ ()
Ответ на: комментарий от drBatty

Только не надо акцентировать внимание на моей ошибке - важно что оператор для конкретного T определяется не в ostream, и что он работает для всех ostream а не только для cout.

son_of_a_gun ()
Ответ на: комментарий от Dudraug

(maybe you meant to use «->» ?)

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

drBatty ★★ ()
Ответ на: комментарий от Dudraug

При чем тут клиент? Тут есть программист.

тут как минимум два программиста - один писал FILE и прочие fopen, а второй это использует. Вот второго я и назвал для краткости «клиентом».

Но хак - это не нормальный способ работы. Хак это хак.

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

drBatty ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.