Perguntas sobre OOP em MQL5 - página 55
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Você está preso nas minúcias. Desinteressante. O principal ponto da discussão do padrão "guardião" aqui foi que ele meio que promete a preservação do encapsulamento, mas é implementado criando um par de métodos públicos para cada campo. Engraçado como você não captou a mensagem mais importante.
Não estou preso, estou tentando, por respeito a você como interlocutor, dar sentido às suas palavras e desvendar suas autocontradições. Aparentemente, em vão.
Acho que ninguém aqui também está interessado em sua espuma de "padrões sagrados".
Tudo aqui é claro, específico e canônico. Existe um LIVRO! Este LIVRO apresenta estes padrões, e é disso que estamos falando. O livro é chamado de Design Patterns ou algo parecido. Mas não só o livro, existem muitos sites sobre eles na Internet e mesmo na Wikipédia, o principal é que o assunto é canonizado)) ...e quem não entende os padrões de design - plebeu, e quem os domina - ele domina a própria vida! Amém!
Você é como um palhaço, infelizmente. Basta deixar o fio OOP, se isso te enoja tanto)
Tudo aqui é claro, específico e canônico. Existe um LIVRO! Este LIVRO apresenta estes padrões, e é disso que estamos falando. O livro é chamado de Design Patterns ou algo parecido. Mas não só o livro, existem muitos sites sobre eles na Internet e mesmo na wikipedia, o principal é que o assunto é canonizado)).
É claro que, se houver até 100 variáveis globais, podemos prescindir de funções, se houver mais de 50 EAs, então as classes são apropriadas, e eu entendo corretamente, se houver mais de 20 desenvolvedores e mais de 20 métodos e número de variáveis é desconhecido, então o padrão é necessário. Se existe apenas um desenvolvedor, então se existe, não tanto?
Não estou preso, estou tentando, por respeito a você como interlocutor, dar sentido às suas palavras e desvendar suas autocontradições. Aparentemente, por nada.
Acho que ninguém aqui também está interessado em sua espuma de "padrões sagrados".
Não tenho contradições, a contradição está em seus padrões, já escrevi sobre eles duas vezes, deixe-me lembrá-lo: um padrão "guardião" promete preservação de encapsulamento, mas é implementado através da criação de dois métodos públicos para cada campo privado.
E diga-me, onde você viu uma contradição em meu padrão?
É claro que, se houver até 100 variáveis globais, podemos prescindir de funções, se houver mais de 50 EAs, então as classes são apropriadas, e entendo corretamente, se houver mais de 20 desenvolvedores, mais de 20 métodos e o número de variáveis é desconhecido, então o padrão é necessário. Se existe apenas um desenvolvedor, então, se existe, nem tanto?
Os desenvolvedores precisam de cérebros em primeiro lugar.
Você é como um palhaço, infelizmente. Basta deixar o fio OOP se você está tão enojado com ele)
O que "isso"? Eu gosto do OOP. Mas estes padrões notórios têm uma relação bastante distante com o verdadeiro OOP.
Não tenho uma contradição, a contradição está em seus padrões, já escrevi sobre eles duas vezes, lembrando: o padrão "guardião" promete preservar o encapsulamento, mas é implementado através da criação de dois métodos públicos por campo privado.
Agora eu entendo. Você simplesmente derramou emoção contra todos os padrões, que o significado de suas palavras foi perdido.
Mas em Snapshot este problema é resolvido usando classes aninhadas para Snapshot.
Se não for suportado pela linguagem, concordo, há este inconveniente, mas pode ser contornado por alguns truques de muleta que me lembro.
Agora eu entendo. Você apenas atenuou a emoção contra todos os padrões, que o significado de suas palavras foi perdido.
Mas em Snapshot este problema é resolvido usando classes aninhadas para instantâneo.
Se não for suportado pela linguagem, concordo, este inconveniente está presente, mas pode ser contornado com alguns truques de muleta, eu me lembro.
Você entendeu tudo errado.
Não importa se é possível escrever uma classe aninhada ou não, não é uma grande diferença. Há um exemplo de código neste tópico com uma classe aninhada e dois métodos públicos por campo privado.
O que 'isso'? Eu gosto do OOP. Mas estes padrões notórios têm uma relação bastante distante com o verdadeiro OOP.
Vou dizer novamente - ninguém reza sobre os padrões. Estes são apenas padrões que podem ser usados como referência.
Mas afirmar que eles não têm nada a ver com o OOP, bem, isso não é verdade.
Em minha humilde experiência, em forma de livro puro, eles são raramente utilizados, com raras exceções. Normalmente, se houver uma tarefa adequada para um padrão, ela vai junto com pelo menos algumas outras tarefas para outros padrões, e é assim que se cruzam 2-3-10+ padrões, este é um trabalho para o cérebro do programador / arquiteto.
Você não entende nada.
Não importa se você pode ou não escrever uma classe aninhada, não é uma grande diferença. Neste tópico há um exemplo de código com classe aninhada e dois métodos públicos por campo privado.
Você já me disse tantas vezes que sou um tolo e não entendo nada, estou orgulhoso da minha compostura por não lhe mandar uma foda bem merecida há muito tempo)
Basicamente - uma classe aninhada torna os métodos públicos para campos privados opcionais, essa é a violação de encapsulamento sobre a qual você está escrevendo. Algum outro argumento?