Махач Имангазалиев

Начать неплохо бы с понимания того, что такое DI. Обратимся к википедии:

Внедрение зависимости (англ. Dependency injection, DI) — процесс предоставления внешней зависимости программному компоненту.

Если выражаться не канцеляритом, а обычным русским языком, то DI - это когда вы своему компоненту (например, классу) предоставляете нужные для него зависимости извне, а не создаете их сами в конструкторе, или через инициализацию в месте объявления поля. То есть не так:

public class Api {
	....
	private final HttpClient client = new OkClient();
}

А, например, так:

public class Api {
	....
	private final HttpClient client;

	public Api(@NonNull HttpClient client) {
		this.client = client;
	}
}

И что нам это даёт?

Ну, очевидно, нам теперь проще менять зависимости. Нужна вам другая реализация абстрактного класса HttpClient - взяли, и передали её через конструктор, или через метод-setter. В случае с первым куском кода, вам пришлось бы ещё и класс Api переписывать, что в случаях, отличных от тривиальных, может привести к ошибкам. Получается, что ваш класс теперь закрыт от изменений (смотрим Open/Closed Principle).

Окей, а на практике-то какие бенефиты?

Во-первых, вы теперь можете написать инициализацию вашей программы через конфигурационные файлы. Скажем, на старте будет читаться простенький текстовый файл, который определяет, какой httpclient использовать, какие настройки доступа к бд применять и так далее, и, исходя из этого, будут определяться зависимости.
Во-вторых, вам теперь существенно проще писать тесты. Написали вы, скажем, какой-нибудь парсер, который принимает InputStream, содержащий в себе данные json-объекта, как-то хитро его парсит, и выдаёт вам объект вашей бизнес-модели. В приложении этот парсер будет принимать на вход реализацию InputStream'а, которая берёт данные из сети, а в тестах - реализацию, которая просто читает файл с диска (потому что тесты должны выполняться часто и быстро, и ваша задача в тесте - протестировать ваш парсер, а не скорость сетевого соединения).

Вот, в общем-то, и всё. А Dagger - это просто библиотека, которая автоматизирует ручное внедрение зависимостей, равно как и другие DI-библиотеки.

P.S. В некоторых случаях чрезмерное увлечение DI может привести к нежелательным эффектам, вроде чрезмерного усложнения кода, поэтому внедряйте аккуратно. Понимание приходит с опытом.

Можно сделать так:
Некий интерфейс:

interface Item {
    Fragment getFragment()
}

и две его реализации:

class StepItemImpl implements Item {
    private StepsMenuItem data;
    StepItemImpl(StepsMenuItem data) {
        this.data = data;
    }
    @Override
    public Fragment getFragment() {
        return StepFragment.newInstance(data.getFileName());
    }
}

class WhatNextImpl implements Item {
    @Override
    public Fragment getFragment() {
        return WhatNextFragment.newInstance(...);
    }
}

далее, вы оборачиваете в эти класс свои данные и у вас получается список:

List<Item> mItems;
...
    @Override
    public Fragment getItem(int position) {
        return mItems.get(position).getFragment();
    }
...
    @Override
    public int getCount() {
        return mItems.size()+1;
    }
/code>
Как-то так.

Махач Имангазалиев , вы бы воспользовались поиском на форуме для начала. Совсем недавно задавался подобный вопрос. Вот пример моей структуры в простом проекте:

ru.mycompany.myapp
├─ activities
├─data
   └─  dao
├─views
   ├─ adapters
   ├─ customview
   ├─ fragments
   └─ widgets
├─ network
   └─api
     └─responce
├─ models
└─utils