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: Thomas Gagne on 9 Jan 2008 14:06 Matthew Shelton 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. > > 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 > Matthew, one of the mistakes some OO programmers make when building applications similar to yours is to forget the DB is already OO. Rather than treat it like the instance it is they construct frameworks of objects in front of it, erecting one-to-one relationships of language objects (in your case, a Java Customer) and database objects (a row from a customer table). I wrote a couple articles about it on my blog, <http://blogs.in-streamco.com/anything.php?title=the_rdb_is_the_biggest_object_in_my_syst> Most database systems today support the use of stored procedures. Store procedures are to database what method calls are to object instances in OOPLs like Java. For both databases and object instances, methods insulate the client from the implementation details inside the server. This insulation, as most OO programmers appreciate, allow the implementation to change with little or no effect on clients. A good test to measure how well an OO/DB application has implemented the principles of OO design is to change rename a column in the database and enumerate how many other code changes are required to accommodate it. If the column name change doesn't affect application code then I believe it passes the test. If instead classes and methods must change in the OOPL then the designer has ignored the benefits of treating their database as if it were an object--albeit a very large one. Consider what would happen if we tried this same test just inside the application and ignored the database altogether. If an instance variable's name was changed an the only dependent code was the object's own methods, then it too passes the test. If changes inside an object don't require complimentary changes in the object's clients then complete implementation hiding is achieved (at least for that attribute). Failing the test would be proven by needing to change /any/ code outside the object itself. If code in another object must change then the two objects are too closely coupled. Remember, we didn't change the objects interface (it's API or protocol, whatever you want to call it) we changed its internals. Any outside object dependent on the internals of another object is poor OO design, or if not poor design it's at least a violation of best practices--deliberate or not. -- Visit <http://blogs.instreamco.com/anything.php> to read my rants on technology and the finance industry. Visit <http://tggagne.blogspot.com/> for politics, society and culture.
From: Thomas Gagne on 9 Jan 2008 14:21 Daniel T. wrote: > <snip> > > I hate to sound like I agree with topmind, and I have to admit that I > know almost nothing of the domain, but it seems to me that SQL is > pretty high level language in its own right. > High-level or low-level is kinda relative, isn't it? SQL is higher-level than machine language, but so is C (barely ;-). That doesn't mean that another language that hides or incorporates SQL couldn't be said to be higher-level than SQL. I remember reading a description of X-generation languages that said of them that the closer a language gets to the human-side of a problem domain (and consequently the further away it gets from the hardware) the higher-level a language it becomes. Consider SQL, then. It may be a long way away from the hardware, but on its own it's not very close to any specific problem domain either--except data manipulation. SQL, then, is an implementation language for some higher-abstracted concepts. Could another language compile itself into SQL or include SQL as part of its implementation? Obviously, since I've never used SQL to order books on Amazon. There are many levels of languages and between my Firefox process and the disks at Amazon that record and execute my transaction, and each level goes from the general (XHTML, Javascript ,etc.) to the very specific (seek a disk head to a specific sector and make it record magnetic fluctuations on physical media that shouldn't change unless told to change). So how high-level a language is SQL? It's higher than C, but not as high a procedures, and not as high as the application that invokes the procedures that execute the SQL that's interpreted by C to move disk heads and flip the polarity of dust on some kind of material. -- Visit <http://blogs.instreamco.com/anything.php> to read my rants on technology and the finance industry. Visit <http://tggagne.blogspot.com/> for politics, society and culture.
From: topmind on 9 Jan 2008 18:21 Dmitry A. Kazakov wrote: > On Sun, 6 Jan 2008 10:00:37 -0800 (PST), frebe wrote: > > > But > > your point seem to be that since you can't tell the complexity from > > the source code, the model is flawed? > > Exactly. > > I don't board an aircraft without wings. Who knows, maybe it has an > anti-gravity relational engine inside, but I better take no chances. Are you suggesting we use only primative tools unless we know each layer and subsystem fairly well? Use COBOL or Fortran and a mainframe if you want such fine control over resources. You can still buy them. Generally there is a price to pay for higher abstraction, and less predictability about resource use is perhaps one of them. One is "outsourcing" more to underlying tools and systems. But in the RDBMS case, one tests to make sure performance is acceptable. If having known performance boundaries are a critical issue, such as for an armed missile, then use assembler, C, Pascal, or ADA instead of RDBMS. Of course, it would cost you more to stay at that level. Software development is all about weighing tradeoffs. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de -T-
From: frebe on 9 Jan 2008 23:22 > So how high-level a language is SQL? It's higher than C, but not as > high a procedures, and not as high as the application that invokes the > procedures that execute the SQL that's interpreted by C to move disk > heads and flip the polarity of dust on some kind of material. One way of telling if something is high-level or not, is to compare the amount of source code to write to accomplish a given task. Lets say I want to find all orders that are not fully paid. In SQL it would look like this: select orderid from order o join orderrow r on r.orderid=o.orderid join payment_allocation a on a.orderid=o.orderid having sum(r.amount) > sum(a.amount) If you write the solution in any other language, we could compare the source code, and tell which language is the most high level for this kind of tasks. //frebe
From: Dmitry A. Kazakov on 10 Jan 2008 04:28
On Wed, 9 Jan 2008 15:21:37 -0800 (PST), topmind wrote: > Dmitry A. Kazakov wrote: >> On Sun, 6 Jan 2008 10:00:37 -0800 (PST), frebe wrote: >> >>> But >>> your point seem to be that since you can't tell the complexity from >>> the source code, the model is flawed? >> >> Exactly. >> >> I don't board an aircraft without wings. Who knows, maybe it has an >> anti-gravity relational engine inside, but I better take no chances. > > Are you suggesting we use only primative tools unless we know each > layer and subsystem fairly well? Use COBOL or Fortran and a mainframe > if you want such fine control over resources. You can still buy them. > > Generally there is a price to pay for higher abstraction, and less > predictability about resource use is perhaps one of them. One is > "outsourcing" more to underlying tools and systems. > > But in the RDBMS case, one tests to make sure performance is > acceptable. If having known performance boundaries are a critical > issue, such as for an armed missile, then use assembler, C, Pascal, or > ADA instead of RDBMS. Of course, it would cost you more to stay at > that level. Oh, thank you for supporting my point, which was: requirements first. > Software development is all about weighing tradeoffs. It is about engineering. He spoke about the *source code*! When your architect could not tell you from the plans he made if your future house won't collapse. Then, I guess, there is no need to build the house, in order to say that there is something wrong with him and the way he produced those "plans"... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |