Princípio de Responsabilidade Única | SOLID com C#: princípios da programação orientada a objetos

Não sei se esse princípio faz sentido em todos os casos. Se trabalho com logs, ou com o padrão observer, sempre haverá uma segunda responsabilidade:

Excluir dados e depois salvar no log.
Atualizar dados e notificar os observadores.

Olhando o código abaixo, não vejo como seria possível notificar a mudança da propriedade fora do SET. O que consequentemente faz o SET ter duas reponsabilidades: atribuição de valor e invocação de evento.

#r "Microsoft.Win32.SystemEvents"
using System.ComponentModel;
using System.Runtime.CompilerServices;

class Pessoa : INotifyPropertyChanged
{
    private string nome;

    public event PropertyChangedEventHandler? PropertyChanged;

    private void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
    {
        PropertyChanged?.Invoke(this, new(propertyName));
    }

    public string Nome
    {
        get => nome;
        set
        {
            if(nome == valor)
            {
                return;
            }
            nome = value;
            NotifyPropertyChanged();
        }
    }
}

Olá Bruno

Entendo sua dúvida em relação ao Princípio de Responsabilidade Única. Esse princípio não significa que uma classe deve ter apenas uma responsabilidade absoluta, mas sim que ela deve ter uma única razão para mudar. Em outras palavras, uma classe deve ter um único motivo para ser alterada.

No seu exemplo, você mencionou o uso de logs e do padrão Observer, que podem parecer uma segunda responsabilidade além da atribuição de valor e invocação de evento no SET. No entanto, é importante analisar se essas funcionalidades estão diretamente relacionadas à classe em questão.

No caso de logs, se a classe Pessoa tiver a responsabilidade de fazer log apenas para si mesma, então essa funcionalidade está alinhada com a responsabilidade da classe. Porém, se a classe Pessoa também fizer logs para outras entidades, então seria interessante extrair essa lógica para uma classe separada, como uma classe de log.

Já no caso do padrão Observer, se a classe Pessoa tiver a responsabilidade de notificar observadores apenas quando o valor da propriedade Nome for alterado, então essa funcionalidade também está alinhada com a responsabilidade da classe. Porém, se a classe Pessoa também tiver a responsabilidade de notificar observadores em outros momentos, então seria interessante extrair essa lógica para uma classe separada, como uma classe de notificação.

Quanto à sua pergunta sobre como notificar a mudança da propriedade fora do SET, é possível utilizar o evento PropertyChanged para isso. No exemplo que você compartilhou, o evento PropertyChanged é invocado dentro do SET da propriedade Nome. Isso significa que sempre que o valor da propriedade Nome for alterado, o evento será disparado e os observadores serão notificados.

Em relação ao contexto compartilhado, vejo que você está com dúvidas sobre a extração de métodos em diferentes classes. É importante evitar a duplicação de código, pois isso pode levar a problemas de manutenção no futuro. No seu caso, você mencionou que copiou e colou o código de um lugar para outro, o que não é uma abordagem recomendada.

Uma solução para evitar a duplicação de código é extrair a lógica comum para uma classe separada e reutilizá-la nas diferentes classes que precisam dessa lógica. No exemplo que você compartilhou, a ideia é criar uma classe chamada LeilaoDAO, responsável por operações de acesso aos dados. Essa classe pode conter os métodos que fazem acesso ao Entity Framework Core para trazer a lista de dados ou alterar os dados na base.

Dessa forma, as classes LeilaoController e LeilaoAPIController podem utilizar a classe LeilaoDAO para realizar essas operações, evitando a duplicação de código. É importante ressaltar que essa é apenas uma sugestão de abordagem e pode variar dependendo do contexto e dos requisitos do seu projeto.

Espero ter ajudado a esclarecer suas dúvidas! Se tiver mais alguma pergunta, é só me dizer. Bons estudos!