Можешь привести пример использования паттерна 'бог-объект' (god object) в проектировании программного обеспечения?

Паттерн 'бог-объект' характеризуется монолитным классом, который содержит слишком много функций и данных, управляя почти всеми аспектами системы.

Пример в контексте Android-разработки — класс Activity или Fragment, используемый для выполнения всех задач:

• Отображение UI.
• Обработка пользовательского ввода.
• Загрузка данных из сети.
• Сохранение данных в базу данных.
• Управление состоянием приложения.
• Навигация между экранами.

// Пример Activity, реализующей паттерн "бог-объект"
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);

        // Инициализация зависимостей прямо тут
        appDatabase = AppDatabase.getInstance(this);
        networkService = new NetworkService();

        loadDataButton.setOnClickListener(v -> {
            // Загрузка данных из сети
            networkService.fetchData(new NetworkService.DataCallback() {
                @Override
                public void onSuccess(String data) {
                    // Сохранение в базу данных
                    appDatabase.dataDao().insertData(new DataEntity(data));
                    // Обновление UI
                    runOnUiThread(() -> dataTextView.setText(data));
                }

                @Override
                public void onError(String error) {
                    // Обработка ошибок
                    runOnUiThread(() -> dataTextView.setText("Error: " + error));
                }
            });
        });

        // Другие логические блоки, связанные с UI, бизнес-логикой и данными могут быть здесь
        setupRecyclerView();
        handleUserAuthentication();
        manageAppPermissions();
    }

    // Метод для настройки RecyclerView (может быть здесь)
    private void setupRecyclerView() {
       // Логика настройки RecyclerView...
    }

    // Метод для обработки аутентификации (может быть здесь)
    private void handleUserAuthentication() {
       // Логика аутентификации...
    }

     // Метод для управления разрешениями (может быть здесь)
     private void manageAppPermissions() {
        // Логика управления разрешениями...
     }

    // Другие методы для обработки различных событий и логики...
}

Такой класс нарушает принципы SOLID, особенно принцип единой ответственности (Single Responsibility Principle), что приводит к следующим проблемам:

• Низкая читаемость и поддерживаемость: Код становится объемным и сложным для понимания.
• Высокая связность: Изменения в одной части класса могут повлиять на другие.
• Сложность тестирования: Тяжело писать юнит-тесты для такого класса.
• Низкая возможность повторного использования кода: Логика тесно связана с конкретным Activity/Fragment.

Для избежания 'бог-объекта' в Android-разработке используются архитектурные паттерны, такие как MVVM, MVP, MVI, Clean Architecture, которые разделяют ответственность между различными компонентами (ViewModel, Presenter, Interactor и т.д.).