[...] ninguém conseguiu me explicar claramente POR QUE é tão importante restringir-se ao escopo privado para impedir que outros programadores quebrem algum tipo de consistência na organização de dados.
Em uma equipe pequena o suficiente com uma base de código pequena o suficiente para ser realmente bem coordenada com bons padrões (pode ser apenas uma pessoa), geralmente você pode encontrar um software confiável que deixa todos os dados em aberto para que qualquer pessoa possa tocar em todos os campos de dados de uma structexposição aberta e com a structdefinição aberta para qualquer pessoa que inclua esse cabeçalho para acessar. A lei de Murphy nem sempre se aplica nesses casos.
Mas eu trabalhei no cenário oposto de uma enorme base de código com muitos milhões de LOC, datados dos anos 80, com uma grande equipe de desenvolvedores de todo o mundo, onde só nos encontramos cara a cara a cada poucos meses, de maneira pouco coordenada, às vezes mal falando o mesmo idioma, sem padrões de codificação, exceto o SDK que as pessoas geralmente não seguiam de qualquer maneira, sem testes de unidade / integração, usando o SVN sem ramificação e às vezes passando seis semanas sem verificar o código, apenas para nos bombardear com bugs, e Não foi até então que eu realmente entendi o valor da informação ocultando e mantendo os invariantes .
Lidei com os bugs em que nem conseguia reproduzir o problema de maneira consistente na minha máquina e, às vezes, nenhum de nós conseguia entre toda a equipe. E quando finalmente consegui reproduzir com sorte o problema relatado pelo usuário ou algo semelhante a ele após todos os tipos de tentativas e erros (e as tentativas e erros geralmente levavam horas porque a ineficiência do nosso software combinava com a execução em depuração da produção final do usuário os dados geralmente demoravam mais de 15 minutos apenas para carregar os dados); eu o rastreava para algo como a structpara um tipo de string que tinha um lennúmero negativo para o lixo, como um comprimento de string -921141282.
Isso nunca deveria acontecer, mas quem fez isso? Então eu tive que definir pontos de interrupção de memória e descobrir e, quando finalmente o fiz, era como uma interação em cascata de variáveis não inicializadas sendo usadas aritmeticamente, o que acabou resultando em um lencampo de string sendo definido como um número de lixo negativo, e esse código não foi modificado em anos. Voou sob o radar.
E durante todo esse tempo, depois de encontrar muitos bugs como esse, pensei comigo: quanto mais confiável seria o nosso software se apenas o usasse getterse setters? Getters e setters são geralmente indicativos dos piores tipos de designs de interface possíveis, mas um setter pode pelo menos desencadear uma falha de afirmação se alguém tentar definir o comprimento de uma string com um valor negativo. Poderíamos ter pegado esses anos de insetosantes, no momento exato em que foi introduzido em segundos, não no culminar de horas de esforço investigativo. E isso é apenas pensar egoisticamente como desenvolvedor; ele não cobre todas as horas de luto que poderia ter salvado os usuários e a equipe de controle de qualidade também. Você sabe que seu sistema está em um péssimo lugar quando está sonhando com o quão melhor poderia ser se usasse setters e getters em face dos últimos 35 bugs que você passou a noite inteira consertando.
Tivemos até casos em que structsforam documentados de maneira que ninguém mais deveria acessar esses campos de dados, apenas para encontrar locais no sistema que acessam esses campos de dados.
Portanto, esses são os tipos de coisas que você pode realmente apreciar ao máximo ao enfrentar o pior cenário, mas muitas vezes o fará a menos que tenha a sorte de passar o resto da vida trabalhando em bases de código menores com equipes bem coordenadas e padrões de codificação fortes.
O que é um código bonito em C ++ [...]?
Essa é difícil. Eu ainda estou tentando descobrir isso. A maior parte do código que considero bonito que escrevi ao longo dos anos, ou pelo menos confiável, relativamente atemporal e estável (sem precisar / querer mudanças) foi escrita em C e, recentemente, em Lua. Ainda luto para escrever código C ++ que parece passar no teste do tempo a ponto de não refletir sobre isso alguns anos depois e pelo menos desejar poder alterá-lo. Eu sinto que ficou mais fácil desde C ++ 11, mas preciso de alguns anos para descobrir como meu código consegue sobreviver sem precisar de alterações para ter certeza. Para mim, a "beleza" definitiva é a "estabilidade", como no código que não precisa e nem tenta outras alterações, mas ainda permanece relevante e útil nos próximos anos, já que "