이름이 긴 거는 이름이 명확하지 않은 것 보다는 훨씬 낫습니다. 그리고 naming을 할 때는 일관성이 중요합니다. 다른 클래스에 Activity, Fragment를 붙이셨다면, 새로운 클래스도 그렇게 하시는게 훨씬 낫겠죠. 만약 새로운 클래스 이름이 너무 길어서 Activity나 Fragment의 더이상 사용하지 않기로 했다면, 다른 클래스들도 그렇게 하시는게 낫구요.
한가지 더 중요한 사실은 이름이 이상하게 길다는 것은, 해당 클래스가 너무 많은 일을 하고 있다는 반증일 수 있습니다. 해당 프레그먼트가 어떤 역할을 하는지 코드를 다시 확인해 보시고, 너무 많은 역할을 한 다면, 서브클래싱이나, 커스텀 뷰 또는 MVC, MVP, MVVM 같은 패턴 등을 통해 역할 분담을 하셔야 합니다. SOLID principle이라고 OOP에서 중요한 원칙이 있는데, 좋은 아키텍쳐 일 수록, 이 원칙을 좀 더 충실하게 따른다고 보시면 됩니다. 첫번째 S가 Single Responsibility입니다. 클래스는 한가지 책임만 가져야 하며, 변경의 이유는 한가지이어야 합니다. 따라서 해당 프레그먼트가 너무 많은 일을 하고 있다면, 잘게 쪼개시는게 테스트를 위해서나 유지보수를 위해 좋습니다. 좋은 코드는 자연스럽게 클래스 작성을 많이하게 만듭니다.
