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
Interesting:
O método proposto por Alexander(AlexSTAL) poderia ter resolvido o problema (não vamos ter em conta a sua certa natureza problemática).
Whoa, whoa, whoa, whoa, whoa!
Eu não o sugeri, disse que há uma possibilidade.
E qual é o seu problema, não consigo entender?
Deve estar a discutir um exemplo em que metade da lógica está em falta e metade está errada (sobra desde o início do OOP)?
Whoa, whoa, whoa, whoa, whoa!
Eu não o sugeri, eu disse que há uma possibilidade.
E qual é o seu problema, não consigo entender?
Digamos que precisa de colocar diferentes objectos numa matriz.
Ao mesmo tempo, todas as propriedades destes objectos devem ser armazenadas na mesma matriz + deve haver acesso a todos os eventos e métodos.
A possibilidade oferecida por si (a implementação pode ser diferente), tanto quanto sei, permite o acesso à funcionalidade dos objectos (eventos e métodos).
Mas o armazenamento de dados numa matriz com um tipo de antepassado é pouco provável que funcione (dado que estes dados não foram declarados no antepassado).
Deixem-me esclarecer o meu pensamento.
Se nos detivermos neste exemplo em particular, então:
1. Digamos, podemos criar uma matriz que irá armazenar o tipo de objecto, posição em X, posição em Y;
2. Poderíamos tentar identificar um objecto único pelo seu ponteiro (embora ao trabalhar com um objecto, o ponteiro possa não ser utilizado, então seria desejável ter algo parecido com um cabo);
Uma pergunta parva (não vejo outra solução), porquê usar um ponteiro como cabo (criar uma propriedade no antepassado e preenchê-la no construtor)?
Não temos a capacidade de armazenar propriedades descendentes numa matriz (apenas aquelas que não estão definidas no antepassado). Por exemplo, tanto quanto sei, não podemos armazenar o raio de um círculo ou o lado de um quadrado numa matriz.
3. não temos a capacidade de armazenar propriedades descendentes na matriz (apenas as não cunhadas no antepassado). Por exemplo, tanto quanto sei, não podemos armazenar o raio de um círculo ou o lado de um quadrado numa matriz.
Porque não haveria de funcionar... Não os aborda directamente, mas usa a sua função "GetValue" com o parâmetro "radius" (se o objecto for um círculo)... Isto é como uma possibilidade...
Estabelece uma tarefa específica simples
Porque não haveria de funcionar... Não os aborda directamente, mas usa a sua função "GetValue" com o parâmetro "radius" (se o objecto for um círculo)... Isto é como uma possibilidade...
Coloca um problema simples e específico
A tarefa é simples, mas quem pode dizer que é fácil de implementar.
A tarefa é registar numa matriz vários objectos (descendentes da classe base) juntamente com os seus dados.
Vamos deixar claro, que juntamente com os seus dados!!!
2. GetArea() para cada descendente;
3. Acrescentar as seguintes características:
a. Calcular o perímetro do quadrado - lado *4;
б. Cálculo do perímetro de um círculo - 2πR.
3. Acrescentar formas adicionais à biblioteca - rectângulo (dois lados) e triângulo.
4. Acrescentar as seguintes características:
a. calcular a área de um rectângulo - base por altura;
б. Calcular o perímetro de um rectângulo - soma dos lados *2;
в. Cálculo da área de um triângulo;
г. Cálculo do perímetro de um triângulo.
5. Identificar cada objecto individualmente (entre todos os objectos e entre os objectos da sua classe).
De preferência com ou sem apontadores.
6. calcular o perímetro e a área das formas utilizando apenas os dados armazenados na matriz.
PS
Não é permitido transferir o código dos descendentes para os antepassados (a menos que este código se aplique a todos os antepassados).
Isto é, não se pode, por exemplo, transferir um raio para um antepassado, já que um quadrado, um rectângulo e um círculo não têm um.
Uma nova funcionalidade pode ser acrescentada a um antepassado, desde que se aplique a todos os descendentes.
Tomamos o código no reboque como base.
Dentro de uma única matriz, resolvi pessoalmente o problema simplesmente adicionando variáveis para armazenar área e perímetro ao antepassado + funcionalidade para escrever dados para eles.
Neste caso, se o resultado da GetArea() e outras funções de cálculo directo for controlado.
Não parece que tenha quebrado as minhas próprias regras.
Esbocei uma forma de implementar a abordagem que descreve.
Não está completa, mas é a abordagem mais importante
Esbocei uma forma de implementação com a abordagem que descreve.
Não está completa, mas é a abordagem mais importante
A abordagem é clara. É provavelmente uma das melhores soluções para um problema semelhante.
Pelo menos por agora.
A tarefa é simples, mas quem diz que é fácil de implementar?
1. a tarefa é escrever diferentes objectos (descendentes de uma classe base) juntamente com os seus dados para uma matriz.
...As folhas de cálculo na MQL5 já resolveram e descreveram o problema.
Como é bom ser capaz de ler... :)
Também não é má abordagem, embora, como entendi, ambas as abordagens sejam calculadas sobre a transferência/leitura de apenas um parâmetro (embora de tipos diferentes).
Mas o que fazer se houver muitos parâmetros e se for impossível encaixá-los todos numa classe base?
Tanto quanto sei, o índice do parâmetro a passar deve ser introduzido adicionalmente (também, pode ser criado na classe um array com parâmetros empilhados por índice).
Como é bom ser capaz de ler... :)
Também não é má abordagem, embora, como entendi, ambas estas abordagens sejam concebidas para transferência/leitura de apenas um parâmetro (embora de tipos diferentes).
E o que fazer se houver muitos parâmetros e for impossível incluí-los a todos na classe base?
Tanto quanto sei, é possível introduzir um índice do parâmetro a passar (também é possível criar um array com parâmetros empilhados por índice numa classe)?