Ela também facilita a manutenção na medida em que é mais fácil para um humano lembrar das entidades envolvidas na resolução do problema do que de seus comportamentos individuais. Imagine que você precisa dar manutenção em um projeto seu mesmo, mas depois de muitos anos. Se há um problema relacionado à impressão de pedidos, deve ser mais fácil você simplesmente gastar seu tempo analisando código da classe Pedido do que procurar entender e encontrar as funções relacionadas no meio de diversos arquivos de código.
P.S.: Note como alguém que argumentasse que basta organizar as funções em arquivos intimamente relacionados estaria, de certa forma, usando esse paradigma sem saber! hehehe
Mas vale lembrar que nem tudo é vantagem. Como também foi citado em comentários, uma equipe que não estudou e não conhece o paradigma pode gastar tempo precioso aprendendo. A experiência (e o grande número de perguntas aqui no SOPT) indicam que há uma bela de uma curva de aprendizado envolvida. Além disso, para aplicações críticas em que velocidade de execução e/ou uso de memória são requisitos não funcionais importantes, o esforço computacional adicional oriundo das facilidades providas por recursos da OO (como, por exemplo, a sobrecarga de métodos e operadores, ou os construtores de cópia) podem trazer desvantagens relevantes.
Ótima resposta. Concordo: você faz um ótimo código OO e um profissional que não entende OO não poderá dar manutenção nele. Mas o inverso também é verdadeiro: você faz um código macarrônico (e tenho visto que ausência de OO em Delphi/C# é sempre macarrônico) e apenas você, com sorte, poderá dar manutenção nele. Então enquanto há o custo da curva de aprendizado de OO, do outro lado há também o custo da curva de aprendizado do próprio código. Pelo que tenho observado, o custo do segundo é bem maior, e é mais fácil encontrar por aí alguém que entenda OO do que alguém que entenda seu código ruim. – Caffé 14/04/15 às 19:48
Geralmente, se você tentar defender a orientação a objetos em uma empresa que não coloca-a como uma premissa básica, a primeira coisa que irá escutar é: -Pra que? funciona não fuinciona? Em time que tá ganhando a gente não mexe.
Na verdade, o código macarronico tem suas vantagens. É fácil de fazer, é muito rápido de desenvolver e geralmente, programas que entram em produção utilizando essa "arquitetura" rodam assustadoramente mais rápido do que seus primos almofadinhas.
Pra vc arrumar um código macarronico que vc fez é uma coisa. Outra completamente diferente é colocar esse software na mão de um novo desenvolvedor. O cara vai ficar louco. Outro problema surge quando alguem quiser melhorar esse software. Aquela velha história...meu software vende maças. Mas agora eu quero vender uva...
Dependencia de Profissionais - Quem entende um código macarronico é só seu criador. Se outro profissional por as mãos, provavelmente passará meses decifrando o que o outro desenvolvedor fez. Diante disso, cria-se uma relação de dependencia entre a empresa e o desenvolvedor do sistema. Esse profissional passa a ficar mais caro a cada dia, afinal o sistema não pode parar e não é fácil achar alguém que consiga dar continuidade ao projeto. O sujeito se torna virtualmente insubstituível, o que não é bom pra empresa.
Manutenção e Evolução - Como disse anteriormente, o software é de vender maça e não uva. Aí começam as gambiarras. Você olha o código e começa achar um monte de "flags" e um monte de "if's" do tipo: if(Uva)...em pouco tempo o software não comporta mais manutenção. Aí dão uma de louco e reescrevem todo o código, porque é rápido fazer sem padrões de projeto. O ciclo continua e o criador do software uma hora dessas tá ganhando uns mil reais a mais. E todo mundo acha que ele é o cara, pq ninguém conseguiu mexer no software. Outro fator importante é a gestão de mudanças. Como fazer gestão de mudanças em um software onde provavelmente nem o programador sabe dizer quais as ramificações daquela mudança?
Efeitos colaterais de evolução - Já reparou que ao alterar uma funcionalidade em um software desenvolvido fora dos padrões da OOP sempre surgem erros inesperados em outras áreas do software? Claro, afinal aquele campo que vc precisou remover do CRUD afeta outras 300.000 áreas do software. Esses efeitos colaterais prejudicam diretamente o negócio da empresa, gerando prejuízos.