Czy możesz podać przykład użycia wzorca 'bóg-obiekt' w projektowaniu oprogramowania?

Wzorzec 'bóg-obiekt' charakteryzuje się monolityczną klasą, która zawiera zbyt wiele funkcji i danych, zarządzając niemal wszystkimi aspektami systemu.

Przykład w kontekście rozwoju Androida to klasa Activity lub Fragment, używana do wykonywania wszystkich zadań:

• Wyświetlanie interfejsu użytkownika.
• Obsługa wejścia użytkownika.
• Ładowanie danych z sieci.
• Zapisywanie danych w bazie danych.
• Zarządzanie stanem aplikacji.
• Nawigacja między ekranami.

// Przykład Activity implementującej wzorzec "bóg-obiekt"
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);

        // Inicjalizacja zależności bezpośrednio tutaj
        appDatabase = AppDatabase.getInstance(this);
        networkService = new NetworkService();

        loadDataButton.setOnClickListener(v -> {
            // Ładowanie danych z sieci
            networkService.fetchData(new NetworkService.DataCallback() {
                @Override
                public void onSuccess(String data) {
                    // Zapis do bazy danych
                    appDatabase.dataDao().insertData(new DataEntity(data));
                    // Aktualizacja UI
                    runOnUiThread(() -> dataTextView.setText(data));
                }

                @Override
                public void onError(String error) {
                    // Obsługa błędów
                    runOnUiThread(() -> dataTextView.setText("Error: " + error));
                }
            });
        });

        // Inne bloki logiczne związane z UI, logiką biznesową i danymi mogą być tutaj
        setupRecyclerView();
        handleUserAuthentication();
        manageAppPermissions();
    }

    // Metoda do konfiguracji RecyclerView (może być tutaj)
    private void setupRecyclerView() {
       // Logika konfiguracji RecyclerView...
    }

    // Metoda do obsługi uwierzytelniania użytkownika (może być tutaj)
    private void handleUserAuthentication() {
       // Logika uwierzytelniania...
    }

     // Metoda do zarządzania uprawnieniami (może być tutaj)
     private void manageAppPermissions() {
        // Logika zarządzania uprawnieniami...
     }

    // Inne metody do obsługi różnych zdarzeń i logiki...
}

Taka klasa narusza zasady SOLID, szczególnie zasadę pojedynczej odpowiedzialności (Single Responsibility Principle), co prowadzi do:

• Niskiej czytelności i łatwości utrzymania: Kod staje się obszerny i trudny do zrozumienia.
• Wysokiej spójności: Zmiany w jednej części klasy mogą wpłynąć na inne.
• Trudności w testowaniu: Trudno napisać testy jednostkowe dla takiej klasy.
• Niskiej ponownej użyteczności kodu: Logika jest ściśle powiązana z konkretnym Activity/Fragmentem.

Aby uniknąć 'boga-obiektu' w rozwoju Androida, stosuje się wzorce architektoniczne takie jak MVVM, MVP, MVI, Clean Architecture, które dzielą odpowiedzialność między różne komponenty (ViewModel, Presenter, Interactor itd.).