Discussão do artigo "Gráficos na biblioteca DoEasy (Parte 83): classe abstrata de objetos gráficos padrão"

 

Novo artigo Gráficos na biblioteca DoEasy (Parte 83): classe abstrata de objetos gráficos padrão foi publicado:

Neste artigo, criaremos uma classe para um objeto gráfico abstrato. Este objeto será a base para a criação de classes de objetos gráficos padrão. Os objetos gráficos têm muitas propriedades, e hoje, antes de criarmos uma classe de objetos gráficos abstratos, precisamos realizar um intenso trabalho preliminar, especificando ditas propriedades nas enumerações da biblioteca.

Vamos compilar o Expert Advisor novamente e executá-lo.

Adicionaremos diferentes objetos gráficos ao gráfico, e no log serão exibidas mensagens sobre a adição de novo objeto e uma breve descrição:


Como se pode ver, tudo funciona conforme o esperado.

Autor: Artyom Trishkin

 
Boa tarde,

Li alguns de seus artigos, às vezes listados, em geral ok, mas fiquei confuso com algumas coisas.....

1. Há muitas duplicatas de código em sua implementação... É claro que talvez haja uma refatoração mais tarde, ou talvez algumas)

2. Se você trabalha com objetos padrão, por que não usar classes prontas que vêm com terminais e carregá-las com funcionalidades adicionais, expandindo assim as possibilidades, e assim não há compatibilidade com versões anteriores e você tem trabalho dobrado....
 
Daniil Kurmyshev #:
Boa tarde,

Li alguns de seus artigos, ocasionalmente são listados, geralmente ok, mas me confundiu algumas coisas....

1. Muitas duplicatas de código em sua implementação.... É claro que talvez haja uma refatoração mais tarde, e talvez algumas)

2. Se você trabalha com objetos padrão, por que não usar classes prontas que vêm com terminais e carregá-las com funcionalidade adicional, expandindo assim as possibilidades, e assim não há compatibilidade com versões anteriores e você faz trabalho duplo....
  1. Você pode dar exemplos de duplicatas para responder mais especificamente?
  2. A estrutura e o conceito de criação de objetos de biblioteca não estão totalmente alinhados com o conceito da biblioteca padrão. Mas, se você deve ter notado, a biblioteca é construída com base no CObject e no CArrayObj padrão.

De qualquer forma, terei prazer em responder a perguntas, aceitar críticas e sugestões.

Obrigado por seu interesse.

 
Artyom Trishkin #:
  1. Você pode dar exemplos de duplicatas para ser mais específico?
  2. A estrutura e o conceito de criação de objetos de biblioteca não se chocam muito com o conceito da biblioteca padrão. Mas, se você puder observar, a biblioteca é construída com base no CObject e no CArrayObj padrão.

De qualquer forma, terei prazer em responder a perguntas, aceitar críticas e sugestões.

Obrigado por seu interesse.

1. Especificamente, eu quis dizer sobre a seção em que o código começa"Further on the code of theclass write methods for simplified access to set and return properties of the object: ".

Pelo que entendi, essa é uma descrição das funções na classe base, ou seja, elas são exaustivas para todos os objetos e têm nível de acesso público; se um sucessor for criado, ele verá todas essas funções, mas nem todos os objetos têm propriedades de controle e saída de texto, por exemplo, etc.... e, para usar esse objeto, ele sempre puxará a classe base, e não a sua própria diretamente do CObject , éclaro que pode fazer sentido obter todos os recursos da classe base, saída de log etc., mas, ao criar herdeiros, é necessário virtualizar e ocultar todas as funções que não podem ser aplicadas à classe do herdeiro no nível de acesso private.

Talvez esse seja o truque de sua implementação; se for assim, então SUPER!))))))

A propósito, talvez o nível protected para algumas funções seja mais apropriado do que public, mas aqui você sabe o que é melhor, é claro, dependendo do sentido que se dá a isso.

2. Sim, revisei seu código novamente, seu conceito de criação de uma biblioteca é diferente, concordo, o principal é que, ao criar níveis superiores de classes, crie funções públicas virtuais, para que outros desenvolvedores possam usar sua solução sem editar diretamente as bibliotecas.

3. Também notei que você usa a mesclagem de strings com +, em algumas versões do terminal em grandes mesclagens e com longas operações de terminal, situações imprevisíveis nessa implementação)))

Eu uso as funções StringFormat e StringAdd, a confiabilidade do trabalho aumentou e, visualmente, o código ficou mais legível.

