ООП моделируемые объекты в приложении, управляемом базой данных?

Question

Я создал целое банковское приложение на основе базы данных SQLite. Сегодня у меня момент паники. Я читал всевозможные статьи по ООП, я думаю, что понимаю концепцию, и это важно, однако я не могу понять ее место в приложении, подобном моему. До сих пор, возможно, по невежеству, моя логика работы с данными была следующей (пример псевдокода для редактирования банковской формы для нового приложения учетной записи):

• В EditAccountApplication Activity определите общедоступный Курсор, этот Курсор будет содержать сведения о предыдущих данных формы заявки.
• Запрос к БД для данных старой формы приложения с использованием метода из DbHelper, возврат объекта Cursor с указанными данными.
• Используя этот Курсор, заполните значения компонентов пользовательского интерфейса (EditText, TextView и т. Д.), С помощью которых пользователь может затем отредактировать, чтобы повторно отправить свое приложение с обновленными данными.
• Пользователь нажимает кнопку, чтобы повторно отправить свою заявку. В методе кнопки onClick () определяются и устанавливаются переменные для каждого компонента пользовательского интерфейса в объекте ContentValues, затем этот объект ContentValues ​​передается обратно в метод DbHelper, который в конечном итоге обновляет связанную запись БД.

Это правильный подход, который я должен использовать при использовании бэкэнда SQLite? Я не вижу, как моделирование объектов могло бы помочь в этом случае (Курсор в значительной степени является объектом, мне не нужно манипулировать им, поскольку элементы пользовательского интерфейса доступны для манипулирования пользователем).

Я действительно хочу понять, действительно ли в этой ситуации создание моделируемых объектов не приносит никакой дополнительной выгоды.

Я действительно ценю любую помощь, проверка реальности будет облегчением в этот момент, так как я волнуюсь!

Еще раз спасибо!

Answer 1

Вы уже используете ООП, не осознавая этого. При программировании мобильного приложения для платформы, такой как Android, вы обычно используете общие шаблоны для выполнения общих задач (таких как обновление бэкэнда Sqlite). Эти шаблоны есть либо на странице Android Dev, либо в отрывках из книг и очень специфичны. Поэтому трудно от них отклониться - и они «уже» объектно-ориентированы.

Теперь предположим, что вы сохраняли экземпляры объекта банковского счета в памяти в своем приложении и, следовательно, нуждались в моделировании объекта BankAccount. Там вы можете следовать принципам ООП, таким как инкапсуляция и сокрытие данных, например, используя метод:

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

в классе BankAccount и манипулирование им. Или, если вы выставляете API, который обновлял объекты, и было прослушивание этого обновления, о котором нужно было уведомить, то у вас есть шанс явно моделировать ООП с использованием шаблона Observer.

Но для такой простой задачи, как обновление базы данных SQLite, при использовании определенного шаблона Android, например, используемого, код УЖЕ объектно-ориентирован.

ИМХО, ты хороший.

Answer 2

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

Если вы на самом деле написали полноценное банковское приложение, то у вас, вероятно, есть проблемы с пользовательским интерфейсом, проблемами с проверкой входных данных, проблемами в области банковской индустрии, проблемами с доступом к данным и т. Д., И ваша архитектура, вероятно, была бы хорошо удовлетворена принципами объектно-ориентированного проектирования. .

Если у вас есть просто приложение CRUD с формами поверх данных, которое не имеет бизнес-логики и не будет со временем развиваться, чтобы включать новые функции, тогда ваш подход вполне подойдет (хотя есть ряд инструментов быстрого программирования приложений, которые Вы, вероятно, могли бы решить эту проблему практически без какого-либо фактического кодирования).