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: frebe on 10 Jan 2008 11:39 > I think the expectation that 4-or-5GLs would be general purpose > languages is a huge mistake on many programmers part. A GUI is a good > example of a 4GL. The only thing Amazon's interface is good for is > buying things from Amazon. It's wouldn't apply to buying Bud Lite from > my local convenience store, even if after much processing the > transactions all end up on my charge card. SQL is also a pretty good 4GL. //frebe
From: topmind on 11 Jan 2008 00:52 Dmitry A. Kazakov wrote: > 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. I disagree generally with a comparison between software engineering and physical 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"... Preventing errors is one of many factors to weigh, and different situations require differing weightings of these factors. Such factors include: * Quality (no errors in output) * Usability (user-friendly) * Features * Cost to build * Cost to maintain (change) * Cross-programmer pick-up (staff changes) * Time to complete project * Run-time speed * Etc. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de -T-
From: Robert Martin on 31 Jan 2008 17:43 On 2007-12-27 23:00:01 -0600, Matthew Shelton <crash700(a)gmail.com> said: > I'm just wondering if OOP is a bit overkill for a database app. OO is a tool. What does the tool do? It helps you manage the dependencies between modules. It would be *very* surprising if your database application did not have modules whose dependencies did not need managing! Consider, for example, the problem testing your database application. You can test the whole application by using it. But how do you test the individual modules? How do you test that each query works as it is supposed to. How to you test that certain records are displayed in just the right way? How do you test that negative numbers appear in red, but positive numbers appear in black? How do you test that passwords are echoed silently? etc. etc. How do you test things things independently, if you cannot isolate the modules one from another? If you can't manage the dependencies between modules, you cannot make your modules testable. And so, just the basic need of all software, to make it testable, is a strong argument for using OO. -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��|
From: frebe on 31 Jan 2008 23:05
> > I'm just wondering if OOP is a bit overkill for a database app. > > OO is a tool. What does the tool do? It helps you manage the > dependencies between modules. It would be *very* surprising if your > database application did not have modules whose dependencies did not > need managing! > > Consider, for example, the problem testing your database application. > You can test the whole application by using it. But how do you test > the individual modules? How do you test that each query works as it is > supposed to. How to you test that certain records are displayed in > just the right way? How do you test that negative numbers appear in > red, but positive numbers appear in black? How do you test that > passwords are echoed silently? etc. etc. > > How do you test things things independently, if you cannot isolate the > modules one from another? If you can't manage the dependencies between > modules, you cannot make your modules testable. > > And so, just the basic need of all software, to make it testable, is a > strong argument for using OO. If testability is the most important requirement, then a functional programming laguage would be the best choice. Functions without side- effects are more easy to test, than objects with state. The larger part of your application you can write as functions without side- effects, the easier would the testing be. //frebe |