Antes de começarmos a aprender os novos recursos avançados do C ++, precisamos falar sobre alguns dos princípios de bom design de classe. Por que um bom design de classe é importante? Isso porque sem um bom design de classe, a capacidade de estender a funcionalidade do software ou adicionar novos recursos a ele é severamente diminuído. Então, vamos falar sobre alguns dos princípios que são mais úteis e vamos começar com o princípio denominado DRY. DRY é uma sigla que significa não se repita, o que significa que você deve escrever código para fazer algo ou descreva algo uma vez e apenas uma vez. Então, o que exatamente isso significa? Vamos dar uma olhada em um exemplo. Você tem uma classe chamada DoNotRepeat, que é destacado. E essa classe tem algumas variáveis, algumas variáveis de membro chamadas integer_var, double_var e string_var. Ele também tem funções para definir essas variáveis e também recuperar seus valores. Agora vamos considerar a outra classe, chamou essa classe de Repetida. Dê uma olhada se ele tem um layout muito semelhante. Ele tem variáveis de membro semelhantes chamadas integer_var, double_var, string_var e tem funções de interface semelhantes para definir essas variáveis e recuperar alguns de seus valores, mas também para calcular algum outro valor com base nesses valores. Então, se você olhar para essas 2 classes e você vai entender que se você precisar alterar um recurso, isso é o mesmo entre eles, você provavelmente precisará fazer alterações duas vezes. Você precisará alterar o DoNotRepeat e você também precisará alterar Repetido, o que é praticamente possível, mas é uma ideia muito ruim porque as mudanças do código que tem que ser repetido 2, 3, 4 vezes é uma ótima maneira de introduzir bugs em seu programa. Então C ++ fornece a você um mecanismo que permitirá que você escreva o código que é comum entre as 2 classes uma vez e apenas uma vez, que é chamado de herança. E estaremos falando sobre isso em algumas das seções a seguir. Outro princípio de que precisamos falar sobre o encapsulamento. E esse princípio é muito importante. O encapsulamento é um princípio pelo qual as propriedades do objeto está protegido de acesso direto por funções ou classes externas. Isso não é a única coisa que o encapsulamento necessita. Objetos encapsulados adequadamente têm interface muito estreita, o que significa que um usuário externo só pode fazer algumas coisas com os objetos, mas o número de componentes e funções internas dentro do objeto podem ser grandes e eles podem fazer algumas coisas por conta própria, mas você não pode executar essas funções sem acessar a interface do objeto de encapsulamento. Para este exemplo, vamos dar uma olhada em uma classe de objeto chamada Mixer, que descreve uma batedeira de cozinha em pé. No meu exemplo, Estou descrevendo um mixer Kitchen Aid e, como você pode ver, tem uma interface muito simples. Você pode começar, parar, misturar. Você pode remover o copo, você pode instalar o copo, você pode desbloquear o mixer, bloquear o mixer, e você também pode aumentar o mixer. Essas são as únicas funções que você pode executar no objeto devidamente encapsulado. Você também sabe que o mixer contém engrenagens, motor, controlador e alguns outros componentes, mas você não tem acesso a eles como um usuário normal do objeto. Você sabe que eles existem individualmente. Eles têm muito pouco interesse para você e você não precisa controlá-los ou tem a função de controlá-los exceto através do objeto. O próximo princípio que veremos é chamado de princípio de responsabilidade única. Esta é uma maneira elegante de dizer essa classe deve ser responsável por uma coisa e apenas uma coisa. Se uma classe, por exemplo, é responsável por descrever um pedido de venda, não deve ser responsável por salvar as informações desse pedido de vendas para o banco de dados nem deve ser responsável por se converter para outro formato como XML. Por que não é uma boa ideia? Bem, na verdade é muito simples. Para o banco de dados, por exemplo, o objeto precisa ter as informações do banco de dados. Então, se você tem muitos pedidos de vendas, cada um precisa ter uma cópia das informações do banco de dados, que está sujeito a erros e torna o código muito confuso de ler e muito difícil de manter. Então, a menos que seja absolutamente necessário, dependências como essas devem ser evitadas. O último princípio sobre o qual falaremos nesta seção é chamado de princípio aberto-fechado. O princípio afirma que a aula deve ser aberta à extensão, mas perto da modificação. Então, o que exatamente isso significa? Vamos dar uma olhada em algo para validação de regra. Você tem uma classe chamada RuleValidation, que tem um método de interface chamado regra de validação para o qual você coloca um objeto de regra, que você mesmo pode descrever. E então você tem a lógica de validação no método e isso significa que toda vez que você adiciona uma nova regra ou um novo tipo de validação, você terá que mudar a classe RuleValidation para acomodar a nova funcionalidade. A melhor maneira de fazer isso seria ter uma classe chamada ValidateRule, que terá uma função pública chamada validate. Então, para cada tipo de validação que você deseja, você criará um objeto desta classe. E você pode estender isso novamente usando herança. Você pode estendê-lo por, fornecer um tipo específico de validação. E então você pode realmente ter validação de regra, tem um conjunto de objetos de regras de validação, que validaremos chamaremos em sucessão até que a regra seja válida, ou causará a falha em todos eles. Desta forma, o objeto de validação da regra não tem que mudar muito para acomodar novas regras de validação. A única coisa que você vai precisar adicionar é uma função chamada addRuleValidator, que terá o objeto de regra de validação, e irá adicioná-los para o conjunto de validação. Adicione a regra de validação. E então você pode simplesmente adicionar muitas validações quantas validações você quiser, que é exatamente como é descrito no princípio aberto-fechado.
