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

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 / etc только настолько, насколько это необходимо для обеспечения адекватной производительности.

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

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

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

Answer 4

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

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

Answer 5

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

VS 2005 был моим последним опытом работы с Visual Studio, и даже тогда я думал, что eclipse гораздо более отзывчив (IntelliJ вдвойне лучше, учитывая время на прогрев и индексацию).

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

Answer 6

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

Answer 7

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

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