Minha abordagem. O núcleo é o motor. - página 136
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
Bem, se eu não publicar nada grande, não diz que eu não tenho nada grande. É que eu só compartilho as pequenas coisas.
Você pode ficar surpreso, mas eu também tive um momento em que comecei a ficar atolado em estilo processual. Logo quando comecei a desenvolver a GUI. Após alguns meses de trabalho, o código cresceu e ficou tão confuso que eu não consegui mais desenvolvê-lo. Era um beco sem saída.
No entanto, foi aí que eu inventei minha abordagem. Criar um kernel, e ao redor dele, um motor - ou seja, um código que funcione com ele. E tudo correu bem.
Portanto, minha abordagem não é o estilo de procedimento como você pensa.
E eu tentei o OOP. Em algum momento, eu gostei. Mas só até o momento em que eu vi alguns descarados e sem sentido mexendo no código. Entendi que eu estava apenas sofrendo uma lavagem cerebral e comecei a me afastar dela.
Havia muitas coisas desnecessárias lá dentro. Classificação para fins de classificação, código de esmagamento para fins de esmagamento, código de acondicionamento para fins de acondicionamento... Nada disso era consistente com a necessidade racional que os mecanismos exigem. Então, eu comecei a me afastar do OOP.
Havia muitas coisas desnecessárias lá dentro. Classificação para fins de classificação, código de trituração para fins de trituração Nada disso era consistente com a necessidade racional que os mecanismos exigem. Então, eu comecei a me afastar do OOP.
Mentira!
Infelizmente, não é mentira.
O desenho em tela não requer uma embalagem na forma de uma classe. Uma lista de funções é suficiente. Você não precisa de nenhum direito de acesso ao método para sacar. E você sabe disso. Mas você nega este fato. Você nega o óbvio.
É um absurdo!
Não, não é. É uma lógica simples.
Por que você criaria objetos quando se refere a funções de classe, se você pode se referir a eles diretamente?
Entendo se você tem um sistema de classes gigantesco e complicado. Mas você não o criou, e ainda usa funções de chamada através de objetos. Para quê?
Onde está a necessidade prática? Não há. Você tem uma crença abstrata de que é necessário e isso é tudo.
Infelizmente, não é um absurdo.
O desenho em lona não requer uma embalagem de classe. Uma lista de funções é suficiente. Você não precisa de nenhum direito de acesso ao método para sacar. E você sabe disso. Mas você nega este fato. Você nega o óbvio.
Não é bem assim. Meu raciocínio é baseado em lógica simples.
Por que você criaria objetos ao se referir a funções de classe quando você pode se referir a elas diretamente?
Entendo se você tem um sistema de classes gigantesco e confuso. Mas você não o criou, e ainda usa funções de chamada através de objetos. Para quê?
Onde está a necessidade prática? Não há. Há uma crença abstrata de que é necessário, só isso.
Só não preciso ouvir este absurdo. Não creio que haja uma única pessoa neste fórum que possa me ensinar kanvas ( infelizmente..., eu ficaria feliz em estar errado)
Bem, não há muitas pessoas assim por aqui. Eu sou provavelmente um deles. Embora, não seja para ensiná-lo. Apenas para ouvir uma resposta sensata. Por que, ao desenhar, você abordaria as funções de classe através de objetos, se você usa apenas UMA classe?
Por que você usaria uma referência de função de classe através de objetos ao desenhar, se você está usando apenas UMA classe?
traduzir
Você está trabalhando com a classe CCanvas. É o único em seu desenvolvimento.
A classe é parte do sistema. Se for UM, não há sistema.
Então por que criar objetos de classe e se referir a suas funções pelas regras do OOP?
Você PRATICAMENTE não precisa de OOP para lidar com UMA classe.
Mas, você usa o OOP para lidar com UMA classe. Você não precisa de OOP.
Você está trabalhando com a classe CCanvas. É o único em seu desenvolvimento.
A classe é parte do sistema. Se for UM, não há sistema.
Então por que criar objetos de classe e se referir a suas funções pelas regras do OOP?
Você PRATICAMENTE não precisa de OOP para lidar com UMA classe.