LINUX.ORG.RU

Решение отдельных задач с использованием объектно-ориентированных возможностей языка

 


0

0

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

Приблизительный список таких видов ПО:

  • программы по вопросу моделирования;
  • приложения с графическим интерфейсом пользователя (GUI);
  • сложные программные продукты, которые разрабатываются большой командой специалистов.

Какие дополнительные виды ПО можно добавить к указанному списку?

Deleted

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

Так этот пункт буквально все и покрывает.

d_Artagnan ★★
()
  • Компьютерные игры (можно отнести к моделированию).

Обычно с ООП, но чаще на С, так что без средств из состава языка:

  • Компиляторы и интерпретаторы.
  • Ядро ОС.

сложные программные продукты, которые разрабатываются большой командой специалистов

ИМХО не критерий, есть много сложных открытых проектов на C.

gv
()

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

Кем применяются? Когда применяются?

Какие дополнительные виды ПО можно добавить к указанному списку?

Можно - любые.

schizoid ★★★
()

приложения с графическим интерфейсом пользователя (GUI);

ООП здесь как пятая нога для слона

программы по вопросу моделирования;

а это что вообще такое?

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

Обычно с ООП, но чаще на С

Компиляторы и интерпретаторы

можно пример объектно-ориентированного компилятора на С?

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

ООП здесь как пятая нога для слона

видел я этот ваш гуй в функциональном стиле

а это что вообще такое?

видимо пересказ фразы «модель предметной области»

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

видел я этот ваш гуй в функциональном стиле

это ложная дихотомия. хотя даже функциональный гуй лучше объектно-ориентированного

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

пример объектно-ориентированного компилятора

Это компилятор, который создан с использованием ООП, что ли?

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

Это компилятор, который создан с использованием ООП, что ли?

это компилятор, при создании которого были применены объектно-ориентированные средства. не из состава языка C, поскольку их там нет

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

это компилятор, при создании которого были применены объектно-ориентированные средства

Например, редактор, написанный с применением ООП, не?

не из состава языка C, поскольку их там нет

Глупо пользоваться только лишь тем, что разрешено прямо.

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

Например, редактор

компилятор

разницу улавливаешь?

Глупо пользоваться только лишь тем, что разрешено прямо.

философские размышления не по теме лично мне не очень интересны. gv написал с ООП, но чаще на С, этот случай я и хотел бы обсудить

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

разницу улавливаешь?
объектно-ориентированные средства

Вот это - это что такое? Средства, применяемые при разработке, включают и инструменты типа редакторов. Или ты что-то другое имел в виду?

философские размышления не по теме лично мне не очень интересны

Если для тебя выбор инструмента для работы - это философские размышления, мне жаль тебя и твоего работодателя.

Если ты программист, конечно, а не менеджер какой-нибудь.

gv написал с ООП, но чаще на С, этот случай я и хотел бы обсудить

Предлагаю тебе философски поразмышлять, чем GObject+C в твоём сознанании не является ООП на C. Можно вслух.

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

можно пример объектно-ориентированного компилятора на С?

Именно так - нет, не знаю :)

ООП на C ведь растяжимое понятие. Я имею в виду, например, VFS в ядре и реализацию Tcl и Python. Из исходников компиляторов я смотрел только AST в clang, там ООП, но C++.

gv
()
Ответ на: комментарий от schizoid

Вот это - это что такое? Средства, применяемые при разработке, включают и инструменты типа редакторов. Или ты что-то другое имел в виду?

Не, речь о компиляторе, который написан на pure C, но написан в объектно-ориентированном стиле, например вручную реализованы полиморфизм или наследование. В каком редакторе писали код - не важно :)

gv
()
Ответ на: комментарий от schizoid

Или ты что-то другое имел в виду?

забей

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

Именно так - нет, не знаю :)

жаль. было бы интересно посмотреть

реализацию Tcl

объекты там есть, но вот с ООП (в смысле позднего связывания) как-то не очень

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

приложения с графическим интерфейсом пользователя (GUI);

ООП здесь как пятая нога для слона

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

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

например Tcl_ObjType

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

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

ООП здесь как пятая нога для слона

