OOP is no use for relatively small apps.

Post #25,197 by Arkadiy 1/22/02 7:20:29 PM 1/22/02 7:21:26 PM Reply	OOP is no use for relatively small apps. OOP is of little of no use when you write stuff at JavaScript level. And even in that case, youend up calling metods, even if you call object "handles". On the other hand, in a large project there happens a point where your own data structures/code become as complex as underlying DB access code/data. So, if you agree that OO is good for writing "those internals", you may consider usong OO for your own code, as it grows as complex as "internals". As long as you can manage w/o "handles" (objects) and APIs (member functions) - fine, keep on using procs. Edited by Arkadiy Jan. 22, 2002, 07:21:26 PM EST Expand All History
Post #25,490 by tablizer 1/24/02 1:03:36 PM Reply	on scalability >> And even in that case, you end up calling metods, even if you call object "handles". << Taking credit for handles is going al gOOre overboard. A handle is simply an ID that points to a larger thingy. That is as much a database concept as it is OOP. >> On the other hand, in a large project there happens a point where your own data structures/code become as complex as underlying DB access code/data. << IMO, the p/r model is more scalable for these reasons (at least): 1. One focuses generally on one task at a time, regardless of the project size. 2. Tables and large ER setups are easier to grok than large class networks. (Usually a lower protocol-coupling ratio also). 3. P/r tends to factor common patterns into tables instead of code structures, where non-programmers or newbies can manage the control info without ever touching code. The Report Manager example is a case in point: most new reports are simply specified with data in tables. OTOH, most OOP puts all that info in code, where attributes and algorithms are all mixed together in a hard-to-navigate soup. ADMIN: is there an area we can take these battles so that they don't "clutter" the regular stuff? I know that some of you don't like these kind of discussions. Thus, if they can be moved to a dark corner somewhere, they may not bother you as much. ________________ oop.ismad.com
Post #25,782 by Arkadiy 1/25/02 5:45:04 PM Reply	Thingy Here is a challenge for you. Try to explain what a handle points to without using a word that is a sinonym of "object". WRT taking credit: I am not. I am actually saying that handles and APIs have a lot to do with the appearnce of OOP idea. The idea of object was somewhat derived from them. And then, it turned out, the better is an API written, the easier it fits into that new approach (better in a sence that existed _before_ objects). WRT scalability: I've never said that there are no other good approaches that scale up. I am just saying that OOP does not scale down quite as well.
Post #25,883 by tablizer 1/26/02 2:55:23 PM Reply	All Your Nouns Are Belong To Us >> Here is a challenge for you. Try to explain what a handle points to without using a word that is a sinonym of "object". << That is a little hard since any noun could be called an "object". Every paradigm deals with nouns, just differently. OOP simply tends to group and focus on them more than others. Its philosophy is that Nouns is King. IOW, it does not just "have" nouns, it elevates them. But the practicality of it is that I don't know what handles point to in most cases. It could be pointing to gerbals on treadmills powering the database. That implimentation detail is abstracted away such that the app developer does not have to worry about that when they use the handle. Perhaps OOP implements gerbals better, but that won't help the handle user because they don't see the basement. ________________ oop.ismad.com
Post #25,924 by static 1/27/02 12:28:52 AM Reply	How very interesting. He almost gets it, Arkadiy... Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #25,956 by tablizer 1/27/02 4:10:45 PM Reply	And youses can almost articulate the benefits >> He almost gets it, Arkadiy... << The only thing solid you have come up with is that some OOP langs can protect against the wrong ID (handle) being used on the wrong entity/object/gerbal/thingy. There are ways to do such without OOP if it was really a signficant issue. Is that the best you can do? It does not extrapolate into the "dynamically typed" OOP langs. Does that mean we should toss those? Jay is gonna be sad. Rasberries for all ________________ oop.ismad.com

Welcome to IWETHEY!