Perguntas sobre OOP em MQL5 - página 49

 

E o objetivo desses jogos mentais selvagens? O "propósito" (entre aspas, porque... gladíolo) do padrão é"sem quebrar o encapsulamento, fixar e preservar o estado interno do objeto" (entre aspas, porque citação). Mas não se pode passar sem o método setState(). Então, onde está a economia de encapsulamento aqui? Para escrever mais dois métodos para cada campo privado... Sim... legal, o encapsulamento é preservado.

E seja honesto, você vai usar esta abordagem na prática? Eu duvido. Na prática, você o tornará explícito e transparente - por exemplo, uma estrutura com o mesmo conjunto de campos e um par de métodos para salvar e restaurar. E então o encapsulamento será realmente preservado, haverá apenas dois novos métodos: para salvar o estado e para restaurar o estado.

 
Igor Makanu:

OK, eu vou salvar, eu precisava testar o princípio do trabalho, talvez isto seja o que eu estava procurando - um código para testador e para EA de trabalho, que pode salvar seu estado, e no testador ao contrário, não desperdiçar recursos em "gestos extras" - parte de tal padrão pode ser coberto por #ifdef -ami ;)

Estou tentando entender o significado deste abarrotamento com o guardião, mas não vejo nenhum uso em particular. Na verdade, é uma má prática de programação através da criação de efeitos colaterais. Quando você muda um objeto, você muda outro. Como resultado, o código torna-se confuso e difícil de entender. É melhor lutar pela pureza do código, imho.

O que o impede de simplesmente copiar um objeto para outro objeto e depois copiá-lo de volta? É essencialmente a mesma coisa, apenas mais correto e mais claro.

Se este singleton tem setters e getters ao mesmo tempo (ou seja, permite mudar seu estado e lê-lo), é equivalente a trabalhar com variáveis globais. E todo programador sabe que trabalhar através da mudança do estado global é maligno. Mas o singleton, de alguma forma, não conta )

 
Alexey Navoykov:

Estou tentando entender o significado desta coisa de custódia, mas não vejo nenhum benefício em particular. Na verdade, é uma má prática de programação ao criar efeitos colaterais. Quando você muda um objeto, você muda outro. Como resultado, o código torna-se confuso e difícil de entender. É melhor lutar pela pureza do código, imho.

É mais simples, eu estou aprendendo o material técnico

Estou acostumado a avaliar a condição de um sistema automatizado do ponto de vista de uma máquina de estado finito, e quero sempre manter um "instantâneo" do estado do sistema como uma reserva ))))

 
Igor Makanu:

Estou mais acostumado a avaliar o estado de um sistema automatizado a partir da perspectiva de uma máquina de estado finito, e isso sempre me faz querer manter um "elenco" do estado do sistema como um backup ))))

É que tal implementação é, em minha opinião, excessivamente complicada e confusa.

 
Alexey Navoykov:

O objetivo é claro, é muito complicado e confuso, na minha opinião.

Infelizmente, é assim que as pessoas são - até que eu receba meus pontapés e pancadas no traseiro, é pouco provável que eu consiga)))

 
Igor Makanu:

Infelizmente, é assim que as pessoas são - até que eu tenha minhas próprias batidas e solavancos, é pouco provável que eu consiga))))

Não há nada de errado com alguém estudando estes padrões, é ótimo - é ginástica para o cérebro, etc. etc. E então, em uma inspeção mais detalhada, acontece que é algum tipo de falsificação infernal, algum tipo de meme para afastar os otários da realidade, assim como aprender o BASIC visual escrevendo aplicações de console.

Estudar estes padrões é interessante, ainda que apenas do ponto de vista de aprender as baratas de alguém - o que elas são na natureza.

E se estamos realmente nos aproximando da tarefa de preservar o estado de um objeto, a maneira é tornar possível copiar um objeto para outro, seja ele um método simples ou uma sobrecarga = sobrecarga. E depois disso, talvez você não queira encapsular esta característica.

 
Dmitry Fedoseev:

E se realmente nos aproximamos da tarefa de preservar o estado de um objeto, a maneira de fazê-lo é tornar possível copiar um objeto para outro, seja ele qual for, seja apenas através de um método ou de uma sobrecarga =. E depois disso, talvez você não queira encapsular esta característica.

Para real, qualquer sistema técnico pode ser projetado com base em 3 princípios básicos:

- está em conformidade com a mais recente norma

- nossos avós a construíram dessa forma, não há necessidade de reinventar a roda

- Você não deve construí-lo de merda e palitos e depois modificá-lo

)))


Estou brincando, tenho tempo para ler e brincar com as opções em minha cabeça, aproveito, assim como a oportunidade de obter explicações rápidas para pontos pouco claros no fórum ;)

 
Alexey Navoykov:

Estou tentando entender o significado desta coisa de custódia, mas não vejo nenhum benefício em particular. Na verdade, é uma má prática de programação ao criar efeitos colaterais. Quando você muda um objeto, você muda outro. Como resultado, o código torna-se confuso e difícil de entender. É melhor lutar pela pureza do código, imho.

O que impede que você simplesmente copie um objeto em outro objeto e depois o copie de volta? É praticamente a mesma coisa, mas mais correto e claro.

Se este singleton tem setters e getters ao mesmo tempo (ou seja, permite mudar seu estado e lê-lo), é equivalente a lidar com variáveis globais. E todo programador sabe que trabalhar através da mudança do estado global é maligno. Mas o singleton de alguma forma não conta )

Suponho que este seja um ponto de vista típico de um programador que nunca teve nada a ver com projetos sérios de grande escala... Perdoem-me por ser grosseiro, mas não vejo outra explicação para chamar as práticas básicas de má prática.)

 
Dmitry Fedoseev:

Não há nada de errado com alguém que estuda estes padrões, é ótimo - exercícios cerebrais, etc. etc. E então, em uma inspeção mais detalhada, acaba sendo algum tipo de falsificação infernal, algum tipo de meme para atrair otários para longe da realidade, assim como aprender o BASIC visual através da escrita de aplicações de console.

Estudar estes padrões é interessante, ainda que apenas do ponto de vista de aprender as baratas de alguém - o que elas são na natureza.

E se estamos realmente nos aproximando da tarefa de preservar o estado de um objeto, a maneira é tornar possível copiar um objeto para outro, seja ele um método simples ou uma sobrecarga = sobrecarga. E, além disso, talvez o desejo de encapsular esta característica caia por terra.

Dmitry, provavelmente neste caso você confunde um pouco as tarefas de Guardião de padrões e Protótipo, e todas as suas possíveis combinações e manifestações. O primeiro - Snapshot não precisa necessariamente 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 destas tarefas aqui, é um exagero, é claro)

 
Alexey Navoykov:

1) Estou tentando descobrir o objetivo desta coisa de custódia, mas não vejo o benefício.
2) É essencialmente uma má prática de programação criar efeitos colaterais.
3) Quando você muda um objeto, você muda outro. Como resultado, o código torna-se confuso e difícil de entender. É ainda melhor lutar pela pureza do código, imho.
4) O que impede que você simplesmente copie um objeto em outro objeto e depois o copie de volta? Em essência é o mesmo, mas mais correto e claro.

Se este singleton tem setters e getters ao mesmo tempo (ou seja, permite mudar seu estado e lê-lo), é equivalente a trabalhar com variáveis globais. E todo programador sabe que trabalhar mudando o estado global é maligno. Mas o singleton, de alguma forma, não conta )

Você não faz parte da seita "eles o instalam, nós não precisamos dele, é seu ..."? ???


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ê...