Но ведь это чушь. Все популярные GUI-тулкиты являются объектно-ориентированными, а эффективный чистый ФП-тулкит невозможен.

даже функциональный гуй лучше объектно-ориентированного

Что значит «функциональный гуй»? Это который использует монадические обёртки над ООП-тулкитами? Но ведь он использует костыли для того, чтобы состыковать чуждые парадигмы. Чем он лучше ООП-гуя, написанного без костылей?

anonymous
()

ziemin

гугли преимущества ООП

ООП дает возможность создавать расширяемые системы (extensible systems). Это одно из самых значительных достоинств ООП и именно оно отличает данный подход от традиционных методов программирования. Расширяемость (extensibility) означает, что существующую систему можно заставить работать с новыми компонентами, причем без внесения в нее каких-либо изменений. Компоненты могут быть добавлены на этапе выполнения.

Добавляю к списку:

  • сложные программные продукты, которые разрабатываются большой командой специалистов, в том числе модульное и расширяемое программное обеспечение;
  • библиотеки классов, фреймворки.

Излишняя универсальность. Неэффективность может также означать, что программа имеет ненужные возможности. В библиотечном классе часто содержится больше методов, чем это реально необходимо. А поскольку лишние методы не могут быть удалены, то они становятся мертвым грузом. Это не воздействует на время выполнения, но влияет на возрастание размера кода.

Одна из причин раздувания программного обеспечения.

Deleted
()
Ответ на: комментарий от jtootf

И да, приведите пример «функционального гуя» с доказательством того, что он лучше объектно-ориентированного.

anonymous
()

По теме. На сегодняшний день ООП — это парадигма, которая лучше всего (по совокупности различных метрик) справляется с задачами разработки ПО в совершенно разных областях. Это — ОС, СУБД, серверы приложений, веб-серверы, почтовые и IM-серверы, оптимизирующие компиляторы, среды разработки, embedded софт, desktop софт, вебсайты, enterprise-системы, middleware, telecom, CAD, CAM, CASE, SCADA, high-performance вычисления, игры и так далее. ООП оказалось удачной и гибкой парадигмой, способной справляться с решением задач во всех вышеперечисленных областях, отсюда и индустриальный успех.

Другие парадигмы, например, ФП, оказались неудачными и непригодными для эффективного решения большинства вышеперечисленных задач, как следствие — фиаско в промышленности.

anonymous
()
Ответ на: комментарий от gv

когда X-сервер посылает событие окну, а то его как-то обрабатывает, и каждое окно по-своему — реализацией полиморфизма

хороший вопрос. с точки зрения определения товарища Кея - несомненно; но в исходном сообщении я имел в виду то ООП, о котором писали GoF

пример GUI без ООП

например. WPF, QML, HTML5, Phooey - шаги в правильном направлении. Reactive (если бы его разработку довели-таки до конца) был бы отличным событийным фреймворком для декларативного GUI

jtootf ★★★★★
()

Обновленный список видов ПО

  • программы для компьютерного моделирования;
  • приложения с графическим интерфейсом пользователя (GUI);
  • сложные программные продукты, которые разрабатываются большой командой специалистов;
  • модульное и расширяемое программное обеспечение;
  • библиотеки классов, фреймворки.
Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от anonymous

Другие парадигмы, например, ФП, оказались неудачными и непригодными для эффективного решения большинства вышеперечисленных задач, как следствие — фиаско в промышленности.

анонимус не тупи.

anonymous
()
Ответ на: комментарий от jtootf

например. WPF, QML, HTML5

Ещё Glade/GtkBuilder. Но ведь всё это стало возможным исключительно благодаря ООП-подложке: C# в случае WPF, Qt/C++ в случае QML, Gecko/WebKit/etc. в случае HTML5.

Phooey - шаги в правильном направлении. Reactive (если бы его разработку довели-таки до конца)

Полторы полудохлые поделки. Одним словом — маргинальщина at its best.

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

анонимус не тупи.

Что не так?

anonymous
()
Ответ на: комментарий от jtootf

сам с собой ты можешь и самостоятельно побеседовать, без моей помощи

Т.е. ты ляпнул нечто («функциональный гуй лучше объектно-ориентированного гуя»), но обосновать это не можешь?

