Шаблоны Банды Четырех используют текстовый процессор в качестве примера, по крайней мере, для некоторых из их шаблонов, в частности, Composite и Flyweight.
Кроме использования C или C ++, могли бы вы действительно использовать эти шаблоны и объектно-ориентированные накладные расходы, которые они влекут за собой для написания высокопроизводительного полнофункционального текстового процессора?
Я знаю, что Eclipse написан на Java, но я его мало использовал, поэтому я не знаю, настолько ли он быстр или полирован, как что-то вроде Visual Studio, которая имеет систему редактирования текста на C ++.
Я использовал только C ++ и Java в качестве примеров. Этот вопрос больше связан с дополнительными затратами на наличие большого количества объектов в памяти, как в приложении, таком как текстовый процессор или даже в игре.
Шаблоны проектирования способствуют абстракции за счет скупости, даже если они обычно указывают, когда вы можете получить какой-то удар по производительности. Текстовые процессоры и особенно игры получают наибольшую выгоду, будучи максимально приближенными к металлу.
Мне просто было интересно, знает ли кто-нибудь о быстром объектно-ориентированном текстовом процессоре или текстовом редакторе, который не был написан на C ++, и будут ли они создавать его с использованием шаблонов, или они воздержатся от большого отвлечения вещей?
Flyweight действительно является просто способом сохранения ресурсов в ситуациях, когда существуют тысячи объектов с внутренним общим состоянием, поэтому он может быть полезен на языках более высокого уровня, чем C / C ++. Возможно, пример GoF с использованием глифов в документе был не лучшим выбором для иллюстрации этого паттерна.
Я думаю, что создание высокопроизводительного текстового процессора намного больше, чем просто эти базовые шаблоны, хотя я не уверен, что в GoF есть что-то, что исключает возможность успешного выполнения этого.
Как правило, Visual Studio (VS) более продвинута и работает значительно лучше, чем Eclipse - по крайней мере, версии VS, которые я видел. Eclipse - одно из самых впечатляющих Java-приложений, которое работает достаточно хорошо на более поздних машинах с большим объемом оперативной памяти.
Этот вопрос на самом деле, кажется, касается производительности Java и C ++, и это не столько объектная ориентация, сколько работа на виртуальной машине с сборкой мусора и тому подобным.
Этот документ по производительности Java против C ++ может стоить прочитать.
Что ж, мухи - это нелепый шаблон для использования в текстовом редакторе. IIRC, у каждого персонажа была ссылка как объект [примечание: это было для каждого глифа , который все еще сумасшедший, потому что ваша операционная система с радостью сделает это для вас]. Если указатель шире символа и вся обработка связана с косвенным обращением, вы с ума сошли бы от использования этого конкретного шаблона в текстовом редакторе.
Если вы интересуетесь дизайном текстовых процессоров, я нашел статью, в которой не рассматриваются шаблоны, но рассматриваются некоторые структуры данных, лежащие в основе конструкции и дизайна текстового процессора .
Постарайтесь помнить, что шаблоны дизайна призваны облегчить вашу жизнь, а не быть чистыми. Должна быть причина использовать шаблон, он должен принести некоторую пользу.
Одна из вещей, которую вы должны помнить, это то, что книга GoF была написана в начале 90-х годов, когда распространенные ОС не имели обширных графических библиотек. Даже Windows еще не была ОС в то время.
IIRC GoF был выпущен в 1994 году. Даже в 1994 году Windows 95 Beta была доступна (и работала на моем 486DX33), а Windows 3.x существовала примерно с 1990 года.
Eclipse + NetBeans + IntelliJ - все написано почти на Java или что-то, что работает на JVM (не на C ++). По крайней мере, в двух из этих IDE я провел некоторое время с кодом редактора, так что я могу заверить вас, что это все Java (и это тоже не просто).
VS 2005 был моим последним опытом в визуальной студии, и даже тогда я думал, что затмение было гораздо более отзывчивым (intelliJ вдвойне, учитывая время для разогрева и индексации).
Не уверен, насколько это актуально, но это мой опыт. Но я удивлен, что визуальная студия все еще сегодня написана на C ++ - я думаю, что было бы в интересах Microsoft использовать C # - если бы ничто иное не сильно ухудшило бы ее производительность, совсем не то, что съесть свою собачью еду!
Смысл GoF и паттернов в целом заключается в том, чтобы говорить о том, как делать вещи «правильно», как правильно, не обязательно «правильно», как правильно в зависимости от обстоятельств. Если производительность является проблемой, и вы обнаруживаете, что ни один из именованных шаблонов не обеспечивает адекватной производительности, тогда, возможно, вы сможете оправдать свой собственный путь. Но хорошее знание шаблонов дает вам «разумное значение по умолчанию» и, вероятно, будет означать, что вы жертвуете ясностью / SoC / и т. Д. Лишь настолько, насколько это необходимо для обеспечения адекватной производительности.
Чувство, что вы «отклоняетесь» от нормы, побуждает вас а) подумать дважды и б) хорошо прокомментировать неидиоматический код.
Образцы являются жизненно важным знанием, но ничто не является Евангелием, и вы всегда должны применять суждение.
Сказав все это - я не могу представить себе причину, по которой вы не могли бы написать достойный текстовый редактор с использованием шаблонов и современного JDK
Да, современные машины достаточно быстрые и имеют достаточно памяти, чтобы это было возможно. Если вы посмотрите на Squeak, вы увидите IDE Smalltalk, написанную на Smalltalk, значительно медленнее, чем Java, но все же достаточно быструю. С другой стороны, для редактирования HD-видео требуется поддержка более низкого уровня.