클래스를 만들고 분류하는 건 아시는대로 "유지,보수" 의 용이성 때문이겠죠.

만일 "절대로" 재활용 될수 없고 내용이 짧은 소스는 불필요하게 메서드화 해서 사용할 필요까지는 없겠죠.

닥치는대로 때려넣은 소스는 현재는 코딩하고 쉽고 직관적이게 보일지 몰라도, 일주일만 그 소스를 안보고 있다가 다시 열게 되면

만든 본인 조차도 헤깔리게 됩니다. 뭐 아시는 내용이라고 생각됩니다.

프로그램이란게 한번 만든다고 해서 절대로 완성되는게 아니라 개발후에도 유지보수 및 수정, 기능 추가가 반드시 필요하며,

이 때, 객체지향적 설계가 제대로 이루어졌다면, 비교적 쉽게 블럭쌓듯이 만들고 수정하겠죠.

이는 규모가 작은 프로젝트보다는 큰 프로젝트에서 실감하시리라 생각됩니다.

제 짧은 지식으로 안드로이드 게시판을 만든다고 했을때, 일단은 DB 파트 클래스, 어댑터 클래스, 커스텀뷰 클래스들, 엑티비트들, 유틸 클래스 정도로 분류하고, 안드로이드의 뷰위젯들은 그대로 사용하기 보다는 커스텀을 많이 하기 때문에 얼마나 다용도로 재활용될수 있게 커스텀 뷰를 만드느냐가 중요하지 않나 싶네요. 그리고 말씀하신 단순한 기능을 가진 메서드들은 별도의 유틸 클래스에서 static 화하여 정의하고 사용할것 같습니다.

만일 엑티비티간 객체를 전달해야한다고 했을때는 parcel, serialize 를 활용하면 가능은 하겠으나 공용적으로 활용되는것이라면 이 역시 static 하여 활용할 것 같습니다. 

객체지향은 말 그대로 객체단위로 쪼개서 설계를 하고

해당 객체의 모든 책임은 그 객체에게 위임한다입니다.

글 내용을 보면 계속 '기능'의 관점으로 접근하시는 것 같은데

약간 다릅니다.

기능은 오히려 객체의 행동(Behavior)에 더 가깝습니다. 자바로 치면 메소드겠져.

기능단위로 쪼개다 보면 메소드로 나뉘어야 할 것들이 객체로 쪼개지는 모습을 보게 됩니다.

방법없습니다. 많이 고민하고 많이 설계하고 많이 구현해보고 재사용하면서 리펙토링 해보고

리뷰하고 이거 반복입니다.