anonymous
()
Ответ на: Обновленный список видов ПО от Deleted

Третий пункт неможко отдаёт борхесовской классификацией животных, ведь это характеристика по другому измерению.

Я бы добавил «ПО уровня предприятия» (тот самый «enterpriZe», от которого у местных маргинальщиков резкая попоболь). Этот класс ПО обычно оперирует большим количеством сущностей (тысячи), большинство из которых персистентны (сохраняются в РСУБД транзактным образом), состоят из большого числа слабосвязанных модулей и интегрируются с внешними системами.

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

Но ведь всё это стало возможным исключительно благодаря ООП-подложке

не вижу противоречий

Полторы полудохлые поделки

модель распространения событий в Rx Framework близка к оной в Reactive. вопрос не в распространённости, а в качестве решений: перенос удачного решения на популярную платформу - вопрос времени

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

перенос удачного решения на популярную платформу - вопрос времени

Лисперы тоже этим всех лечат. Уже 50 лет. Вот как перенесут — так и посмотрим.

вопрос не в распространённости, а в качестве решений

Почему reactive — более качественное решение, чем ООП-гуй? Докажите это.

anonymous
()
Ответ на: комментарий от jtootf

считай, что я слился

Okay.

не тупи

И? С каких это пор adoption by Micro$oft у нас считается показателем качества?

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

Почему reactive — более качественное решение, чем ООП-гуй? Докажите это.

А чего доказывать-то, или по вашему неявное лучше явного? В frp видно какие сигналы и куда передаются, в ооп-гуе равиоли проявляются в худшем смысле.

anonymous
()

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

Тут ещё дополнительное условие: программный продукт использует библиотеки и скорее всего не применяется во встраиваемых системах. Дабы устранить возражения про всем известное ядро.

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

но в исходном сообщении я имел в виду то ООП, о котором писали GoF

Гуф писали про паттерны. Сводить всё ООП к паттернам несерьёзно, это лишь шаблоны для написания логики программы в ООП стиле. Разумеется, паттерны для кодирования логики при декларативном задании GUI бесполезны.

например. WPF, QML, HTML5, Phooey - шаги в правильном направлении. Reactive (если бы его разработку довели-таки до конца) был бы отличным событийным фреймворком для декларативного GUI

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

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

пример GUI без ООП

например. WPF, QML, HTML5, Phooey - шаги в правильном направлении. Reactive (если бы его разработку довели-таки до конца) был бы отличным событийным фреймворком для декларативного GUI

WPF без ООП? Ты серьезно?

Нет, конечно, я как-то экспериментировал. Писал на F#, используя приемы так называемого «реактивного функционального программирования» (у Томаша Петричека научился), когда подписываешь обработчик события через Async.Await, а само событие - это уже IObservable<_> (то ли это монада, то ли почти монада - там могут нарушаться законы; особо не задумывался). И большая часть кода становится неким вычислением (асинхронным). Даже не поймешь, на что это было у меня больше похоже, то ли на ФП, то ли на ООП, то ли на совершенно дикий гибрид. Причем, сделал простенький прототип редактора диаграмм на WPF, и это даже работало.

Но, в самом WPF всюду ООП. Я не говорю о xaml, я говорю о фреймворке.

dave ★★★★★
()

любые, где характерно присутствие множества типов данных, работа с которыми простым структурным программированием с использованием всего лишь примитивных типов (int, float и их разновидности) рождает спагетти-код (не знаю, как выразить точно. имеется в виду большое количество одинаковых/похожих строк кода)

например, банально проще воспринимается

Vector2 position (0, 0);
Vector2 speed (2.4, 2.2);
Vector2 next_position = position + speed;

Нежели запрогивание структуры, функции для инициализации (или ручной инициализации, или упаси макросов) и функций типа vector_add(Vector2 v1, Vector2 v2), хотя это всего лишь синтактический сахар по большому счёту. Но многим людям гораздо проще программировать и читать код.

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

Экзамены на носу штоле? :)

Может дисер пишет? Даже в топике язык в своеобразном стиле выдержан.

ak377630
()

Приблизительный список таких видов ПО:

- софт написанный на Python, Ruby, C#, Java, прочие языки, на которых нельзя писать без использования ООП.

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