Minha abordagem. O núcleo é o motor. - página 137
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
Peter, você realmente entendeu mal algo sobre a aplicação do OOP.
Nikolai, você está construindo HIERARCHY ou criando mecanismos de desenho?
Se você constrói HIERARCHY (não se importa em desenhar), então é claro porque você precisa de OOP em todos os lugares.
Se você está criando um mecanismo de desenho que funciona com base em UMA classe, então você não precisa da própria Classe.
Classe, - a partir da palavra Classificação. A classificação é uma divisão por atributos. A classe é uma derivada da Classificação. Se há uma Classe, então não há Classificação.
Portanto, a classe, nesse caso, é uma besteira abstrata. Isso não faz sentido.
...
Fica-se com a impressão de que o próprio OOP se antecipa ao mecanismo que supostamente deve servir. Ou seja, o mecanismo deve lutar pela integridade e, portanto, pelo menor número de seus blocos. Mas o OOP força esses blocos a se multiplicarem por qualquer razão. Como resultado, a estrutura dos mecanismos é esfarrapada e eles não funcionam bem. E eles se desenvolvem ainda pior.
...
Bem, talvez você devesse estudar o OOP pelo menos um pouco em vez de fantasiar sobre isso? Você nem sequer fantasia, você está delirando.
Nikolai, já lhe ocorreu que seu amor pela OOP não é justificado por quase nada além de razões abstratas?
Digamos, se você estivesse criando mecanismos gigantescos com este OOP, ficaria claro porque você precisa tanto dele. Você justificaria especificamente por que você precisa do OOP. Mas, você cria mecanismos relativamente pequenos. Não há ali código suficiente para tirar conclusões sobre as desvantagens e vantagens desta ou daquela abordagem. Mas você continua falando de OOP de qualquer maneira. Embora o OOP seja apenas uma ferramenta e não tenha sentido por si só. Isto é, se não houver nenhum mecanismo a ser feito, o OOP não é necessário. Mas se existe um mecanismo, ele deve ser sério o suficiente para exigir o OOP enquanto o cria.
A maioria daqueles que defendem o OOP não fazem nada de sério. Eles só fazem pequenas coisas. Entretanto, sua crença no OOP é inabalável. Outros que fazem mecanismos muito mais sérios são muito menos propensos a gritar sobre a grandeza do OOP. Alguns até falam com críticas (já houve algumas vezes).
Portanto, sua argumentação precisa ser apoiada pela prática, não apenas pela teoria. Eu, por exemplo, posso argumentar sobre os benefícios do OOP no desenvolvimento de GUI com Anatoly, porque podemos comparar soluções e suas nuances na prática. Mas, com você, eu não posso desenvolver meu argumento porque você não o entenderá. Você vai, mas não vai entender (sem ofensa). O anatoly, pelo contrário, pode entendê-lo muito bem. A diferença na experiência de criação de mecanismos globais é a principal razão para o mal-entendido.
SZY. Como praticante, direi o seguinte: A abordagem deve ser tal que maximize o potencial do cérebro de um determinado programador. Encontrei essa abordagem para mim mesmo.
Fantasias sobre o OOP estão ficando cada vez mais selvagens...
A seriedade do trabalho é determinada pelo resultado, não pelo número de anos passados.
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ê está negando o óbvio.
Sim, para comer uma banana, é preciso descascar a pele. Mas se uma vaca tem chifres, então todo mundo com chifres é uma vaca.
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ê se referiria às funções de classe através de objetos, se você usa apenas UMA classe?
Como as funções de desenho na tela se referem apenas ao desenho na tela e nada mais, então não há razão para mantê-los em um recipiente separado, é por isso que eles são coletados em uma classe. Mas você não entenderia de qualquer forma.
Nikolai, você está construindo HIERARCHY ou criando mecanismos de desenho?
Se você constrói HIERARCHY (não se importa em desenhar), então é claro porque você precisa de OOP em todos os lugares.
Se você está criando um mecanismo de desenho que funciona com base em UMA classe, então você não precisa da própria Classe.
Classe, - a partir da palavra Classificação. A classificação é uma divisão por atributos. A classe é uma derivada da Classificação. Se há uma Classe, então não há Classificação.
Portanto, a classe, nesse caso, é uma besteira abstrata. Isso não faz sentido.
O que a hierarquia tem a ver com isso? O OOP faz amplo uso da herança. ...e mais um monte de fantasia desenfreada...
...e a cereja em cima do bolo:
Eu tinha um projeto semelhante com outro software bastante caro, e também implementei a idéia utilizando soluções de trabalho (para não comprar módulos adicionais).
Eu tinha um projeto semelhante em outro software especial, bastante caro, também implementei a idéia por meio de soluções (para não comprar módulos adicionais), funcionou, mas com alguns clientes acabaram em um impasse e o tempo foi desperdiçado
Mas era um campo completamente diferente, e era fácil encontrar clientes