too much OOP ?
in [OOP]
|
Prev: Should class code access private members or public wrappers for those private members?
Next: Should class code access private members or public wrappers forthose private members?
From: Matthew Shelton on 28 Dec 2007 00:00 I'm building a java/JSP webapp. So I have everything designed pretty well, expecting usual code/test iterations. I'm just wondering if OOP is a bit overkill for a database app. I continue to end up with a utility class with a bunch of static methods, no matter how I try to analyze it. as everything is done one record at a time (inserts, searches, updates.) so I dont really have a need for multiple instances of a class. It seems pretty procedural, by nature. For example, I have a "Customer" class. This corresponds to a "Customer" table in the database. The class really only exists to access the database for updates, or queries. (takes a string as a parameter, and outputs a resultSet full of results, or <void> for an update/insert). The only place I could see using the fields is during a database INSERT. I suppose I could factor in some OOnes by making a method to get and display the data, and I could share the object with the rest of the app as a session or request attribute. And also cut the required scripting in my JSP's down to a few custom tags I think I've answered my own question, but I'd love to hear some opinions from somebody else, or at the very least, helping somebody with the same questions. Thanks. ~Matt
From: jukkaTamminen on 28 Dec 2007 06:28 On 28 joulu, 07:00, Matthew Shelton <crash...(a)gmail.com> wrote: > I'm building a java/JSP webapp. So I have everything designed pretty > well, expecting usual code/test iterations. > > I'm just wondering if OOP is a bit overkill for a database app. Hi Matt You are here at very profound questions. Simple answer to your simple question is: Yes everything SHOULD be OO. ...... but The trouble is that your approach is NOT OO at all! Well Why. The necessary fundamental core of OO is OO functionality. This is always collaboration between business objects like Customer-object and Delivery-object for instance. This means that you have to design and implement ALL BUSINESS logic as methods in WRIGHT business object. In this way your application NEVER adds a delivery for your customer. This is always done by the Customer object. In this way your db will change to be only a place to save your objects when you don't need them acutely. If you look in Java Persistence API with annotation you find out that db behavior can be completely declarative. When you look this thing from application perspective ( from user GUI), the change you see is that from doing business logic in your GUI you only find objects and tell them what to do. ( Continuing my pervious example: You first find your current Customer object, when he logs on. Then you show him list (collection) of your Product objects. When he decides to order, you will send the Customer object a message newDelivery( aProduct) here the parameter list is the list of chosen Product object. Now the newDelivery method will 1. create new Delivery object set it's attributes 2. connect the delivery to the customer and to the Product that will be delivered. So your delivery object need at least the following attributes: Creation date Delivery time State Number of products delivered Price (and of course the above association). The Delivery class must have a method getDeliveryAddress which asks the customer his home address. Finally you say to every new or old object: "Got to db" (ei. Save or something like that) The glue here is the business objects collaboration ( see Grady Booch: Object-Oriented Design pg 16 or Peter Coad Object-Oriented analysis a whole chapter in the beginning of the book) regards Jukka Tamminen For further question tamminen(a)gmail.com I can also send you a small example application
From: Daniel T. on 28 Dec 2007 09:26 Matthew Shelton <crash700(a)gmail.com> wrote: > I'm building a java/JSP webapp. So I have everything designed pretty > well, expecting usual code/test iterations. > > I'm just wondering if OOP is a bit overkill for a database app. I > continue to end up with a utility class with a bunch of static methods, > no matter how I try to analyze it. as everything is done one record at a > time (inserts, searches, updates.) so I dont really have a need for > multiple instances of a class. It seems pretty procedural, by nature. Unlike the last responder, I have to say that it may very well be the case that OO isn't appropriate for your application. I turn to Arthur J Riel: In some management information system (MIS) domains... there is no interesting behavior... These applications are often grinding up an object model and spitting it out in a variety of forms. This is not to trivialize MIS applications. Many projects in this area are very complex; it is just that their behavior is trivial. All of the interest is in the static object model and possibly the user interface. ("Object-Oriented Design Heuristics", pg 202) Topmind works in just such an environment. > For example, I have a "Customer" class. This corresponds to a "Customer" > table in the database. The class really only exists to access the > database for updates, or queries. (takes a string as a parameter, and > outputs a resultSet full of results, or <void> for an update/insert). > The only place I could see using the fields is during a database INSERT. > > I suppose I could factor in some OOnes by making a method to get and > display the data, and I could share the object with the rest of the app > as a session or request attribute. And also cut the required scripting > in my JSP's down to a few custom tags If you have removed the duplication in your system and it performs adequately, I'd say you are done. Don't add methods just to be adding them.
From: Dmitry A. Kazakov on 28 Dec 2007 12:20 On Fri, 28 Dec 2007 09:26:27 -0500, Daniel T. wrote: > Matthew Shelton <crash700(a)gmail.com> wrote: > >> I'm building a java/JSP webapp. So I have everything designed pretty >> well, expecting usual code/test iterations. >> >> I'm just wondering if OOP is a bit overkill for a database app. I >> continue to end up with a utility class with a bunch of static methods, >> no matter how I try to analyze it. as everything is done one record at a >> time (inserts, searches, updates.) so I dont really have a need for >> multiple instances of a class. It seems pretty procedural, by nature. > > Unlike the last responder, I have to say that it may very well be the > case that OO isn't appropriate for your application. > > I turn to Arthur J Riel: > > In some management information system (MIS) domains... there is no > interesting behavior... These applications are often grinding up an > object model and spitting it out in a variety of forms. This is not > to trivialize MIS applications. Many projects in this area are very > complex; it is just that their behavior is trivial. All of the > interest is in the static object model and possibly the user > interface. ("Object-Oriented Design Heuristics", pg 202) I don't think it is true, or better to say, it is true only because these systems are designed at an extremely low abstraction level. When the OP talks about "update query" it is an indicator of. Another is "database application." Not uncommon, but it is actually same as to talk about a "CPU application" and then to conclude that there isn't much OO around "MOV" instructions. True, so what? Should it be this way? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: H. S. Lahman on 28 Dec 2007 23:20
Responding to Shelton... > I'm building a java/JSP webapp. So I have everything designed pretty > well, expecting usual code/test iterations. > > I'm just wondering if OOP is a bit overkill for a database app. I > continue to end up with a utility class with a bunch of static methods, > no matter how I try to analyze it. as everything is done one record at a > time (inserts, searches, updates.) so I dont really have a need for > multiple instances of a class. It seems pretty procedural, by nature. > > For example, I have a "Customer" class. This corresponds to a "Customer" > table in the database. The class really only exists to access the > database for updates, or queries. (takes a string as a parameter, and > outputs a resultSet full of results, or <void> for an update/insert). > The only place I could see using the fields is during a database INSERT. > > I suppose I could factor in some OOnes by making a method to get and > display the data, and I could share the object with the rest of the app > as a session or request attribute. And also cut the required scripting > in my JSP's down to a few custom tags As described so far your application sounds like a typical CRUD/USER pipeline between the UI and the DB. OO techniques are usually overkill for such applications because the RAD IDEs have already provided a large amount of automation and present a fairly high level of abstraction (e.g., Form/Table) that would have to be reinvented using OO techniques. Generally you need an OO approach to deal with complex processing that must be done /between/ the UI and the DB. IOW, you need OO techniques when you need to solve a particular problem _in the application_. For the CRUD/USER applications the only problem being solved is converting the DB view to the UI view and vice versa. That is, the user solves some problem once the data has been presented in a convenient form for analysis. Note that once one is outside the realm of CRUD/USER processing the layered models that are underlie the RAD IDEs and infrastructures tend to break down because the mapping across boundaries is no longer 1:1. In addition, the UI tends to be regarded as a low level service for communicating with the user that is a peer of DB access. As a result the main application is typically completely indifferent to what UI paradigm is used or what storage paradigm is used so that UI and DB paradigms can be substituted without touching the problem solution. -- There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH |