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: frebe73 on 9 Sep 2006 05:17 > Common example: Your users come in two types, Guest and Premium. So you > store the boolean isPremium in the database, and then all over your project, > from the data layer to the JavaScript, you write "if (isPremium) (whatever} > else {whateverElse}" everywhere. > > You need polymorphic types there. You should instead have a user type with > two sub-classes. User.whatever() will call one behavior for the Guests, and > another for the Premiums. Is Guest/Premium the only way you need to classify users? What if you later find it that you need to have different functionality for domestic and international users? How would the user subtypes look like (DomestGuestUser, InternationalGuestUser, DomesticPremiumUser, InternationalPremiumUser)? What if yet another dimension is introduced. Subtyping can be very dangerous. It is very unlikely that a entity such as user only need to be classified in only one dimension. Fredrik Bertilsson http://frebe.php0h.com
From: Phlip on 9 Sep 2006 09:41 frebe73 wrote: > 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"? -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
From: Phlip on 9 Sep 2006 09:51 frebe73 wrote: >> Common example: Your users come in two types, Guest and Premium. So you >> store the boolean isPremium in the database, and then all over your >> project, >> from the data layer to the JavaScript, you write "if (isPremium) >> (whatever} >> else {whateverElse}" everywhere. >> >> You need polymorphic types there. You should instead have a user type >> with >> two sub-classes. User.whatever() will call one behavior for the Guests, >> and >> another for the Premiums. > > Is Guest/Premium the only way you need to classify users? Absolutely yes. That's the only criteria that gets OO'd. > What if you > later find it that you need to have different functionality for > domestic and international users? Uh, put their functionality into two subclasses with a parent class HailsFrom? Give each Customer instance a delegating link to a HailsFrom instance? > How would the user subtypes look like > (DomestGuestUser, InternationalGuestUser, DomesticPremiumUser, > InternationalPremiumUser)? What if yet another dimension is introduced. Wow! That problem could happen to anything in OO, not just in lite web sites! How about we ... don't do that? > Subtyping can be very dangerous. It is very unlikely that a entity such > as user only need to be classified in only one dimension. Duplicating code all over the place can be very risky. If a given OO pattern reduces the duplication, use it. Otherwise ... don't! -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
From: Phlip on 9 Sep 2006 09:53 frebe73 wrote: >> For example, 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. > > Maybe COBOL is OO too? Or even SQL? Sure, but only when used in the JavaScript layer. -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
From: VV on 9 Sep 2006 11:04
Thanks everyone for your input. I too am trying to understand the best way to use OO within the context of todays web sites. One clarification to the earlier post. I define the benefits of OO as the additional benefits above and beyond what procedural programming already offered. 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. 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. 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. Please let me know your thoughts. Regards. Vibi Varghese Phlip wrote: > frebe73 wrote: > > >> For example, 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. > > > > Maybe COBOL is OO too? Or even SQL? > > Sure, but only when used in the JavaScript layer. > > -- > Phlip > http://www.greencheese.us/ZeekLand <-- NOT a blog!!! |