Аргумент - игры, до появления DirectX были написаны качественнее.
Статья называется "Объектная парадигма провалилась":
Среди языков программирования, которые упоминал автор статьи, не было ни одного модульного языка (Modula, Oberon, Component Pascal, ...). Видимо автор с ними не знаком. Отсюда идет такой детский лепет:
мощные концепции, такие как инкапсуляция, были придуманы для уменьшения ошибок при разработке программ, но инкапсуляция... обременяет, когда меняются глобальные особенности, или когда необходима эволюция программы или, вообще, её коренная перестройка. Концепция открытого исходного кода лучше справляется с подобной ситуацией. Она похожа на модульность — разбиение на составные части так, чтобы люди могли их понять — вот что действительно важно в инкапсулировании
Автору статьи надо просветиться на счет того что такое модульность. Истинная инкапсуляция возможна только на уровне модуля и это всем известно уже несколько десятков лет, а автор, как минимум, преподнес это как свое собственное изобретение. Ему надо поизучать модульные языки.
Oсновное преимущество ООП в том, что позволяет размывать ответственность за готовый продукт. Неоднократно натыкался на это дело на практике...
Это аргумент за или против ООП? Какие игры и что значит "качественнее"?
На мой взгляд обсуждение в том топике движется в сторону открытия того что Microsoft медлительна, так как если она начнёт принимать мизерные решения быстрее чем раз в год, мало не покажется никому.
Против конечно. Игры разные... просто когда смотришь на DirectX поделки, когда одни и те же эффекты используют все игры подряд, становится тошно.
Никтo в здравoм умe сeйчас нe вoзьмётся за бoльшoй прoeкт бeз примeнeния OOП
Ты что? Я наобарот за ООП
Игры хуже, однозначно. Но их больше.
oгда смoтришь на пoдeлки бeз DirectX, тo нe видишь никаких эффeктoв
Вот скажи, можно написать полностью трехмерный симулятор космического боя, с торговлей, апгрейдом кораблей, квестами, переговорами, гигантскими галактиками по несколько десятков тысяч звезд, чтобы это все чудо занимало 100 кбайт ?
?), нo этo нe значит, чтo oни дoлжны такими oставаться. Кружoчeк на рoмбикe сeйчас дажe на мoбильнoм тeлeфoнe нe пoкатит за "вхoд в станцию". Кoрoчe, минимализм ужe давнo нe в мoдe. Ожидания от ООП были единственные - интеграция ПО от разных разработчиков. В этой области сделано очень немного. А именно концепция интерфейса (например IUnknown), что по сути является таблицей с адресами. Практически сделана только таблица и GUID. Остальное является промежуточными, или переходными технологиями. OLE сменилось OCX, затем ActiveX и так далее, это не тянет на системный уровень.
А вот с этим согласен
бред какой. Если говорить про эваолюцию OLE - то это будет так: OLE - набор интерфейсов для создания компонентов, вначале был OLE 1.0 потом OLE 2.0 который переименовали в ActiveX. Потом сделали технологию COM и расширили её в DCOM, Появилась технология MTS которая потом переросла в COM+. А уж ocx - это вообще расширение файла хранящего COM сервера
Насчет интерграции ПО - полная лажа... разные разработчики могут собирать lib'ы или dll'ки для того чтобы другие люди могли бы с ними работать, и экспортировать они будут обычные функции...
А вот про IUnknown лучше почитать в книге которую я описал выше...
Вы ещё в только в тетрис ползали, когда мы критиковали винду за то, что нормальная система интеграции ПО должна соответствовать двум принцыпам: а) управление программой не только для пользователя, но и для программулек пользователя, б) dll должна использоваться не только для экспорта функций, но и для наследования объектов из dll.
Офис ещё не появился а Borland уже реализовывала оба этих принципа.Интересно интересно, когда появился MS Office уже был OLE 1.0 и не думаю что к тому моменту вышел Delphi 1.0, а если для примера брать пункт Б, да он поддерживался в Borland Pascal with Objects 7.0 но о поддержке пункта А ещё и речи небыло.
IUnknown стоит изучать только тому, кому надо участвовать в эволюции ^OLE.
я не понимаю почему я должен радоваться DCOM, а не SOAP?вы можете радоваться чему угодно, обе этих технологии сделаны для работы с удалёнными серверами, MS уже отказывается от DCOM, а .net работает через SOAP.
И пожалуйста не надо личных наездов, OLE и COM это технологии MS ( это насчет фразы кто из MS не вылазит ) , ocx может и не содержать библиотеки типов вообще.
не приписывайте пожалуйста к расширению OCX - то что это какая-то технология.
Цитата:Офис ещё не появился а Borland уже реализовывала оба этих принципа
Интересно интересно, когда появился MS Office уже был OLE 1.0 и не думаю что к тому моменту вышел Delphi 1.0, а если для примера брать пункт Б, да он поддерживался в Borland Pascal with Objects 7.0 но о поддержке пункта А ещё и речи небыло.
Delphi 1.0 у меня появился вместе с Windows3.11, а MS Office без Windows работал? Извини не знал, имел ввиду Office97. А в том старом, тоже VB или там VC++? Как не было поддержки пункта A? Что за фигня - компонентов нельзя было регистрировать? Мне мои метакомпоненты снились что-ли? Да и Рэю Лишнеру? По крайней мере я говорил о системном уровне, на системном уровне нельзя назвать это пунктом A. Не у Delphi 1.0 не у Microsoft Office XP. BPL это для Борланд DLL это для Микрософт, а между собой они не договорились. Единственное о чём договорились это таблица с гуидом. Это система, это да, а остальное промежуточно. То что поддерживает Delphi - это реализация работы с COM для этого языка.
Извините, чего вы хотите изучать? устройство интерфейса или технологию COM которая по сути является следующей вехой в программировании после ООП.
обе этих технологии сделаны для работы с удалёнными серверами
Delphi 1.0 у меня появился вместе с Windows3.11, а MS Office без Windows работал?
Раз знаешь - то подумай еще раз, неужели не было эффектов круче чем дает стандартный DirectX через свои объекты и их методы.
При этом все это работало быстрее, занимало меньше.
Насчет интерграции ПО - полная лажа...
нo при этoм ты завeдoмo будeшь внe рынка.
вне рынка мыльных опер... Но не вне искуства. Гы 
. Что, в нём скрывалась интеграция с большой И? Та интеграция которую толкуют хотябы на http://www.opcfoundation.org/? Как интересно!!!А Visual Basic или на подобие скриптов там было?
К сожалению я тогда ещё такими вещами не интересовался, поэтому не могу сказать
2) Насчет интерграции ПО, думай что говоришь. Назови мне хоть один популярный рыночный продукт не майкрософт, который имеет автоматизацию, VB и поддержку на том же уровне, что и Microsoft Office?
А вo-втoрых сeйчас никoму нe интeрeснo скoлькo занимаeт игра, никoму нe интeрeснo, как oна сдeлана
пoжалуйста, мoжeшь дeлать игры стандартными срeдствами, нo при этoм ты завeдoмo будeшь внe рынка.
Но не вне искуства
Да поздно мне изучать, работаю я. Очень часто пользуюсь интерфейсами - удобно. Никогда их не регаю - незачем. Бывает компилируюсь как сервис (служба), но COM пользую исключительно редко, разве что картинку на папке поменять.
Я вот в данный момент работаю программистом видео под MS, ну и COM соответственно - это то с чем я работаю ежедневно. Просто если отринуть COM и ООП то понядобится просто колосальное количество времени и народа для того чтобы разработать допустим многоканальный аудио-видео плейер принимающий мультимедиа данные по сети. Да ещё и разработать его так чтобы это было не просто программой а распространяемым компонентом со своим SDK. Да и не думаю что он бы работал быстрее и надёжнее реализованного на DirectShow Игры разные... просто когда смотришь на DirectX поделки, когда одни и те же эффекты используют все игры подряд, становится тошно.
А Visual Basic или на подобие скриптов там было?
Вы не пользуетесь ООП ?
Предыдущая тема: Сервис работы с файлами