问题
I've built an entire banking app based on a SQLite database. Today I'm having a panic moment. I've been reading all sorts of articles on OOP, I believe I understand the concept and it's importance, however, I can't understand its place in an app like mine. So far, perhaps ignorantly, my logic for dealing with data has been as follows (example pseudo code for editing a banking form for a new account application):
- Within EditAccountApplication Activity, define a public Cursor, this Cursor will hold the details of the prior application form data.
- Query the DB for the old application form data using a method from DbHelper, return a Cursor object with said data.
- Using this Cursor, populate values of UI components (EditText, TextView, etc) with which the user can then edit to Re-Submit their application with updated data.
- User clicks on button to Re-Submit their application form, in the button's onClick() method, variables are defined and set for each UI component in a ContentValues object, this ContentValues object is then passed back to the DbHelper's method which ultimately updates the related DB record.
Is this the correct approach I should be taking when using a SQLite backend? I am not seeing how modelling objects would help in this case (the Cursor is pretty much the object, I don't need to manipulate it as the UI elements are available for the user to manipulate).
I really wish to understand whether or not this situation is one where creating modelled objects is of no added benefit.
I really appreciate any help, a reality check will be a relief at this point as I'm freaking out!
Thanks again!
回答1:
You are already using OOP without being conscious of it. When programming a mobile app for a platform such as Android, you usually use common patterns for doing common tasks (such as updating a Sqlite backend). These patterns are out there either on the Android Dev page, or in snippets in books and are very specific. So it's hard to deviate from them - and they are "already" object oriented.
Now, let's say you were keeping instances of a bank account object in memory in your app and hence needed to modela BankAccount object. There you could follow OOP principles such as encapsulation and data hiding by for example having a method:
debitAccount(double amt) {
// do validation checks for account balance such as don't let it go negative
}
in the BankAccount class and manipulating that. Or if you were exposing an API that updated objects and there were listeners to that update that had to be notified, then you have a chance of explicitly modelling OOP using the Observer pattern.
But for a simple task such as updating a SQLite database, when you use a specific Android pattern such as you are using, the code is ALREADY Object Oriented.
IMHO, you are good.
回答2:
The extent object-oriented concepts should be used for a given application depends upon the type of problem you are trying to solve. Your question is whether you should use object-oriented modeling within a data-driven application which is begging the question. That is to say, you've written your application in a data-driven style (presuming that is the style best suited for the problem at hand) and are asking about the correct way to merge in concepts from a different architecture paradigm.
If you have actually written a full banking application then you probably have user interface concerns, input validation concerns, banking industry domain concerns, data access concerns, etc. and your architecture would probably have been well served following object-oriented design principles.
If you just have a pure forms-over-data CRUD application that has no business logic and won't evolve over time to incorporate new features then your approach is just fine (though there are a number of Rapid Application Programming tools that you probably could have solved this problem with as well with little to no actual coding).
来源：https://stackoverflow.com/questions/9791349/oop-modelled-objects-in-a-database-driven-app