Можете ли вы действительно создать быстрый текстовый процессор с GoF Design Patterns?

Question

Шаблоны Банды Четырех использует текстовый процессор в качестве примера, по крайней мере, для некоторых из их шаблонов, в частности, Composite и Flyweight.

Кроме использования C или C ++, действительно ли вы могли бы использовать эти шаблоны и объектно-ориентированные накладные расходы, которые они влекут за собой для написания высокопроизводительного полнофункционального текстового процессора?

Я знаю, что Eclipse написан на Java, но я не очень часто его использовал, поэтому я не знаю, настолько ли он быстр или полон, как Visual Studio, в которой есть система редактирования текста на C ++.

---

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

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

Мне было просто интересно, знает ли кто-нибудь о быстром объектно-ориентированном текстовом процессоре или текстовом редакторе, который не был написан на C ++, и будут ли они создавать его с использованием шаблонов, или они будут воздерживаться от абстрагирования многих вещей?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Смысл GoF и паттернов в целом заключается в том, чтобы говорить о том, как делать вещи «правильно», как правильно, не обязательно «правильно», как правильно в зависимости от обстоятельств. Если производительность является проблемой, и вы обнаружите, что ни один из именованных шаблонов не обеспечивает достаточную производительность, тогда, возможно, вы сможете оправдать свой собственный путь. Но хорошее знание шаблонов дает вам «разумное значение по умолчанию» и, вероятно, будет означать, что вы жертвуете ясностью / SoC / и т. Д. Лишь настолько, насколько это необходимо для обеспечения адекватной производительности.

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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