Uma pergunta para os especialistas do OOP. - página 3
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
Criatura.
Flora/Fauna
Subespécie
Espécie
Família
etc.
É isso que você quer?
Bem, é uma simples herança da entidade base "Entidade".
Mas você pode ir mais fundo do que isso - há unicelulares/multicelulares, e isso é tudo para os seres vivos. Mas há também os não-vivos. Tudo depende de tarefas, para as quais você precisa encontrar propriedades de um objeto básico, e herdá-las delas.
Se você está realmente louco, você pode chegar aos átomos e começar a dividi-los em partes em busca de um objeto pai fundamental (tenha cuidado - uma reação de fissão pode se tornar uma reação em cadeia, e você destruirá metade do mundo :))
Certo. À primeira vista, o conceito de OOP é ideal para a construção de uma hierarquia. Mas como você trabalha com uma hierarquia construída através do OOP? É um mar de sintaxe e complexidade de transições entre links devido aos direitos de acesso às classes e seus conteúdos. É aqui que começam as despesas gerais, como conseqüência da divisão em classes. O OOP, por um lado, permite construir uma hierarquia, por outro lado, torna extremamente difícil trabalhar com ela.
Bem, não. O OOP dá acesso muito fácil a qualquer membro da hierarquia em qualquer local.
Comece por encontrar seu objeto de base com as propriedades mínimas exigidas.
O resto dos objetos herdam dele. Para evitar reinventar a roda, seu objeto base deve herdar a classe CObjeto da biblioteca padrão. Isto permite criar sua própria hierarquia de objetos sem a necessidade de reinventar as listas
CObject --> CBaseObject --> sua hierarquia.
No CBaseObject você deve ter um método virtual que devolva este objeto. Então cada um dos descendentes terá este método de acordo, e ele retornará exatamente o objeto descendente. A classe base do CObject já tem um método -Tipo(). Se você tiver o mesmo método virtual de CBaseObject, e ele devolverá o tipo de objeto, você saberá qual objeto você acessou.
É como uma base básica para todos os seus objetos. E todos eles devem ser armazenados em suas próprias listas - cada lista conterá apenas objetos de um tipo - peixes, animais, humanos, deuses, etc.
Ou seja, você precisará ter uma lista para cada subtipo. E deve haver uma lista, que conterá as seguintes listas na hierarquia. Cada uma dessas listas também deve ter listas - novamente - que são as próximas na hierarquia. E assim por diante.
Ou seja, você também precisa de um objeto de lista base, no qual você colocará as listas necessárias. E esta lista base deve ter um método Type(), e deve haver um método que permita devolver qualquer objeto armazenado nela por seu índice. Então, se isto for feito, você terá automaticamente um método em qualquer uma das listas que devolve o objeto requerido.
Em geral, é preciso pensar primeiro em seu objeto de fundação, e depois em seu objeto de lista. Também não é necessário criar listas de objetos, elas já existem.
E depois é uma questão de técnica. E você só precisa saber o tipo de objeto que está procurando. Haverá muitos tipos em sua hierarquia, e cada um deles é conhecido por você e você pode solicitá-lo e recebê-lo.
Como me pareceu, não tem nada a ver com o OOP neste caso.
No caso de Peter, todos os objetos da matriz são procurados por alguma chave. E não há diferença se você usa classes, se você usa matrizes, se você usa um monte de objetos declarados.
O OOP permite ter uma lista de objetos, cada um dos quais, digamos, tem o método GetColor() - e o usuário percorre todos os objetos em busca da cor certa. Mas, se sem o OOP - temos uma série de estruturas idênticas, que o usuário precisa conhecer, para obter a cor de onde ela é necessária, com o OOP - o usuário não precisa saber exatamente como e onde a cor é armazenada - o método GetColor() do objeto sabe, onde obter a cor.
Portanto, para OOP - o usuário não precisa saber como e onde a cor do objeto é armazenada. Portanto, se de repente precisarmos adicionar um "objeto para cegos", no qual a cor é codificada por pontos em braile, podemos facilmente adicionar este objeto à nossa lista e alterar apenas seu método GetColor(), que receberia o código de cor dos pontos em braile e o devolveria de forma regular. Para o usuário de nossa lista, nada vai mudar.
Se tivermos apenas uma matriz - não podemos colocar lá "pontos em braile". Não temos tal campo nele.
O benefício do OOP é realmente bem visto, quando herdamos do CObject, então criamos um conjunto de objetos CArrayObj, e então, escrevendo apenas a função de comparação - imediatamente obtemos uma classificação rápida e possibilidade de busca binária.
Grosso modo, para meu exemplo acima, com cor - para OOP - nós escrevemos uma função de comparação, obtendo cor através de GetColor(), e podemos classificar nossos objetos por cor, mesmo sem saber que temos metade dos objetos com cor real e metade com "pontos em braile".E se quisermos adicionar um objeto com novo código de cores - novamente só precisamos escrever a função GetColor(), que traria sua representação de cores ao padrão - e então osalgoritmos de classificação e busca já escritos aceitarão este novo objeto sem problemas.
Isto é, na verdade, o OOP nos permitiu ter um algoritmo de classificação e recuperação de objetos ainda não escritos, antes mesmo de decidirmos exatamente como eles serão representados e como serão armazenados.
Os benefícios do OOP são realmente claros, quando herdamos do CObject, então criamos um conjunto de objetos CArrayObj, e então, escrevendo apenas a função de comparação, obtemos uma classificação rápida e busca binária.
É um mar de sintaxe e de dificuldades com as transições entre links por causa dos direitos de acesso às classes e seus conteúdos. É aqui que começam as despesas gerais, como conseqüência da divisão em classes. O OOP, por um lado, permite construir uma hierarquia, por outro lado, torna extremamente difícil trabalhar com ela.
os modificadores de direitos de acesso permitem detectar erros no momento da compilação
Em geral, tudo isso não complica o trabalho com as aulas, não o utilize, escreva tudo em público: e então será mais fácil trabalhar com eles.
SZZY: Muitas frases bonitas sobre OOP, encapsulamento e herança... Tudo isso é bom, mas a vantagem mais importante do OOP sobre outros estilos de programação é o armazenamento de todos os dados (campos de classe) e funções de trabalho com esses dados (métodos de classe) em um só lugar (classe) - em livro é o encapsulamento. Além disso, o uso do OOP depende da tarefa, se a tarefa permitir escalar classes, será necessária uma hierarquia e haverá classes base e seus descendentes - se usá-lo, depende de você
Devo admitir que no conceito OOP, "Objeto" é apresentado em um contexto mais amplo do que em meu "Kernel". Mas, isto não é surpreendente, uma vez que até agora só lidei com gráficos, e o OOP é usado para uma ampla gama de tarefas. Meu "menu" de objetos é bastante esparso e além de "etiqueta", "elemento", "janela", provavelmente não há muito mais... No entanto, para interfaces gráficas não há muito mais que eu precise.
No entanto, surgiu agora a questão da ampliação do conceito de "Objeto" e da construção de uma hierarquia. Um simples núcleo bidimensional não pode aceitar toda a variedade de objetos de base de conhecimento e, portanto, ou um núcleo diferente para objetos diferentes deve ser criado ou o conceito de OOP deve ser seguido.
Em essência, esta é uma questão puramente técnica. O que é mais eficiente, o que é mais rápido, o que é mais legível, etc...
De fato, você pode simplesmente manter todos os objetos em uma matriz como uma lista de propriedades, entre as quais estarão as indicações para outras matrizes, com outros objetos e assim por diante. Ouvocê pode usar explicitamenteo OOP. A orientação a objetos está invariavelmente presente em ambas as abordagens, apenas os métodos de implementação são diferentes. A mesma memória, as mesmas indicações, os mesmos objetos, a mesma classificação. Apenas a forma de código é diferente...
Queria falar a Peter sobre isto quando ele entender o conceito de armazenamento de dados que foi proposto a ele.
Vou tentar entender este conceito de armazenamento e manuseio de dados.
Certo. (risos) Podemos conversar pessoalmente sobre o assunto. Ou no Skype, como você preferir. É que as especificidades não estão no tópico deste tópico - aqui, como eu entendo, são apenas perguntas gerais.