4. Também gostaria de alertar sobre a limitação do comprimento dos objetos criados durante a renderização; lembre-se disso, é melhor gerar um hash a partir do nome e, com base nele, criar um objeto; a limitação tem uma função padrão, não me lembro exatamente, mas provavelmente ResourceCreate....

 
Daniil Kurmyshev #:

1. Especificamente, eu quis dizer sobre a seção em que o código começa"Mais adiante no código daclasse, escreveremos métodos para acesso simplificado para definir e retornar propriedades do objeto: ".

Pelo que entendi, essa é uma descrição das funções da classe base, ou seja, elas são exaustivas para todos os objetos e têm nível de acesso público; se um sucessor for criado, ele verá todas essas funções, mas nem todos os objetos têm propriedades de controle e saída de texto, por exemplo, etc.... e para usar esse objeto, ele sempre puxará a classe de base, e não a sua própria diretamente do CObject , éclaro que talvez faça sentido obter todos os recursos da classe de base, saída de registro etc., mas ao criar herdeiros é necessário virtualizar e ocultar todas as funções que não podem ser aplicadas à classe do herdeiro no nível de acesso private.

Talvez esse seja o truque de sua implementação; se for assim, então SUPER!)))))))

A propósito, talvez o nível protected para algumas funções seja mais apropriado do que public, mas é claro que você saberá melhor dependendo do significado disso.

2. Sim, revisei seu código novamente, seu conceito de construção de biblioteca é diferente, concordo, o principal é que, ao criar níveis superiores de classes, crie funções públicas virtuais, para que outros desenvolvedores possam usar sua solução sem editar diretamente as bibliotecas.

3. Também notei que você usa a combinação de cadeias de caracteres com +; em algumas versões do terminal, em combinações grandes e com operação longa do terminal, foram obtidas situações imprevisíveis nessa implementação))))

Eu uso as funções StringFormat e StringAdd, a confiabilidade do trabalho aumentou, e também visualmente o código ficou mais legível

4. Também gostaria de alertar sobre a limitação do comprimento dos objetos criados durante a renderização; lembre-se disso, é melhor gerar um cache do nome e, com base nele, criar um objeto; a limitação tem uma função padrão, não me lembro exatamente, mas provavelmente ResourceCreate....

1. A publicidade dos métodos e sua redundância é o custo de querer criar muitas maneiras diferentes de acessar as mesmas propriedades. Mas alguns métodos serão de fato virtuais ou prescritos apenas em herdeiros. Mas, novamente, isso só se aplica aos objetos da própria biblioteca. Ao herdar deles, infelizmente, todos os métodos públicos serão herdados.

2. Vou pensar sobre isso. Mas, na verdade, o nível superior de acesso será outro ponto de entrada para as bibliotecas, e serão funções definidas pelo usuário, novamente, repetindo recursos já implementados da biblioteca, mas serão mais compreensíveis para o usuário comum - basta usar a função para obter o resultado, e não para inventar lógica e manipuladores - tudo isso será feito dentro da biblioteca, e a saída será funções de caso de uso para simplesmente obter as informações necessárias.

3. não otimizei nada (exceto a lógica pensada com antecedência) e não criei nenhum perfil. Isso é para o último momento.

4. Verifiquei do meu jeito. O nome longo do objeto é possível. Mas obrigado, vou me lembrar disso e ficar de olho.

 
Artyom Trishkin #:

1. Tornar os métodos públicos e redundantes é o custo de querer criar muitas maneiras diferentes de acessar as mesmas propriedades. Mas alguns métodos serão de fato virtuais ou prescritos apenas em herdeiros. Mas, novamente, isso só se aplica aos objetos da própria biblioteca. Ao herdar deles, infelizmente, todos os métodos públicos serão herdados.

2. Vou pensar sobre isso. Mas, na verdade, o nível superior de acesso será outro ponto de entrada para as bibliotecas, e serão funções definidas pelo usuário, novamente, repetindo recursos já implementados da biblioteca, mas serão mais compreensíveis para o usuário comum - basta usar a função para obter o resultado, e não para inventar lógica e manipuladores - tudo isso será feito dentro da biblioteca, e a saída será funções de caso de uso para simplesmente obter as informações necessárias.

3. não otimizei nada (exceto a lógica pensada com antecedência) e não criei nenhum perfil. Isso é para o último momento.

4. Verifiquei do meu jeito. O nome longo do objeto é possível. Mas obrigado, vou me lembrar disso e ficar de olho.

4. Esse erro pode ter sido eliminado, mas não tenho certeza... a função parece funcionar, mas o objeto não é criado, esse é o comportamento quando o comprimento é grande

 
De fato, estou entrando nessa, e escolhi o curso de Tecnologia da Informação para fazer isso de forma definitiva.