mas então... qual a vantagem? Seguindo sua linha de raciocínio, não seria mais interessante melhorarmos a forma como escrevemos nosso código de forma procedural ao invés de forçar uma OOP nele?
Muitos anos atrás lembro que compilaram uma lista com implementações de OOP nas mais variadas linguagens, até mesmo arquivos em lote (.bat) do Windows. Como uma curiosidade técnica ou mesmo exercício, é muito interessante, mas pro dia a dia, por adicionar complexidade aonde não deveria existir, é problema.
Nesse caso existe um trade-off entre desempenho e facilidade para escrever o código, já que alguns dos padrões usados para implementar algumas funcionalidades possuem algum custo computacional na sua execução. Porém as vezes é necessário pagar esse custo devido a característica do problema a que está sendo resolvido. Saber escolher quando esse custo deve ser pago, ou pode ser pago sem prejuízos é de grande valor para alguns sistemas. A ideia dessa série é mostrar um ponto de vista sobre orientação a objetos como algo que surge de determinados padrões de código, assim como existem outros padrões de código que resolvem certos problemas (como usar uma variável auxiliar para trocar o valor de variáveis, as funções filter, map e reduce para tratar iteráveis...), dando uma visão de como orientação a objetos é implementada e o que determinadas sintaxes descrevem, e se possível uma ideia de custo para implementar esses padrões ou como transitar entre um código estruturado e orientado a objetos.
Eu não sei exatamente o custo de todos os recursos, e também não conheço nenhum material que teria isso. Porém, considerando o caso de funções virtuais da apresentação do autor do htop, sim, esse custo é quase insignificante para um computador atual, porém pode fazer diferença em um hardware mais limitado, como um Arduino, ou em um servidor que execute a mesma função milhões ou bilhões de vezes em um curto período de tempo, onde uma pequena diferença é escalada várias vezes. Hoje se usa Python para fazer diversos scripts, que conhecidamente não tem o melhor desempenho (salve quando utiliza alguma lib implementada em C ou Fortran), então muitas vezes esse custo é pago sem que o usuário final perceba tanta diferença, e acredito que o custo do interpretador do Python seja muito maior do que a implementação de algumas funcionalidades de orientação a objetos. Rust é vendido como uma linguagem que só se paga o custo do que se usa, porém é necessário de um bom conhecimento de baixo nível para entender esses custos.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
mas então... qual a vantagem? Seguindo sua linha de raciocínio, não seria mais interessante melhorarmos a forma como escrevemos nosso código de forma procedural ao invés de forçar uma OOP nele?
Muitos anos atrás lembro que compilaram uma lista com implementações de OOP nas mais variadas linguagens, até mesmo arquivos em lote (.bat) do Windows. Como uma curiosidade técnica ou mesmo exercício, é muito interessante, mas pro dia a dia, por adicionar complexidade aonde não deveria existir, é problema.
Nesse caso existe um trade-off entre desempenho e facilidade para escrever o código, já que alguns dos padrões usados para implementar algumas funcionalidades possuem algum custo computacional na sua execução. Porém as vezes é necessário pagar esse custo devido a característica do problema a que está sendo resolvido. Saber escolher quando esse custo deve ser pago, ou pode ser pago sem prejuízos é de grande valor para alguns sistemas. A ideia dessa série é mostrar um ponto de vista sobre orientação a objetos como algo que surge de determinados padrões de código, assim como existem outros padrões de código que resolvem certos problemas (como usar uma variável auxiliar para trocar o valor de variáveis, as funções filter, map e reduce para tratar iteráveis...), dando uma visão de como orientação a objetos é implementada e o que determinadas sintaxes descrevem, e se possível uma ideia de custo para implementar esses padrões ou como transitar entre um código estruturado e orientado a objetos.
mas o custo em desempenho neste caso chega a ser insignificante, não? Você tem algum material aí pra gente ver qual seria este custo?
Eu não sei exatamente o custo de todos os recursos, e também não conheço nenhum material que teria isso. Porém, considerando o caso de funções virtuais da apresentação do autor do htop, sim, esse custo é quase insignificante para um computador atual, porém pode fazer diferença em um hardware mais limitado, como um Arduino, ou em um servidor que execute a mesma função milhões ou bilhões de vezes em um curto período de tempo, onde uma pequena diferença é escalada várias vezes. Hoje se usa Python para fazer diversos scripts, que conhecidamente não tem o melhor desempenho (salve quando utiliza alguma lib implementada em C ou Fortran), então muitas vezes esse custo é pago sem que o usuário final perceba tanta diferença, e acredito que o custo do interpretador do Python seja muito maior do que a implementação de algumas funcionalidades de orientação a objetos. Rust é vendido como uma linguagem que só se paga o custo do que se usa, porém é necessário de um bom conhecimento de baixo nível para entender esses custos.