Is inheritance overrated? - Page 5


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 5 of 5 FirstFirst ... 345
Results 61 to 68 of 68

Thread: Is inheritance overrated?

  1. #61
    PWilmarth Guest

    Re: Is inheritance overrated?


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    >> I don't know or understand the internal workings of my car (and I
    >> never intend to know) but I still make use of it and enjoy its
    >> benefits.

    >
    >And you are not a professional mechanic. If you were, and made such a
    >claim, you would be seen as a rather pathetic figure.


    Well, you know, that's the point. I'm not a professional mechanic and I don't
    intend to be. And where did I imply I would make such a claim? It's amazing
    to me how you can never make a salient point in less than 100 words. Does
    your code suffer from this kind of bloat also?

    I'm only amazed that you didn't cite a gazillion references in proper APA
    format on top of it.

    Get a life, Bill.



  2. #62
    Mike Mitchell Guest

    Re: Is inheritance overrated?

    On Tue, 10 Dec 2002 22:27:18 -0000, "Kunle Odutola"
    <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:

    >Mike, are you really suggesting that a spoon (or a bottle opener, stick etc)
    >is a "function"?.


    So someone passes you a spoon in a restaurant, and you think, ah, an
    OOP method! Street.Restaurant.Spoon.Stir, eh?!!

    MM

  3. #63
    Ed Courtenay Guest

    Re: Is inheritance overrated?


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:nhaevuso07qq0ts7pi9v4kn8ee51d9rghh@4ax.com...
    > On Tue, 10 Dec 2002 22:27:18 -0000, "Kunle Odutola"
    > <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:
    >
    > >Mike, are you really suggesting that a spoon (or a bottle opener, stick

    etc)
    > >is a "function"?.

    >
    > So someone passes you a spoon in a restaurant, and you think, ah, an
    > OOP method! Street.Restaurant.Spoon.Stir, eh?!!
    >
    > MM


    Nope, probably more like:

    Dim IStirrable drink As New RoadsideCafe.ImitationTea
    Dim IStirrer stirrer As New RoadsideCafe.HorriblePlasticSpoonThing

    drink.StirWith(stirrer);




  4. #64
    Kunle Odutola Guest

    Re: Is inheritance overrated?

    W.E. (Bill) Goodrich, PhD wrote:

    >> Perhaps the "big thinkers" in computer science will find more
    >> effective paradigms to approach problem-solving,

    >
    > They already have. The Next Big Thing in academia is AOP, which will
    > do to OOP what OOP did to SSP.


    AOP is *complements* OOP. It can't replace it.

    >> but right now, this is the paradigm that the software world is
    >> operating from. It's popular because it is useful.

    >
    > Absolute nonsense. It is "popular" because the academics have been
    > teaching it as The One True Way for a while now.


    Nope. Many academics feel that not much [primary] innovation has occured
    since LISP/Simula really.

    >> I don't know or understand the internal workings of my car (and I
    >> never intend to know) but I still make use of it and enjoy its
    >> benefits.

    >
    > And you are not a professional mechanic.


    And you've stated more times than there are lines in your bloated replies
    that most VB'ers are "non-programmers" [sic]

    > If you were, and made such a
    > claim, you would be seen as a rather pathetic figure.


    That's what we thought when you made that claim.

    > But you - like
    > most of the other OOP apologists here - claim to be a professional
    > programmer. The extent to which you proudly proclaim that you "don't
    > know or understand the internal workings of" the code elements you
    > are using (or worse, modifying) is the extent to which you proclaim
    > yourself dangerously incompetent at your claimed profession.


    Really?. How many professional *application* programmers knew or understood
    or cared about the internals of their OS?. Are they all incompetent for not
    firing up a debugger and stepping thru kernel code.?

    >> You might be able to achieve some peace of mind if you would take
    >> the same approach.

    >
    > Unlike those of you who seem compelled to try (however poorly) to
    > defend OOP, he seems to already HAVE a large measure of peace of mind.


    Most people here (like most of the rest of the s/w development world) use
    OOP. They don't have to defend it. Mike's and your illusory peace of mind
    seems to be based on avoiding OOP whilst still throwing around derogatory
    remarks based on ignorance [or a strategy of overemphasizing extreme
    positions].

    Kunle


  5. #65
    Kunle Odutola Guest

    Re: Is inheritance overrated?

    Mike Mitchell wrote:

    Nice try to snip relevant context from my post.

    >> Mike, are you really suggesting that a spoon (or a bottle opener,
    >> stick etc) is a "function"?.

    >
    > So someone passes you a spoon in a restaurant, and you think, ah, an
    > OOP method! Street.Restaurant.Spoon.Stir, eh?!!


    Nope. I repeat again, "A spoon is an object".

    ShovelCrapIntoMikesPieHole() might be a method of a
    MikeMitchellOOP*****inSpoon (which IS-A type of Spoon).

    Kunle


  6. #66
    Mike Mitchell Guest

    Re: Is inheritance overrated?

    On Wed, 11 Dec 2002 12:40:20 -0000, "Ed Courtenay"
    <replace-this-with-my-first-name@edcourtenay.co.uk> wrote:

    >Nope, probably more like:
    >
    >Dim IStirrable drink As New RoadsideCafe.ImitationTea
    >Dim IStirrer stirrer As New RoadsideCafe.HorriblePlasticSpoonThing
    >
    >drink.StirWith(stirrer);


    Eh? A semicolon at the end of a VB statement? Shurely shome mishtake,
    Mish Moneypenny?

    Also, aren't you supposed to use parentheses all over the place? E.g.
    Dim IStirrable drink As New RoadsideCafe.ImitationTea()

    MM

  7. #67
    Mike Mitchell Guest

    Re: Is inheritance overrated?

    On Wed, 11 Dec 2002 12:56:20 -0000, "Kunle Odutola"
    <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:

    >ShovelCrapIntoMikesPieHole() might be a method of a


    Ya see! This fellah knows when to use parentheses!

    >MikeMitchellOOP*****inSpoon (which IS-A type of Spoon).


    Oops, nope! Wrong! He doesn't!

    MM

  8. #68
    David Bayley Guest

    Re: Is inheritance overrated?

    Phil Weber wrote:

    > > Your ContentItem base class stores the Type as a public
    > > String property, which immediately indicates to me that you
    > > are not really "using" inheritance (TypeOf is available if you
    > > must examine the type).

    >
    > Perhaps "Type" isn't the best name for that field; I use it to
    > indicate which user control to use to display the content. I could
    > call it DisplayControl, would I be "using" inheritance then? ;-) Or I
    > suppose I could give the user control the same name as the associated
    > content class, then use GetType to retrieve the name. The problem
    > with that is that eventually our Web designers should be able to
    > create the display controls; they shouldn't have to know or care
    > about my class names.


    Yes, I misunderstood the purpose of the "Type" property
    ("DisplayControl" would be clearer). In that case, it is preferable
    that your business tier not have *any* dependancy on the presentation
    tier, whether through direct references or string properties.

    It is up to the presentation tiers to determine which controls are
    associated with whatever biz objects they depend on, rather than the
    other way around. Consider a rich Windows.Forms app (for example an
    internal maintenance app) running along side your public Web.Forms
    app... should the Biz.ContentItem then add a WindowsDisplayControl
    property along side the (Web)DisplayControl property?

    > > Say, for example, you refactored your data store into an
    > > RDBMS with a "base" ContentItem table indexing all the ID's,
    > > and various HomePage, FeaureArticle, ProductReview, etc.
    > > tables with a foreign-key relation to the ContentItem table...
    > > Would the problems you raised be any different?

    >
    > Yes, they'd be different. Instead of being able to reuse a single
    > Load and Save method for all content classes, I'd have to write
    > separate stored procedures and data access code for each class, and
    > maintain a separate table for each content type. A LOT more work.


    I think you misunderstood me here. The issue I was trying to raise, is
    that refactoring the database to mirror the changes you made in the
    application domain, would result in the same problems. Seperate
    tables/classes, with the associated seperate client
    stored-procedures/user-controls.

    RDBMS's don't do inheritance, so this suggests that the issue is a more
    fundamental one about the data domain (seperate tables), rather than the
    behavioural domain(seperate classes) which usually feeds off the data.

    > > On the subject of creating a Content Management System,
    > > I think you are in danger of creating a generic framework...

    >
    > That's exactly what I'm doing. Why is that a danger? FTP wants a
    > framework that it can use with its existing family of sites, as well
    > as any new sites it may decide to launch in the future.


    "Any" site? Some dangers that come to mind...

    - You end up competing with 3rd-party generic framework providers, with
    the major disadvantage that you only have *one* customer. If
    3rd-parties are expensive, then that is an indication that the framework
    is not so easy to produce in-house.

    - Predicting future usage is inherently dangerous. The XP acronym YAGNI
    (You Ain't Gonna Need It), comes to mind. More often, it is better to
    refactor in new requirements when, and only when, they are required.
    Continuous refactoring is suprisingly painless IME (it works first
    time).

    - A generic framework adds a layer of complexity to development. An IDE
    is able to automatically provide class views, compile-time errors, UML
    diagrams, intellisense, etc., for behaviour which is encoded in static
    language constructs. A generic framework that uses proprietary strings
    sacrifices much of this functionality.

    - The original author may get run over by a bus. This is rather harsh,
    but if I was employed to replace you, I could understand well named
    classes written in language X. I won't understand a proprietary
    framework unless you have gone to the exceptional expense of supporting
    and documenting it in the same way that 3rd-party providers do.

    > > Chances are some 3rd-party has already gone to far more
    > > effort at writing a generic CMS that you can customize using
    > > your XML form definitions.

    >
    > If you know of such a product, please feel free to recommend it. :-)


    I admit I don't have any experience in the CMS market. If there is one
    though, then chances are somebody will be able to provide an economical
    generic framework now, or in the future. Until then, better to write a
    self-documenting maintainable Fawcette System using well known language
    structures.

    > > It only takes an hour to derive a few HomePageItem* classes,
    > > and subsequently minutes to modify HomePageItem behaviour.

    >
    > That's an hour + minutes that I won't have to spend maintaining my
    > generic framework. The users can create a new content type without my
    > involvement, simply by creating a user control to display the
    > content, an XML edit form definition, and adding a row to a
    > ContentTypes table.


    Why do *you* have to implement this in the generic framework. There are
    gazillions of programmers capable of inheriting from .NET classes, but
    there is only one programmer who understands your form definition files
    (XML alone is just hierarchical text).

    All you have to do is provide a set of base Web and/or Windows Controls.
    Sure they will have a *similar* structure to the server Biz objects, but
    seperating these logical tiers is usually worth it because of the
    different behaviour these similarly named classes implement.
    Alternatively, just start off implementing all the behaviour in
    Web.Controls, and refactor out a business tier as needed (there is no
    law that says n-tier is needed).

    --
    David




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center