Uma pergunta para os especialistas do OOP. - página 25
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
o próprio conceito de OOP implica simplesmente não escrever - você não deve conhecer a implementação do método (em seu exemplo return(SymbolSelect(m_name,select))
Imagine que, ao invés desta linha:
você tem que fazer muitas consultas, várias verificações, etc. - Isso levará tempo para escrever sua própria biblioteca e estudar o material
Suponha que sua tarefa seja usar apenas um método de solução pronta na forma de uma classe - você cria uma instância da classe (objeto) e usa o método Select(const bool select) pronto
Se você não vai realizar tais operações, liberar memória = apagar o objeto
Suponha que sua tarefa seja exibir um botão, apertando-o, você habilita/desabilita o símbolo no relógio de mercado ---> crie sua classe e encapsule o botão de classe pronta e a CSymbolInfo de classe pronta - a tarefa é feita
O paradigma OOP dá apenas informações gerais sobre o que pode ser feito com uma classe - você não quer encapsular o CSymbolInfo - bem, herde dela sua classe
Acredito, não entendo e não aceito isso. Quando você tem uma tarefa específica que não pode passar sem todas essas advertências, então a "iluminação mental" e a compreensão virão. Mas, por enquanto, do meu ponto de vista,nem sempre se justificam apenas engenhocas extravagantes. Nem sempre isso significa nunca. Estou feliz em usar a classe Ctrade, mas não aceito isso como mencionado acima. Se a descrição da função SymbolSelect na documentação não for difícil de encontrar, no SB já é difícil encontrar a descrição.
HH: "Em poucas palavras", a essência do OOP é uma solução rápida para um determinado problema sem o conhecimento da implementação.
Nesse caso, em vez de conhecer a implementação, é preciso saber como chamar o método desejado, onde encontrá-lo e assim por diante. Este é um tipo de linguagem em uma linguagem de programação?
Bem, posso entender se um projeto precisa ter várias instâncias de um objeto. Mas até agora não vi nenhuma implementação desse tipo, exceto a demonstração da Artem mencionada acima. Nesse caso, é claro que é melhor, mais fácil, mais simples, mas não cheguei a um entendimento completo precisamente por causa da falta de necessidade, da falta de tarefa. Não faz sentido mudar o objeto por causa de um único uso de funções mql5. Esse é o meu raciocínio.
Nesse caso, em vez de conhecer a implementação, você precisa saber como chamar o método certo, onde encontrá-lo e assim por diante. Este é um tipo de linguagem em uma linguagem de programação?
olhar na documentação, tudo o que é publicado publicamente é acompanhado de manuais, por assim dizer, de ética
não é um estilo, é um paradigma! - um conceito, regras de etiqueta, ninguém é obrigado a escrever assim, mas por alguma razão é o estilo mais comum
a essência do OOP é resolver rapidamente um determinado problema sem o conhecimento da implementação
Você pode chamar uma função, passando uma estrutura com dados para dentro dela, e obter uma solução igualmente rápida sem o conhecimento da implementação da função.
Sim, mas seu método será limitado, no OOP você também pode herdar - mesmo sem saber a implementação e acrescentar à sua tarefa, a primeira coisa que vem à mente - Botão com bordas arredondadas, há toneladas de exemplos na web
SZZ: e a lógica de desdobrar um objeto através de construtores é bastante útil.
Uma classe é uma descrição de um objeto. Bom. Contém as propriedades e a funcionalidade do objeto. Ok. Tudo isso é ordenado, aberto ou protegido.
Então o próprio OBJETO está fora de cogitação. É no contexto da classe. No contexto de seu nome e descrição. Isto é, no OOP, o Objeto, é exatamente um conjunto de atributos (não apenas propriedades, mas também elementos funcionais - métodos), mas mais ordenados e encapsulados do que eu tenho. (Faz mais sentido para mim).
Você tem que ler livros para dar sentido a isso. Pelo menos VC++ em 21 dias.
Aconselho você a usar MFC pela primeira vez, criar uma aplicação windows baseada em CDialog, criando todos os tipos de objetos e ver como eles são facilmente gerenciados.
Depois disso, você jogará fora seu empreendimento. Infelizmente.
Bem, isso é improvável. A questão é que eu encontrei muito poucas diferenças conceituais entre minha abordagem e o OOP. Minha abordagem também é orientada a objetos. Os objetos são encapsulados no núcleo e têm uma representação muito específica. Eles estão ligados por ponteiros, formando complexos - elementos, janelas... Se você for além dos gráficos e criar uma forma diferente de núcleo que inclua mais diversidade, ela será tão boa quanto no OOP.
A diferença nas abordagens está no estilo de escrita de código, sintaxe e métodos de distribuição de funcionalidade. Em minha abordagem a funcionalidade tende a se fundir, em OOP ela tende a se dividir. A fusão da funcionalidade é garantida para aumentar a eficiência do sistema e uma pequena quantidade de sintaxe, enquanto a divisão da funcionalidade facilita a portabilidade do código. Ele permite a conexão de módulos. De modo geral, estas são as diferenças.
É claro que minha abordagem ainda não tem essa ampla "objetividade". Mas, eu já tenho idéias sobre como consertar isso. Um núcleo é de um único tipo e isto limita as propriedades nele armazenadas, mas um núcleo não precisa ser uma matriz única. Pode ser um complexo de caroços. A principal vantagem é a representação digital dos objetos, que não requer uma longa descrição, sintaxe adicional e fragmentação da funcionalidade.
Mas, o OOP é muito interessante para mim. Aprenderei com isso).Peter, finalmente google classes, o que elas são no contexto da alocação de memória, chamadas de método, ou seja, em que o compilador converte tudo isso. A maioria das perguntas evaporará por conta própria depois disso.
Muito se pensou sobre o conceito de OOP, e eis o que se segue:
Vamos abstrair da sintaxe e dos termos técnicos, deixando os conceitos de "Classe", "Objeto", "Propriedade", "Encapsulamento", "Polimorfismo", "Herança". Vou descrever a "raiz" filosófica do conceito.
A realidade é percebida pela consciência através de prismas de "Espaço", "Tempo" e "Matéria" (é assim que os órgãos dos sentidos funcionam), e "Objeto" é um resultado discreto de sua interação contínua.
A multiplicidade de formas de interação gera uma variedade de objetos que são "plantados" pelo inconsciente do sujeito sobre uma certa "estrutura". Esta estrutura tem uma estrutura ramificada, em cascata e é "construída" no inconsciente, sendo um de seus "arquétipos". A estrutura assume novos e novos objetos (informações sobre eles) que são distribuídos em toda sua estrutura. É daí que vem o conceito de OOP.Esta é uma distribuição consciente e ligação de objetos imitando o "algoritmo" do inconsciente. Tendo dominado os métodos do próprio pensamento, o sujeito é capaz de simular seu trabalho no mecanismo de "rastreamento" do cérebro - o computador. Mesmo que um computador seja apenas uma paródia patética de um cérebro, mas o próprio homem percebe apenas as sombras do mundo objetivo. A cascata, arquétipo ramificado, é um "padrão" de distribuição de objetos, propriedades, processos e todas as informações dentro de nossa memória em geral. É uma ferramenta biológica para simplificar a percepção da realidade, estruturando um modelo do mundo ao nosso redor. É-nos dada pela Natureza. A consciência de nosso próprio mecanismo de processamento de informação "natural" (ou seja, inconsciente) é um nível de autoconsciência necessário parausar o OOP.
Considere este arquétipo implícito, biológico, "tipo árvore", que facilita a memorização, aprendizagem e percepção, no contexto de sua aplicação "artificial".No OOP, "produzimos" objetos encapsulando suas descrições em classes, onde estabelecemos suas propriedades e valores. As relações dos objetos são refletidas em sua classificação, e implementadas através da herança de propriedades e métodos desde o global ao privado. Praticamente, parece assim: todo objeto privado é apenas um objeto e, portanto, tem todas as propriedades de apenas um objeto + suas propriedades privadas. Os objetos derivados terão suas propriedades privadas como suas propriedades comuns, mas terão suas propriedades privadas. Além disso, a cadeia pode se ramificar indefinidamente. É o mesmo com os métodos de objetos. Um método reflete uma ação, uma interação, um processo, uma mudança de estado. Os métodos de objetos são distribuídos de modo geral para propriedades privadas como propriedades. Se houver um processo geral, cada forma discreta terá suas próprias propriedades. E isto é polimorfismo. Isto é, ao contrário da sobrecarga, o polimorfismo proporciona uma implementação privada diferente de uma função subjacente, mantendo seu mecanismo subjacente. Esta é uma herança "funcional".
Como podemos ver, "como uma árvore" no OOP está em toda parte; quaisquer que sejam os esquemas que você criar, você ainda terá uma "árvore"). Mas isto é correto, pois estamos apenas copiando nossos próprios padrões inconscientes de trabalho com informações.
Tenho pensado muito sobre o conceito de OOP e é isso mesmo:
...Difícil.
Peter, você precisa entrar na política. Tais talentos não são procurados aqui - para dizer muito, de forma inteligente e incompreensível, e sobre nada.
...
Com uma melhor compreensão de como nossas mentes conscientes e inconscientes funcionam, seremos capazes de replicar seu mecanismo no computador. Eu simplesmente me afastei dos detalhes técnicos e olhei para a raiz do conceito.