나는 이클립스를 사용하여 안드로이드에서 몇 가지 기본 프로그래밍을 속이고있다. 나는 현재 책을보고 있으며 책에 쓰여있는 샘플 코드를 가지고 놀고있다.android object oriented programming
나는이 특정 책에서 지금까지 모든 예제가 주요 활동에 보조를 맞추고 있음을 알았습니다. 나는 이것이 전통적인 자바 배경에서 나온 것처럼 객체 지향 프로그래밍 연습이라고는 생각하지 않는다.
모바일 플랫폼의 일반적인 관행입니까? 클래스가 모두 자신의 파일에 포함되어서는 안됩니까?
클래스가 모두 자신의 파일에 포함되어서는 안됩니까?
반드시 Android가 아니어야합니다. Activity은 '특수 사례'클래스입니다. 당신이 이미하지 않은 경우, 나는
액티비티가 사용자 인터페이스를 하나의 화면을 나타냅니다 ... 당신이 Application components에서 '활동'섹션을 Application Fundamentals을 읽고 특히 권하고 싶습니다. 예를 들어 전자 메일 응용 프로그램에는 새 전자 메일 목록, 전자 메일 작성 활동 및 전자 메일 읽기 활동이 표시된 활동이 하나있을 수 있습니다. 전자 메일 응용 프로그램에서 일관된 사용자 경험을 형성하기 위해 여러 활동이 함께 작동하지만 각 활동은 서로 독립적입니다. 따라서 다른 응용 프로그램이 이러한 활동 중 하나를 시작할 수 있습니다 (전자 메일 응용 프로그램에서 허용하는 경우). 예를 들어, 카메라 응용 프로그램은 사용자가 사진을 공유 할 수 있도록 새 메일을 작성하는 전자 메일 응용 프로그램에서 활동을 시작할 수 있습니다.
굵게 강조 표시된 부분에 유의하십시오. 요점은 Activity 그 자체가 완전한 앱이 아니며 허용되는 경우 타사 앱이 잠재적으로 앱 중 하나에서 Activity을 호출 할 수 있다는 것입니다. 따라서 Activity을 가능한 한 자체 포함 된 것으로 만드는 것이 일반적입니다. 예를 들어 AsyncTask과 같은 것을 사용하면 배경 스레드를 실행하고 UI를 조작하는 메서드를 제공합니다. AsyncTask을 확장하는 개인 클래스를 중첩하는 것은 매우 일반적이며 코드를 단순화합니다. BroadcastReceiver을 확장하는 중첩 클래스도 같은 이유로 공통적입니다.
즉, POJO 도우미 클래스 용으로 별도의 Java 클래스 파일을 사용하는 것은 잘못된 것이 아닙니다. 예를 들어 앱이 얼마나 복잡한 지 알 수 있지만 특정 Android 클래스의 작동 방식을 특별히 고려해야합니다. AsyncTask 클래스는 특히 별도의 클래스 파일에 정의 된 경우 하나가되고 시도해 보면 내가 무슨 뜻인지 알 수 있습니다. :-)
활동이 거의 자체적으로 앱이라는 사실은 완전히 큰 클래스에 포함 된 것과 완전히 반대되는 것을 의미해야합니다. 모든 응용 프로그램은 어느 정도 "자체 포함"되어 있지만 모든 코드가 단일 클래스에 있어야 함을 의미하지는 않습니다. 인용 한 것처럼 * "활동은 함께 작동하여 응용 프로그램에서 일관된 사용자 경험을 형성합니다 *, 실제로 활동간에 UI 및 기능의 일부가 공유 될 것으로 예상됩니다. – Groo
@Groo : "Activity가 거의 하나의 앱이라는 사실 ..."- Android의 새로운 사람들이 믿는 바는 정확히 없습니다. 즉, '활동'은 '앱'과 동의어입니다. 실제로 앱에는 수십 개의 구성 요소 (활동, 서비스, 방송 수신자, 콘텐츠 제공 업체)가있을 수 있습니다. 모든 활동에 모든 것을 포함시켜야한다고 제안하는 것은 아닙니다. 요점은 활동이 매우 단순한 '페이지'UI 인 경우가 종종 있으며, 이는 매우 간단한 조치를 수행하며 종종 필요한 모든 것을 포함 할 수 있다는 점입니다. 공유 코드가 필요하면 헬퍼 클래스를 사용할 수 있습니다. – Squonk
+1 좋아, 내가 너무 피상적으로 게시물을 읽은 것 같아, 이제 그것을 얻을 : 완벽한 응용 프로그램의 일환으로 "자체 포함 된"'활동'을 언급했다. 앱의 모든 부분을 여러 파일 (또는 클래스)로 나눌 필요는 없지만 TDD 프로그래밍을 할 때 종종 가장 작은 각 구성 요소를 개별적으로 테스트 할 수있어서 좋으므로 자주 들어갑니다. 대부분의 시간. 그러나 다시, TDD는은 탄환도 아니다. 그리고 개인 클래스를 사용하여 클래스의 기능 중 복잡한 부분을 분해 한 다음 필요한 경우 (및 필요한 경우) 리팩터링합니다. – Groo
OO는 클래스에 기능을 넣는 것에 관한 것입니다. 이러한 클래스를 작성하는 방법은 그것이 좋은지 여부를 정의합니다 (논쟁의 여지가 있지만). 이러한 모든 클래스가 단일 파일인지, 아니면 소수의 파일인지 또는 각 클래스가 자체 파일을 가지고 있는지 여부는 미각의 문제이며 직접 OO 문제는 아닙니다.
작은 샘플이있는 책이므로 모든 클래스가 별도의 파일에있을 때보 다 쉽게 읽을 수 있습니다.
적절한 OOP를 사용하면 훨씬 더 빠르게 템플릿 기반 응용 프로그램을 만들 수 있습니다. &.
예를 들어 일반 데이터베이스 앱이 있고 사소한 변경으로 여러 데이터베이스를 사용할 수있는 경우이를 수행해야합니다.
질문을 더 잘 설명 할 수있는 몇 가지 예를 게시 할 수 있습니까? – elevine
OOP가 항상 최선의 방법은 아닙니다. 수천 개의 파일로 분할한다고해서 반드시 좋은 OOP 프로그램이 생성되는 것은 아닙니다. –