데이터베이스 기반 응용 프로그램에서 OOP 모델링 된 개체?

Question

저는 SQLite 데이터베이스를 기반으로 전체 뱅킹 응용 프로그램을 만들었습니다. 오늘 저는 공포의 순간을 보게됩니다. OOP에 대한 모든 종류의 기사를 읽었습니다. 개념을 이해하고 중요하다고 생각합니다.하지만 내 것과 같은 앱에서 그 위치를 이해할 수는 없습니다. (새로운 계정 응용 프로그램에 대한 은행의 양식을 편집 예를 들어 의사 코드) 다음과 같이 지금까지, 아마 무지, 데이터 처리에 대한 내 논리가있다 : EditAccountApplication 활동 내에서

• , 공공 커서를 정의를이 커서 것이다 사전 신청서 양식 데이터의 세부 사항을 보유하십시오.
• DbHelper의 메서드를 사용하여 이전 응용 프로그램 양식 데이터를 쿼리 한 다음 해당 데이터로 Cursor 개체를 반환하십시오.
• 이 커서를 사용하여 사용자가 편집 할 수있는 UI 구성 요소 (EditText, TextView 등)의 값을 채워서 업데이트 된 데이터로 응용 프로그램을 다시 제출하십시오.
• 사용자가 단추를 클릭하여 응용 프로그램 양식을 다시 제출하면 단추의 onClick() 메서드에서 변수가 정의되고 ContentValues ​​개체의 각 UI 구성 요소에 대해 설정되며이 ContentValues ​​개체는 최종적으로 DbHelper의 메서드로 전달됩니다. 관련 DB 레코드를 업데이트합니다.

SQLite 백엔드를 사용할 때 올바른 방법을 사용하고 있습니까? 이 경우에는 모델링 오브젝트가 어떻게 도움이되는지 알지 못합니다 (커서는 꽤 많은 오브젝트입니다. 사용자가 조작 할 수 있도록 UI 요소를 사용할 수 있기 때문에 커서를 조작 할 필요가 없습니다).

이 상황이 모델링 된 객체를 만드는 것이 더 큰 이점이 아닌지 여부를 정말로 알고 싶습니다.

정말 도움이된다면 정말 고맙겠습니다. 현실에서의 확인은 내가 놀라움을 금치 못하게 할 것입니다!

다시 한번 감사드립니다!

Answer 1

당신은 이미 그것을 의식하지 않고 OOP를 사용하고 있습니다. Android와 같은 플랫폼 용 모바일 앱을 프로그래밍 할 때 일반적으로 일반적인 작업 (예 : Sqlite 백엔드 업데이트)에 일반적인 패턴을 사용합니다. 이 패턴은 Android Dev 페이지 또는 책의 발췌 부분에 있으며 매우 구체적입니다. 그래서 그것들을 벗어나는 것이 어렵습니다. 그리고 그것들은 이미 "객체 지향"입니다.

이제 은행 계정 개체의 인스턴스를 앱의 메모리에 보관하고 BankAccount 개체를 모델링해야한다고 가정 해 보겠습니다. 거기 당신은 캡슐화 및 데이터는 방법을 가지고 예를 들어 은폐 등의 OOP 원칙에 따라 수 :

debitAccount(double amt) { 
    // do validation checks for account balance such as don't let it go negative 
} 

는 BankAccount 클래스에서 그 조작을. 또는 업데이트 된 개체가있는 API를 노출하고 알림을 받아야하는 해당 수신기의 수신기가있는 경우 Observer 패턴을 사용하여 OOP를 명시 적으로 모델링 할 수 있습니다.

그러나 SQLite 데이터베이스를 업데이트하는 것과 같은 간단한 작업의 경우 사용중인 특정 Android 패턴을 사용할 때 코드는 이미 객체 지향적입니다.

IMHO, 괜찮 았군.

Answer 2

주어진 응용 프로그램에 대해 객체 지향 개념을 사용해야하는 정도는 해결하려는 문제의 유형에 따라 다릅니다. 귀하의 질문은 데이터 지향 응용 프로그램 내에서 begging the question 인 객체 지향 모델링을 사용해야하는지 여부입니다. 즉, 응용 프로그램을 데이터 중심 스타일로 작성하고 (다른 곳에서는 문제에 가장 적합한 스타일이라고 가정 함) 다른 아키텍처 패러다임의 개념을 병합하는 올바른 방법을 묻는 것입니다.

실제로 전체 은행 업무 응용 프로그램을 작성한 경우 사용자 인터페이스 문제, 입력 유효성 검사 문제, 은행 산업 영역 문제, 데이터 액세스 문제 등이있을 수 있으며 아키텍처가 객체 지향 설계 원칙.

비즈니스 로직이없고 시간이 지남에 따라 새로운 기능을 포함하지 않는 순수한 데이터 오버 플로우 CRUD 애플리케이션을 사용하는 경우 접근 방법은 매우 좋습니다 (많은 수의 빠른 애플리케이션 프로그래밍 도구가 있지만 실제 코딩을 거의 또는 전혀하지 않아도이 문제를 해결할 수 있음).