Perguntas sobre OOP em MQL5 - página 50
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
Dimitri, neste caso você provavelmente está confundindo um pouco os objetivos do Guardião e Protótipo de padrões, e todas as suas possíveis combinações e manifestações. First- Snapshot não tem necessariamente que copiar o objeto inteiro, ao contrário do Protótipo.
E sim, a necessidade de encapsulamento aparece principalmente em grandes projetos com muitas pessoas. Para brinquedos como a maioria destes, é um pouco redundante.
O que se trata - sentar e debater com toda a seriedade que um valor pode ser atribuído a uma variável e depois pode ser usado. Oh sim - quando se programa qualquer coisa em qualquer coisa, muitas vezes são atribuídos valores diferentes a variáveis diferentes e depois são usados. Mas agora é chamado de forma diferente, e agora, ao discuti-lo, você tem que sulcar as sobrancelhas e dar um olhar sério.
E é importante não cometer um erro, se todos os campos forem salvos, é Protótipo, e se não todos, é Guardião, ou os caras vão rir.
Você não é membro da seita "eles estão instalando a internet, nós não precisamos dela, nós não precisamos da sua internet...", não é? ???
1. O custodiante, por projeto, é semelhante ao padrão que eles usam para armazenar o estado ao digitar com conteúdo modificável para reverter mudanças quando estas mudanças não são uma, mas várias centenas. Por exemplo, editor de fotos, editor de texto...
Encontrei-a depois de escrever -https://refactoring.guru/ru/design-patterns/memento
2. basicamente é uma má prática não saber e não entender o assunto para criticar algo lá...
3. Como algo que você já não entendeu pode se tornar mais confuso e difícil de entender?
4. O resto é com você...
O que o Partido Republicano tem a ver com isso?
Por acaso, você não é membro da seita "eles instalam intinet, nós não precisamos dela, você intinet"? ???
1. O custodiante, por projeto, é semelhante ao padrão que eles usam para armazenar o estado ao digitar com conteúdo modificável para reverter mudanças quando estas mudanças não são uma, mas várias centenas. Por exemplo, editor de fotos, editor de texto...
Encontrei-a depois de escrever -https://refactoring.guru/ru/design-patterns/memento
2. basicamente é uma má prática não saber e não entender o assunto para criticar algo lá...
3. Como algo que você já não entendeu pode se tornar mais confuso e difícil de entender?
4. O resto é com você...
Eu estou com você até o fim! Obrigado por argumentar meu ponto de vista... Eu era muito preguiçoso))
Eu acrescentaria apenas no ponto 1 que a foto não armazena necessariamente todos os dados do objeto, e pode haver várias filiais com centenas de fotos do mesmo objeto "de lados diferentes". Nesse caso, o armazenamento de centenas de cópias de dados não utilizados é realmente a pior prática.
Chegou-se a isto - sentar-se ali e falar com toda a seriedade sobre como uma variável pode ser atribuída a um valor e depois ser usada. Oh sim - quando se programa qualquer coisa em qualquer coisa, muitas vezes são atribuídos valores diferentes a variáveis diferentes, e então eles são usados. Mas agora é chamado de forma diferente, e agora, ao discuti-lo, você tem que sulcar as sobrancelhas e dar um olhar sério.
E é importante não cometer um erro, se todos os campos forem preservados, é o Protótipo, e se não todos, é o Guardião, ou os meninos vão rir.
Dmitry, eu lhe asseguro, eu ficaria feliz em rir de você, bem, eu amo isso) mas, neste caso, você exagerou, mesmo sorrindo particularmente bem.
Você está realmente confuso - um TOTAL não é igual a uma CÓPIA OBJETIVA, eu apontei isso para você.
Se não estiver claro, deixe-me explicar-lhe pelo exemplo - você tem 1000 bytes de objeto, você precisa de 200 para instantâneo, então por que copiar 800, especialmente se você tem muitos milhões de instantâneos salvos.
p/s// E em geral. As pessoas não percebem que os padrões são apenas um exemplo elementar de solução de um problema TIPICAL elementar. E na verdade as tarefas não são elementares, mas mais complicadas. E para resolver problemas reais, os padrões são necessários, mas muitas vezes não em forma de livro puro, mas adaptados a uma tarefa específica, possivelmente combinados entre si, possivelmente com a adição de alguma improvisação, expressa às vezes em uma simplificação, se a tarefa permitir, ou vice versa "ponderação" da realização.
Novamente, por que você precisa de encapsulamento e interfaces - isto provavelmente não pode ser compreendido se seu QI está abaixo de Wasserman, ou se você não participou de projetos reais, quando diferentes partes do projeto são alteradas por pessoas diferentes simultaneamente, e não seguir os princípios básicos do OOPD envolve custos enormes na captura de bugs. Realmente, por que tudo isso para estampar EAs para o mercado))
Sergey Dzyublik:
1. Um mantenedor, de design semelhante ao padrão usado para armazenar o estado quando se digita com conteúdo modificável para mudanças de rollback quando estas mudanças não são uma, mas várias centenas. Por exemplo, um editor de fotos, um editor de textos...
2. Na verdade, é má prática não saber e não entender o assunto para criticar algo lá...
O ponto-chave foi destacado. É o conteúdo modificável que está na raiz de muitos problemas de mau uso do OOP. Eu também estive envolvido nisto por muito tempo, mas com a experiência gradualmente vem o entendimento. O código onde há muitas inter-relações entre objetos (ponteiros) e ao mesmo tempo esses objetos são mutáveis - é uma massa terrível que não mudará. Assim, devemos nos esforçar para tornar os objetos de referência imutáveis. Somente os objetos de valor devem ser mutáveis, ou seja, estruturas e tipos simples, e ponteiros também.
Neste caso, é desejável declarar o objeto inicial como uma estrutura, e não como uma classe. Então você pode mudar seu conteúdo. Neste caso, é claro, nenhum ponteiro para ele será tomado e salvo como no padrão discutido, e isto é correto. Para mudar objetos você deve se referir explicitamente a seus métodos, ou passá-los como um argumento para uma função, ou seja
ou
Não é assim:
parece que estamos mudando um objeto memento, mas na verdade estamos mudando algum outro objeto, que provavelmente está localizado em outro lugar no programa. Isto cria um efeito colateral. É o mesmo que mudar uma variável global em um lugar e usar seu valor em outro lugar.
Ou seja, uma lembrança não deve armazenar uma referência ao objeto original. Ele deve armazenar apenas o conteúdo. Esta é a minha opinião, mas acho que não estou longe da verdade )
Não estou reivindicando minha própria opinião, provavelmente lida em algum lugar, mas imho, existem apenas dois problemas na programação: estrutura correta do programa e rapidamente encontrar um bom nome para uma variável, e tudo o mais é feito com bastante facilidade
Eu também estou falando sério.
Obrigado, eu vou ler seus padrões
Vou esperar, no caso de aparecer mais alguém, mas apenas no nível de iniciantes e treinadores que fazem perguntas a akademvelopers swoop em ))))
1) O código, que tem muitas inter-relações entre objetos (ponteiros), e ao mesmo tempo os objetos são mutáveis, é uma massa absurda, na qual o diabo não pode entender mais tarde. Portanto, é necessário lutar para queos objetos de referência sejam imutáveis.
2)Somente objetos de valor, ou seja, estruturas e tipos simples, e ponteiros devem ser mutáveis.
3) Nestecaso, é desejável declarar o objeto inicial como uma estrutura, e não como uma classe. Então você pode mudar seu conteúdo. É claro que você não pode levar um ponteiro até ele e salvá-lo como no padrão discutido, e isto é correto.
4)Os objetos devem ser mudados chamando explicitamente seus métodos ou passando-os como um argumento para uma função.
Parece que estamos mudando o objeto memento, mas na verdade é algum outro objeto que provavelmente está localizado em outro lugar no programa. Isto cria um efeito colateral.
1. Acontece que a estrutura de dados Árvore é toda do mal...
2. pobre C++ onde classe === estrutura privada, o que fazer, provavelmente devemos recusar estruturas e classes.
3. e isso mesmo: sem padrões, sem ordenação por ponteiros, sem economia de memória, especialmente para objetos grandes...
4. Não devemos nos esquecer de proibir o uso de interfaces e funções de modelo, caso contrário você não entenderá com que objeto você está trabalhando - que horror...