Обсуждение статьи "Разработка системы репликации (Часть 32): Система ордеров (I)"

[MetaQuotes]

Опубликована статья Разработка системы репликации (Часть 32): Система ордеров (I):

Из всего, что было разработано до настоящего момента, данная система, как вы наверняка заметите и со временем согласитесь, - является самым сложным. Сейчас нам нужно сделать нечто очень простое: заставить нашу систему имитировать работу торгового сервера на практике. Эта необходимость точно реализовывать способ моделирования действий торгового сервера кажется простым делом. По крайней мере, на словах. Но нам нужно сделать это так, чтобы для пользователя системы репликации/моделирования всё происходило как можно более незаметно или прозрачно.

Сказать, что советник должен быть одинаковым, значит не компилировать его для использования в тестере, а затем снова компилировать для использования на реальном рынке. Это было бы гораздо проще и легче с точки зрения программирования, но создало бы проблемы, связанные с постоянным перекомпилированием советника пользователем. Мы совершенно не хотим, чтобы это произошло, мы хотим создать советник и скомпилировать его только один раз. Как только это будет сделано, его можно будет использовать как на реальном рынке, так и в уже созданном тестере.

Ответственная часть использования советника на реальном рынке, даже на демо-счете, является самой простой для реализации. Тогда мы начнем с нее. Одна деталь: мы начнем с самой базовой модели. Мы будем постепенно усложнять советника, чтобы он мог делать то, что мы действительно хотим, - использовать его вместе с репликацией/моделированием, а также на демо- или реальном счете. Первое, что мы сделаем, - мы позаимствуем большую часть кода, который мы уже объясняли в других статьях, опубликованных здесь в сообществе. Эти статьи принадлежат мне, поэтому я не вижу никаких проблем в использовании данной информации. Мы внесем некоторые изменения, чтобы сделать систему настолько гибкой, модульной, надежной и стабильной, насколько это возможно. В противном случае мы можем в какой-то момент оказаться в тупике, что сделает невозможным дальнейшее развитие системы во всех отношениях.

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

Рисунок 01: Текущая схема наследования классов советника

Но хотя данная схема очень хорошо работает для того, что было делалось до сих пор, она еще далека от того, что нам действительно нужно. Это не связано с тем, что сложно добавить класс C_Orders в эту схему наследования. На самом деле, этого можно добиться, если сделать класс C_Orders наследником класса C_Study. Но мы не хотим, чтобы это произошло, и причина кроется в очень практичном вопросе, который иногда игнорируется большинством программистов, работающих с ООП (объектно-ориентированным программированием). Данный вопрос известен: это инкапсуляция. Другими словами, мы будем знать только то, что необходимо для выполнения нашей работы. Когда мы создаем иерархию классов, мы не должны позволять некоторым классам знать больше, чем им действительно нужно знать. Мы всегда должны отдавать предпочтение тому виду программированию, где каждый из классов знает только то, что ему действительно необходимо знать для выполнения своей задачи. Поэтому сохранение инкапсуляции и одновременное добавление класса C_Orders в схему, показанную на рисунке 01, практически не оправданно. Поэтому лучшим вариантом решения данной проблемы является удаление класса C_Terminal из блока наследования, как показано на рисунке 01, и передача его в этот же блок в качестве аргумента или параметра, который может быть использован гораздо более подходящим способом. Так что контроль над тем, кто будет получать ту или иную информацию, будет осуществляться кодом советника, и это будет важно в дальнейшем, поскольку мы сможем поддерживать инкапсуляцию информации.

Автор: Daniel Jose