Conversando sobre a OLP no salão - página 19

[---]

Volchanski, e você também pode escrever para si mesmo um refrão chamado "Do you need goto?".

[Alexey Volchanskiy]

Andrei:
Verilog

Bem, isso é um pouco agarrado, não é?) É para projetar circuitos eletrônicos.

[Alexey Volchanskiy]

o_o:

Volchansky, e escreva para si mesmo outro tópico "Você precisa ir para...".

Estou correto ao assumir que você tem sentimentos negativos? Por que isso acontece?

[fxsaber]

Комбинатор:

Que diferença isso faz?

Você precisa argumentar sua alegação (OOP não presta) - vá ao Google, digite "OOP" e um par de qualidades negativas, pegue um artigo e sem lê-lo, jogue-o no fórum.

Verdadeiro ou não verdadeiro - não importa. Não importa se eu sou ou não sou. Se houver pessoas atentas como você que se preocuparão em lê-lo e verificá-lo, podemos lançar outro artigo da mesma forma.

Sou um principiante na OOP, por isso admito com grande probabilidade que não me dei conta de alguma desvantagem séria da OOP. Tomei este artigo como um artigo de topo porque achei que parecia ser um recurso sério de programação. Talvez não seja assim, mas eu também não sou um programador.

Como resultado, você provavelmente deveria conduzir um estudo sociológico (ou psicológico) sobre o porquê de uma parte da sociedade (um indivíduo) desenvolver uma aversão quase agressiva e persistente a certas coisas.

[Alexey Volchanskiy]

George Merts:

Eu também não sou apreciado por garotas... E muito mais... O usual, Alexey, são todos animais, nem todos conseguem treiná-los, então você terá muitos homens invejosos.

Mas é melhor você me dizer - onde está seu curso? Eu também vou dar uma olhada...

Você não precisa dele, eu o enviei pessoalmente.

[TheXpert]

fxsaber:

Uma séria desvantagem do OOP é que algo complexo é difícil de projetar, ou seja, é muito difícil fazer uma arquitetura que funcione bem e se encaixe bem sem muletas, então a refatoração é muito, muito comum. Quanto menos experiência você tiver em design, mais inferno você pode fazer dela. A questão é que no OOP a estrutura de um modelo de objeto normalmente projetado tem muitas vezes pouco em comum com objetos reais (como nós os imaginamos)

Então depende do suporte de certos paradigmas por certos idiomas, para que possamos falar sobre "bom/mal", "aplicável/desaplicável".

Por exemplo, o gorila com banana acima mencionado não é um problema de OOP, é um problema de uso descuidado de gerentes de pacotes sem rastreamento de dependência. Especialmente na web hoje em dia

[Koldun Zloy]

fxsaber:

O artigo mente!

Quando li esta declaração, fiquei muito céptico. Rápido rolou para verificar que eu não estava confuso na cabeça:

Destaquei as linhas que o autor do artigo sugere mudar. O resultado não é afetado pela sua substituição. Eu não li o resto do artigo. O mais provável é que tenha sido apontado para este absurdo do autor nos comentários.

O artigo não mente. Existem ali funções virtuais, portanto tudo funciona da maneira como o autor diz.

Mas espero que você não tome isso como um argumento sério contra o OOP.

As mudanças em uma classe base podem ser tão grandes quanto você quiser, e esperar que elas não afetem o trabalho das classes derivadas é apenas uma tolice.

[fxsaber]

Koldun Zloy:

O artigo não mente. Existem ali funções virtuais, portanto tudo funciona da maneira como o autor escreve.

Mas espero que você não pense que este é um argumento sério contra o OOP.

As mudanças na classe base podem ser tão grandes quanto você quiser, e esperar que elas não afetem o trabalho das classes derivadas é uma tolice.

Se virtual, faz sentido e o autor é simplesmente incompetente nas questões e desafios das funções virtuais.

Além disso, se ele tivesse que obter independência, ele deveria ter feito

virtual void Array::addAll( const int &elements[] )
{
  for (int i = 0; i < ArraySize(elements); i++)
//      this.a.add(elements[i]);
    Array:: add(elements[i]);
}

Mas considero o exemplo um bom exemplo para iniciantes. Você precisa entender o que está fazendo.

[fxsaber]

Комбинатор:

Uma séria desvantagem do OOP é que algo complexo é difícil de projetar, ou seja, é muito difícil fazer uma arquitetura que funcione bem e se encaixe bem sem muletas, então a refatoração é muito, muito comum. Quanto menos experiência você tiver em design, mais inferno você pode fazer dela. A questão é que no OOP a estrutura de um modelo de objeto normalmente projetado tem muitas vezes pouco em comum com objetos reais (como nós os imaginamos)

Então depende do suporte de certos paradigmas por certos idiomas, para que possamos falar de "bom/mau", "aplicável/inaplicável".

Por exemplo, o gorila com banana acima mencionado não é um problema de OOP, é um problema de uso descuidado de gerentes de pacotes sem rastreamento de dependência. Especialmente na web, hoje em dia.

Sim, eu encontrei algumas situações em que a arquitetura foi mal escolhida. Às vezes era mais fácil reescrever do zero do que editar.

Na codificação de procedimentos você pode quase sempre compor a arquitetura de um programa enquanto escreve o código. Porque a liberdade e a flexibilidade são totais, mas o crapshoot é enorme.

No OOP, por outro lado, é aconselhável escrever toda a arquitetura no quadro ANTES de escrever a primeira linha de código. Quando você estiver pronto, é muito fácil escrever o código. E se a arquitetura for bem sucedida (apenas experiência e habilidades individuais ajudam aqui), é igualmente fácil de refinar/extender, mesmo que você já tenha esquecido tudo sobre o projeto.

[Andrei01]

Alexey Volchanskiy:

Bem, isso é um grande aperto que você tem aí). É para projetar circuitos eletrônicos.

Não apenas isso.