Podes dar um exemplo do uso do padrão 'objeto deus' no design de software?

O padrão 'objeto deus' é caracterizado por uma classe monolítica que contém funções e dados demais, gerindo quase todos os aspetos do sistema.

Um exemplo no contexto do desenvolvimento Android é a classe Activity ou Fragment, usada para realizar todas as tarefas:

• Exibir a interface de utilizador.
• Processar a entrada do utilizador.
• Carregar dados da rede.
• Guardar dados na base de dados.
• Gerir o estado da aplicação.
• Navegar entre telas.

// Exemplo de Activity que implementa o padrão "objeto deus"
public class GodObjectActivity extends AppCompatActivity {

    private TextView dataTextView;
    private Button loadDataButton;
    private AppDatabase appDatabase;
    private NetworkService networkService;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_god_object);

        dataTextView = findViewById(R.id.data_text_view);
        loadDataButton = findViewById(R.id.load_data_button);

        // Inicialização de dependências aqui mesmo
        appDatabase = AppDatabase.getInstance(this);
        networkService = new NetworkService();

        loadDataButton.setOnClickListener(v -> {
            // Carregar dados da rede
            networkService.fetchData(new NetworkService.DataCallback() {
                @Override
                public void onSuccess(String data) {
                    // Guardar na base de dados
                    appDatabase.dataDao().insertData(new DataEntity(data));
                    // Atualizar UI
                    runOnUiThread(() -> dataTextView.setText(data));
                }

                @Override
                public void onError(String error) {
                    // Lidar com erros
                    runOnUiThread(() -> dataTextView.setText("Error: " + error));
                }
            });
        });

        // Outros blocos lógicos relacionados com UI, lógica de negócio e dados podem estar aqui
        setupRecyclerView();
        handleUserAuthentication();
        manageAppPermissions();
    }

    // Método para configurar RecyclerView (pode estar aqui)
    private void setupRecyclerView() {
       // Lógica de configuração do RecyclerView...
    }

    // Método para lidar com autenticação de utilizador (pode estar aqui)
    private void handleUserAuthentication() {
       // Lógica de autenticação...
    }

     // Método para gerir permissões (pode estar aqui)
     private void manageAppPermissions() {
        // Lógica de gestão de permissões...
     }

    // Outros métodos para lidar com eventos e lógica...
}

Este tipo de classe viola os princípios SOLID, especialmente o princípio de responsabilidade única (Single Responsibility Principle), levando a:

• Baixa legibilidade e manutenção: O código torna-se extenso e difícil de entender.
• Alta coesão: Alterações numa parte da classe podem afetar outras.
• Dificuldade de testar: É difícil escrever testes unitários para tal classe.
• Baixa reutilização de código: A lógica está fortemente ligada a um Activity/Fragment específico.

Para evitar o 'objeto deus' no desenvolvimento Android, usam-se padrões arquiteturais como MVVM, MVP, MVI, Clean Architecture, que dividem a responsabilidade entre diferentes componentes (ViewModel, Presenter, Interactor, etc.).