Вы действительно можете построить быстрый текстовый процессор с шаблонами дизайна GoF?

Flyweight действительно является просто способом сохранения ресурсов в ситуациях, когда существуют тысячи объектов с внутренним общим состоянием, поэтому он может быть полезен в языках более высокого уровня, чем C/C++.. возможно, пример GoF с использованием глифов в документе не был лучшим выбором для иллюстрации этой модели.

Я думаю, что есть гораздо больше для создания высокопроизводительного текстового процессора, чем просто эти основные шаблоны, хотя-не уверен, есть ли что-нибудь в GoF, что исключает возможность успешно сделать это.

Как правило, Visual Studio (VS) является более продвинутым и работает значительно лучше, чем Eclipse - по крайней мере, версии VS, которые я видел. Eclipse - одно из самых впечатляющих приложений Java, хотя оно довольно хорошо работает на более поздних машинах с большим количеством RAM.

Ну, flyweight -это нелепый шаблон для использования в текстовом процессоре. IIRC, у них был каждый символ, на который ссылались как на объект [Примечание: это было для каждого глифа , что все еще безумно, потому что ваш OS с радостью нарисует это для вас]. Поскольку указатель шире символа и вся обработка связана с косвенным обращением, было бы безумием использовать этот конкретный шаблон таким образом в текстовом процессоре.

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

Постарайтесь помнить, что шаблоны дизайна существуют для того, чтобы облегчить вашу жизнь, а не для того, чтобы Вы были чистыми. Должна быть причина, чтобы использовать паттерн, он должен приносить какую-то пользу.

Смысл GoF и паттернов вообще состоит в том, чтобы говорить о том, как делать вещи "right", как правильно, а не обязательно "right", как правильно в данных обстоятельствах. Там, где производительность является проблемой, и вы обнаруживаете, что ни один именованный шаблон не дает адекватной производительности, тогда, возможно, вы можете оправдать свой собственный путь. Но хорошее знание паттернов дает вам "sensible default" и, вероятно, будет означать, что вы жертвуете ясностью / SoC / и т. д. Только настолько, насколько это необходимо для обеспечения адекватной производительности.

Чувство, что вы "deviating" от нормы, побуждает вас а) дважды подумать и б) хорошо прокомментировать неидиоматический код.

Паттерны-это жизненно важное знание, но ничто не является Евангелием, и вы всегда должны применять суждение.

Сказав Все это - я не могу придумать ни одной причины, по которой вы не могли бы написать приличный текстовый редактор, используя шаблоны и современный JDK

Этот вопрос на самом деле, похоже, касается производительности Java против C++, и это не столько объектная ориентация, сколько работа на виртуальной машине со сборкой мусора и тому подобным.

Этот технический документ о производительности Java против C++, возможно, стоит прочитать.

Одна из вещей, которую вы должны помнить, заключалась в том, что книга GoF была написана в начале 90-х годов, когда преобладающая OSes не имела обширных графических библиотек. Даже Windows в то время еще не было OS.

IIRC GoF был выпущен в 1994 году. Даже в 1994 году бета-версия Windows 95 была доступна (и работала на моем 486DX33), а Windows 3.x существовал примерно с 1990 года.

Eclipse + netbeans + IntelliJ все они написаны в значительной степени все в java или что- то , что работает на JVM (не C++). По крайней мере в 2 из этих IDEs я провел некоторое время с кодом редактора, поэтому я могу заверить вас, что все java (и это тоже непросто).

VS 2005 был моим последним опытом работы в visual studio, и даже тогда я думал, что eclipse был гораздо более отзывчивым (intelliJ-вдвойне, учитывая время для разогрева и индексирования).

Не знаю, насколько это важно, но это мой опыт. Но я удивлен, что visual studio до сих пор написана на языке C++ - я думаю, что это было бы в интересах Microsoft использовать C# - если бы ничего другого не было, это действительно сильно повысило бы его производительность, ничего подобного тому, как есть свой собственный корм для собак !

Да, нынешние машины достаточно быстры и имеют достаточно памяти, чтобы это было возможно. Если вы посмотрите на Squeak, вы увидите Smalltalk IDE, написанный на Smalltalk, значительно медленнее, чем Java, но все же достаточно быстро. HD с другой стороны, редактирование видео-это то, что в настоящее время нуждается в некоторой поддержке более низкого уровня.