what's the future of Object Oriented Programming
in [OOP]
|
Prev: Deriving - .NET example
Next: Polymorphism Downsides (was: what's the future of Object Oriented Programming)
From: Phlip on 9 Sep 2006 12:03 VV wrote: > For e.g. reducing dependency was already solved with procedural > languages using libraries and include files. As a result, we should > ignore this as a value of OO. You get my gist. OO allows old code (library code) to call new code more easily. Without OO support in your language, you must pass a function pointer to the old code, and this calls your function back as a callback, to specialize it. The callback typically comes with a void *, to pass your application-specific data through. Under an OO system, you derive from a library class, and overrride a function. This is also a callback (the procedural language enabled a form of OO), but it's typesafe, more accurate, and easier to upgrade and extend. > Borrowing an idea from a previous poster, I guess I could have created > objects to represent types of users at my sites. In our case - users > and solution providers. All methods related to these objects would then > be encapsulated within the objects. It would be easy to maintain and > extend and such a site. Don't create a class as a "compilable comment", to name a category of entities. Create one if you have behavior to abstract. Have you read /Design Patterns/ yet? > But I guess my biggest problem is simply that web sites do not > naturally lend itself to OO the way apps do. In an app, everything is > an object with functions. For e.g. In windows you have windows, > applications, programs - all objects. Web sites have pages, not > objects. So if you build sites with OO yes its possible but it just > doesn't feel like a natural fit. An HTML page is a declarative expression, not a program, so naturally its OO aspects are more subtle. One big twist in web programming is you typically need aspects of your objects to appear in several layers. Database, server-side, HTML, DOM, and JavaScript. Of course you don't clone the code of each object and port it to the next language. The best way to flatten this complexity is a variation of the Observer Pattern called Model View Controller. That's, roughly, a triad of 3 observers watching each other. So the only "objects" in your JavaScript are thin things that observe your data model, and reflect its changes onto the screen. Now look up Ruby on Rails, if you think OO can't accelerate web development! -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
From: Bruno Desthuilliers on 9 Sep 2006 15:05 VV a ?crit : (snip) > But I guess my biggest problem is simply that web sites do not > naturally lend itself to OO the way apps do. Depends on what kind of "web site" - and what kind of application. An e-commerce solution usually includes a non-trivial part of applicative code... > In an app, everything is > an object with functions. For e.g. In windows you have windows, > applications, programs - all objects. Web sites have pages, not > objects. So if you build sites with OO yes its possible but it just > doesn't feel like a natural fit. One other possible approach is too represent pages (and their content) as objects, and store the whole thing in a OODBMS - this is mostly how Zope2.x works (ok, Zope sucks, but that's another problem). You can have a look at Trac's components/plugins architecture or at the CherryPy web application server to see how web-programming can benefit from OO. My 2 cents...
From: H. S. Lahman on 9 Sep 2006 22:21 Responding to VV... > I am interested in hearing everyone's opinion on what they think the > future is of Object Oriented programming. > > I have spend most of my career with object oriented concepts (12+ years > ) but recently with AJAX and the free tools, I really wonder what the > future of OO is. > > I recently launched a business written completely with free tools like > php and AJAX. I worked hard to give everything a structure like we OO > programmers are so particular about but honestly there was minimal > dependence on OO. Huh? It is true that a lot of the RAD CRUD/USER tools and layered model infrastructure are object-based at best. In addition, OSes like Windows and interoperability infrastructures are pretty much a bunch of class wrappers overlaid on function libraries. But the OOness lies in the OOA/D of the application, which is largely independent of the specific implementation technologies. (The transformation engines used for full code generation from UML OOA models routinely target languages like C or even Assembly for the output.) > The extend of my reusability might have been include pages, constants > etc. Reuse is nice but not a major consideration in using OO techniques. The real objective of OO development is to create maintainable applications in the face of volatile requirements over the product life cycle. To answer your title question, OO programming is still the only game in town for producing maintainable software. Unfortunately there is a lot of software called "OO" that is just C or FORTRAN programming with strong typing. The long term future of OO lies in UML as a 4GL. Currently UML is the only truly general purpose 4GL available and the OO paradigm's emphasis on abstraction is ideally suited to 4GLs because it allows independence from the local computing environment. Currently we are just moving into a paradigm shift similar to the shift from 2GLs (BAL) to 3GLs in the early '60s. In another 10-15 years I fully expect 3GL programmers to be as rare as Assembly programmers today. Currently the only vehicle in town for that shift is the OO paradigm. > Are many of you finding widespread use of OO in the web world? From what little I've seen, no. Much of current web development seems to be a throwback to the '60s. That's sad because there really shouldn't be anything different about web development than one finds in typical R-T/E environments. You've got a remote client and asynchronous messages. What's new about that? [Apocryphal anecdote. A couple of years ago I saw an article in a journal where the author actually claimed the first markup language was invented in 1986. How soon they forget and repeat past mistakes. Markup and scripting languages were very much in vogue in the late '50s and '60s. But there was a reason why they were abandoned by the early '70s.] ************* 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
From: frebe73 on 10 Sep 2006 03:30 > > First, what is your definition of OO? As you see people claim that HTML > > and web browsers are OO. So what is not OO? For some OO is everything, > > and everything is OO. > > I said, "Your web page can work in any browser, so the HTTP and HTML are > like adapter layers." Going from there to "everything is OO" is a slur, > which I don't appreciate. > > What verbiage in this thread lead you to "For some OO is everything"? You also said: "AJAX is a data stream to an Object - any web browser. The data stream is a Message, where the JavaScript in the web page in the browser is the Method that responds to that Message. Pure OO." Using HTML, JavaScript and AJAX is mostly done with minimal use of OO. But you claim that it is OO just because it can med modelled as objects. Because (almost) anything can be modelled as objects, everything is OO, according to you. I can model a HTML page using the relational model, but that doesn't mean that you use the relational model when you write a HTML page. Fredrik Bertilsson http://frebe.php0h.com
From: Patrick May on 10 Sep 2006 08:21
ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > "H. S. Lahman" <h.lahman(a)verizon.net> writes: >>[Apocryphal anecdote. A couple of years ago I saw an article in a >>journal where the author actually claimed the first markup language was >>invented in 1986. How soon they forget and repeat past mistakes. >>Markup and scripting languages were very much in vogue in the late '50s >>and '60s. But there was a reason why they were abandoned by the early >>'70s.] > > Is there a source (preferably accessible via the Internet) > where I can learn more about this, with names or examples of > these languages and an explanation why they were abandoned? I'd start with the history of SGML. Google coughed up this link: http://www.sgmlsource.com/history/index.htm No doubt Mr. Lahman, with his advantage of greater age^H^H^H experience[*] can provide more pointers. Regards, Patrick * ;-) ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) |