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: topmind on 31 Dec 2007 23:17 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) > > Topmind works in just such an environment. This is mostly an issue of interpretation of words. Data and behavioral are mostly interchangeable. One can process, view, or transform one as the other. For an extreme example, from the CPU's perspective, all your programs are nothing but data to it (machine instruction lists). Complex behavior in business systems tends to be what can be called "emergent" behavior. You don't have many isolated units of intense lone processing, but rather *complex integration* of multiple forms/ kinds of information. I am a NON-fan of OOP, by the way. I believe it to be mostly hype. -T- oop.ismad.com
From: topmind on 31 Dec 2007 23:25 H. S. Lahman wrote: > 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. Bullshit! This is ONLY true if you try to do everything in OOP and only use the DB as a mere bland simple file system. If you do such, you generally end up reinventing a database in OOP code the hard long way. SQL is nearly Turing Complete such that one can place a lot of processing, even a majority of it, into queries if one wants. (SQL is not the ideal relational language IMO, but thats another story.) Queries are NOT "low level", unless you are allergic to them and only use them as such. > > -- > 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 -T- oop.ismad.com
From: Daniel T. on 1 Jan 2008 10:41 On Dec 28 2007, 12:20 pm, "Dmitry A. Kazakov" <mail...(a)dmitry- kazakov.de> wrote: > On Fri, 28 Dec 2007 09:26:27 -0500, Daniel T. wrote: > > 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. > > > 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 don't 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 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? 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.
From: Dmitry A. Kazakov on 2 Jan 2008 05:13 On Tue, 1 Jan 2008 07:41:53 -0800 (PST), Daniel T. wrote: > On Dec 28 2007, 12:20�pm, "Dmitry A. Kazakov" <mail...(a)dmitry- > kazakov.de> wrote: >> On Fri, 28 Dec 2007 09:26:27 -0500, Daniel T. wrote: >>> 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. >>> > 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 don't 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 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? > > 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. I think you make the same logical error as he does. What an SQL request does is no matter, it could be extremely complex when translated into assembly instructions or considered on the level of transistors and ferromagnetic materials. We just do not care so long it does the work. Important is only relation to the problem domain. (Thus Turing completeness is also not an issue.) Regarding the domain, the abstracton level is in my view determined by *remoteness* of solutions from concrete problems. This is why all application-domain oriented languages are very low-level just per their *intent*. They aren't remote, they just directly do what you want. (Provided, that updating records is the problem.) This is not an abstraction. Abstraction happened long before when a language designer made a decision to abstract "update query" as a language construct, not me nor you. Of course, there is nothing wrong with that as long as we stay close to the domain of intent. Just let's call things by their names. Now, I wouldn't claim that I understand much "biz", but I guess that many application there are much more than "updating records." In that case SQL would necessarily become higher level than it was originally intended, and so the question arises whether it has enough abstraction power to cope with that. We all (including topmind) know that it does not. We also know that there cannot be a universal problem-oriented language. Once you start to specialize anything that thing will loose its universality. OO is merely an attempt to address this sort of problems. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 2 Jan 2008 06:19
On Jan 2, 11:13 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Tue, 1 Jan 2008 07:41:53 -0800 (PST), Daniel T. wrote: > > On Dec 28 2007, 12:20 pm, "Dmitry A. Kazakov" <mail...(a)dmitry- > > kazakov.de> wrote: > >> On Fri, 28 Dec 2007 09:26:27 -0500, Daniel T. wrote: > >>> 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. > >>> > 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 don't 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 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? > > > 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. > > I think you make the same logical error as he does. > > What an SQL request does is no matter, it could be extremely complex when > translated into assembly instructions or considered on the level of > transistors and ferromagnetic materials. We just do not care so long it > does the work. > > Important is only relation to the problem domain. (Thus Turing completeness > is also not an issue.) Regarding the domain, the abstracton level is in my > view determined by *remoteness* of solutions from concrete problems. This > is why all application-domain oriented languages are very low-level just > per their *intent*. They aren't remote, they just directly do what you > want. (Provided, that updating records is the problem.) If we don't share your view that the abstraction level is determined by the "remoteness", the rest of your post is rather meaningless. Assembler is pretty "remote" from the problem domain payroll processing, but that doesn't make it very high level. I know that there are no really objective ways of determinate the "level of abstraction", but most IT professionals would agree that SQL is an 4GL and most OO programming languages like Java, C++, etc, are 3GL. Most IT professionals would also agree that 4G languages could be considered as having an "higher level of abstraction" than 3G languages. > This is not an abstraction. Abstraction happened long before when a > language designer made a decision to abstract "update query" as a language > construct, not me nor you. Of course, there is nothing wrong with that as > long as we stay close to the domain of intent. Just let's call things by > their names. > > Now, I wouldn't claim that I understand much "biz", but I guess that many > application there are much more than "updating records." In that case SQL > would necessarily become higher level than it was originally intended, and > so the question arises whether it has enough abstraction power to cope with > that. We all (including topmind) know that it does not. We also know that > there cannot be a universal problem-oriented language. Once you start to > specialize anything that thing will loose its universality. > > OO is merely an attempt to address this sort of problems. //frebe |