Fazendo um projeto de crowdsourced em Tela - página 24
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
Se dois programadores com a mesma experiência e inteligência estão competindo, criandograndes projetos similares. Mas a primeira utiliza apenas funções, e a segunda utiliza funções e classes. Definitivamente, a vitória será para a segunda. Mas, repito, se for um projeto volumoso, este último o fará mais rápido porque haverá menos bugs e mais ordem. E o produto do segundo será mais legível, de manutenção e mais facilmente atualizado e complementado. Esta nem sequer é a minha imho, é apenas uma declaração de fato. É mais fácil cavar um buraco com uma pá do que com uma colher de pedreiro. Se você implementasse seu mecanismo não apenas em funções, mas também em classes, ele se tornaria mais eficiente. Esta é a minha imho.
Vamos começar com a questão da necessidade de aulas na implementação de grandes mecanismos. Uma classe é uma concha para um conjunto de algumas funções, e um "grande mecanismo" é um bloco de código que implementa um conjunto de tarefas. Na minha implementação, um "grande mecanismo" é quase sempre uma função muito grande e um conjunto de pequenos mecanismos que a servem. O chamado "motor". Se você o enche com funções de serviço em uma classe, nada mudará, e se você o enche em classes diferentes, o acesso entre elas se tornará mais complicado e a eficiência do mecanismo diminuirá.
Se o tamanho do mecanismo aumentar, você deve otimizar seu código ou dividir a funcionalidade em arquivos. Não é suficiente? Além disso, a otimização periódica do código em um bloco leva a milagres de eficiência. Ela é constantemente comprimida e requer cada vez mais funções para ser implementada. Ou seja, o número de funções diminui, ao contrário. Eles são generalizados em um bloco, cujo código é constantemente melhorado. Este é um caminho direto para a eficiência .
Além disso, se tornarmos globais variáveis importantes, elas serão visíveis em todos os lugares do mecanismo, e será fácil trabalhar com elas, e se definirmos escopos para elas, isso criará uma tarefa supérflua do ponto de vista da eficiência do mecanismo. Novamente, a complicação de acesso. Criando objetos de classe, etc... A tendência de fragmentar o mecanismo em um grande número de funções arruína não só a eficiência, mas também a universalidade dos blocos de código. Acontece que cada tarefa concreta precisa de uma função separada, e a universalidade dos blocos de código simplesmente não é melhorada. O número de chamadas e parâmetros passados também cresce. Isto não contribui para a eficiência do mecanismo, mas esta tendência é realmente promovida pelo OOP.
O OOP é mais eficiente quando um projeto é tratado por uma equipe de programadores. Neste caso, não se pode passar sem ele. Embora, se pensarmos nisso, podemos encontrar aqui também uma maneira de passar sem ele...
Mas, é claro, tudo isso são palavras. Na prática, eu provaria rapidamente do que estou falando.
Nikolai Semko:
E, Peter, dei uma rápida olhada em seu código e percebi que você está usando lona em toda a sua extensão (não na classe CCanvas, mas quem se importa). Então por que todas essas perguntas sobre tela e por que estou tentando explicar todas essas coisas aqui? :)).
)))), estou um pouco surpreso com suas explicações sobre os princípios de desenho do Kanvas. Já lhe disse antes e lhe mostrei que tudo no meu Kanvas está desenhado)). (Bem, quase tudo. :))
Comecei este tópico porque não consigo entender porque até agora ninguém desenhou o mesmo botão que o meu. Afinal de contas, e em suas palavras, é fácil.
))), também fiquei um pouco surpreso com sua explicação sobre os princípios do desenho em tela, porque já lhe disse e mostrei antes que tudo está desenhado)). (Bem, quase tudo. :))
Comecei este tópico porque não consigo entender porque até agora ninguém desenhou o mesmo botão que o meu. Afinal de contas, e em suas palavras, é fácil.
Se você não viu, isso não significa que ninguém, a não ser você, não possa fazer isso. É tão insignificante que você nem precisa postar - um evento insignificante demais - criando apenas um botão - para postar seu código, não porque você é o melhor ;)
Todos vocês estão competindo, e com razão, com Anatoly - com moinhos de vento.
Se você ainda não viu, isso não quer dizer que ninguém além de você seja capaz de fazer isso. É tão insignificante que não há necessidade de afixar - um evento insignificante demais - apenas criando um botão - para afixar seu código, não porque você é o melhor ;)
Todos vocês estão competindo, e com razão, com moinhos de vento.
Acalme-se, Artem. Eu já percebi que você não gosta de mim. Aparentemente, o mesmo acontece com muitos outros sobre este recurso. Talvez seja justificado, mas é demais para mudar sua personalidade do nada ao discutir questões técnicas.
Eu estou calmo, o que o faz pensar o contrário?
Gostar/des gostar de uma pessoa - não é um fórum técnico para discutir. Para mim, você é neutro - nada mais. Da mesma forma, como para o resto de nós, me parece.
Mas para que você não seja mencionado no estilo "ah-ah-ah..., é que Dom Quixote..., eu me lembro, eu me lembro...", você precisa fazer algo útil, pelo menos.
Você pode ou não fazer o que quer fazer - seu direito, e ninguém o contesta. Ninguém precisa de sua palavra aqui - você deve dá-la a si mesmo em primeiro lugar ;)
O ambiente é muito amigável - as pessoas lhe dizem como é bom usar o OOP em algumas situações, um homem está crucificando diante de você, tentando ajudá-lo em algo, codificando para que você possa mostrar, para torná-lo mais compreensível. Mas acontece - por suas próprias palavras - que você nem precisa - você simplesmente não sabe com quem mais competir, e tenta desafiar as pessoas "fracamente".
E o que também me parece - você não é porque decidiu não escrever e não estudar OOP, que pesou tudo e entendeu que você, usando programação procedural, escreveu código muito melhor e otimizado (como você o apresentou a todos aqui), mas simplesmente porque não entendeu nada lá, e inventou uma desculpa, que você anunciou a todos, apoiando com palavras e desafiando "acredite somente aquele que me bate".
Lembra-se da piada sobre o "Elusive Joe"?
...
Lembra-se da piada sobre o "Elusive Joe"?
Concordo plenamente.
O lírico/filósofo esquivo... :-) a mesma porcaria do "Joe", só que na "outra mão"... :-)
Comecemos pela questão da necessidade de aulas na implementação de grandes mecanismos. Uma classe é uma concha para um conjunto de funções, e um "grande mecanismo" é um bloco de código que implementa um conjunto de tarefas. Na minha implementação, uma "Grande Máquina" é quase sempre uma função muito grande e um conjunto de pequenas funções que a servem. O chamado "motor". Se você o enche com funções de serviço em uma classe, nada mudará, e se você o enche em classes diferentes, o acesso entre elas se tornará mais complicado e a eficiência do mecanismo diminuirá.
Se o tamanho do mecanismo aumentar, você deve otimizar seu código ou dividir a funcionalidade em arquivos. Não é suficiente? Além disso, a otimização periódica do código em um bloco leva a milagres de eficiência. Ela é constantemente comprimida e requer cada vez mais funções para ser implementada. Esse é o número de funções que diminui, ao contrário. Eles são generalizados em um bloco, cujo código é constantemente melhorado. Este é um caminho direto para a eficiência .
Além disso, se tornarmos globais variáveis importantes, elas serão visíveis em todos os lugares do mecanismo, e será fácil trabalhar com elas, e se definirmos escopos para elas, isso criará uma tarefa supérflua do ponto de vista da eficiência do mecanismo. Novamente, a complicação de acesso. Criando objetos de classe, etc... A tendência de fragmentar o mecanismo em um grande número de funções arruína não só a eficiência, mas também a universalidade dos blocos de código. Acontece que cada tarefa concreta precisa de uma função separada, e a universalidade dos blocos de código simplesmente não é melhorada. O número de chamadas e parâmetros passados também cresce. Isto não contribui para a eficiência do mecanismo, mas esta tendência é realmente promovida pelo OOP.
O OOP é mais eficiente quando um projeto é trabalhado por um grupo de programadores. Neste caso, não se pode passar sem ele. Embora, se pensarmos bem, podemos encontrar aqui também uma maneira de evitá-lo...
Mas, é claro, tudo isso são palavras. Na prática, eu provaria rapidamente do que estou falando.
Peter, é que eu costumava programar apenas com funções e raciocinava quase da mesma forma que você faz agora, e então eu quase através da força (pois a força do hábito é incrível) comecei a programar com aulas. Agora eu posso comparar os dois estados, enquanto você, que não tentou aplicar aulas, não pode. Sem ofensa. Isso só me faz lembrar de outra situação. Sou vegetariano há muitos anos. E com invejável regularidade há pessoas que nunca foram vegetarianas e tentam me esfregar sobre proteínas, aminoácidos essenciais, etc. Eu lhes digo: não estamos em condições de igualdade, eu era comedor de carne e agora sou vegetariano para poder comparar estas duas condições em termos de prática. Você não é e seu conhecimento é apenas teórico, o que nada tem a ver com a prática.
Não perca seu tempo - master OOP.
Você está completamente banido neste fórum, meu amigo. :)) Incluindo eu. ( Não se desespere - o que não nos mata nos torna mais fortes. Eu acredito em você!!!! :))
Não perca seu tempo - mestre OOP.
Você está completamente banido neste fórum, meu amigo. :)) Eu também. ( Não se desespere - o que não nos mata nos torna mais fortes. Eu acredito em você!!!! :))
Comecemos pela questão da necessidade de aulas na implementação de grandes mecanismos. Uma classe é uma concha para um conjunto de funções, e um "grande mecanismo" é um bloco de código que implementa um conjunto de tarefas. Na minha implementação, uma "Grande Máquina" é quase sempre uma função muito grande e um conjunto de pequenas funções que a servem. O chamado "motor". Se você o enche com funções de serviço em uma classe, nada mudará, e se você o enche em classes diferentes, o acesso entre elas se tornará mais complicado e a eficiência do mecanismo diminuirá.
Se o tamanho do mecanismo crescer, é necessário otimizar seu código ou dividir a funcionalidade em arquivos. Não é suficiente? Além disso, a otimização periódica do código em um bloco leva a milagres de eficiência. Ela é constantemente comprimida e requer cada vez mais funções para ser implementada. Esse é o número de funções que diminui, ao contrário. Eles são generalizados em um bloco, cujo código é constantemente melhorado. Este é um caminho direto para a eficiência .
Além disso, se tornarmos globais variáveis importantes, elas serão visíveis em todos os lugares do mecanismo, e será fácil trabalhar com elas, e se definirmos escopos para elas, isso criará uma tarefa supérflua do ponto de vista da eficiência do mecanismo. Novamente, a complicação de acesso. Criando objetos de classe, etc... A tendência de fragmentar o mecanismo em um grande número de funções arruína não só a eficiência, mas também a universalidade dos blocos de código. Acontece que cada tarefa concreta precisa de uma função separada, e a universalidade dos blocos de código simplesmente não é melhorada. O número de chamadas e parâmetros passados também cresce. Isto não contribui para a eficiência do mecanismo, mas esta tendência é realmente promovida pelo OOP.
O OOP é mais eficiente quando um projeto é trabalhado por um grupo de programadores. Neste caso, não se pode passar sem ele. Embora, se pensarmos bem, podemos encontrar aqui também uma maneira de evitá-lo...
Mas, é claro, tudo isso são palavras. Na prática, eu provaria rapidamente do que estou falando.
E há algo a ver com isso. Alan Kay, o criador do OOP, na verdade tinha uma idéia muito diferente do que se entende por OOP hoje. É ainda mais semelhante à sua visão. Tenho a idéia de criar um projeto com um núcleo e serviços que chamem a ele por alguma funcionalidade. E a comunicação entre os elementos acontecerá somente através de eventos-mensagens. Assim que você envia um pedido de evento com os dados, você recebe a resposta ao evento com o resultado. Não há herança, polimorfismo ou inclusão.
A propósito, com esta abordagem a multi-tarefa é mais fácil de organizar, porque todos os elementos por definição trabalham independentemente uns dos outros.
Há algo nele. Alan Kay, o criador do OOP, teve uma idéia diferente do que se entende por OOP hoje. É ainda mais semelhante à sua visão. Tenho a idéia de criar um projeto com um núcleo e serviços que chamem a ele por alguma funcionalidade. E a comunicação entre os elementos acontecerá somente através de eventos-mensagens. Assim que você envia um pedido de evento com os dados, você recebe a resposta ao evento com o resultado. Não há herança, polimorfismo ou inclusão.
A propósito, com esta abordagem, a multitarefa é mais fácil de organizar, porque todos os elementos estão, por definição, trabalhando independentemente uns dos outros.