Is inheritance overrated? - Page 3


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 5 FirstFirst 12345 LastLast
Results 31 to 45 of 68

Thread: Is inheritance overrated?

  1. #31
    Arthur Wood Guest

    Re: Is inheritance overrated?


    <CLIP>
    BTW, Arthur, what happens when the child becomes an adult?
    </CLIP>

    good point, but the situation never arose - that Church has since closed
    its doors, and it would most likely have been the case that in the case where
    a child DID reach 'adulthood', they would have been added to the app as a
    'New' Family unit (either with a College address, or ore likely, a different
    address fromn their parent's address). Even if they still lived at 'home',
    the elders of the chirch wanted to treat 'adult' children as a separate 'family
    unit'. In that case, the only information that would need to be re-entered
    would have been Birthdate (no biggy).

    Artur Wood



  2. #32
    Mike Mitchell Guest

    Re: Is inheritance overrated?

    On 3 Dec 2002 06:49:41 -0800, "Arthur Wood" <wooda@nospam.com> wrote:

    >But so far, in almost 5 years of app development at the professional level,
    >this was the only REAL application where I found inheritance to be really
    >useful.


    But, Arthur, even then, why do it like that at all? Too much
    complexity again! You could write a membership management proggie like
    that in half a day with just an Access database, a data control, and a
    grid. It would be as simple as heck and there would be nothing
    inferior about the program thus produced.

    I believe many programmers start in on OOP for all the wrong reasons,
    e.g. they think they will gain some respect from the gurus. I'm not
    saying you did that, but I am always reading about failed projects
    nowadays. And ten to one they (or some of them) are being done with
    rigid attention to OOP diktat. I'm pretty certain some failures
    wouldn't have happened if only the coders could just learn to keep it
    simple.

    MM

  3. #33
    Kunle Odutola Guest

    Re: Is inheritance overrated?

    > I believe many programmers start in on OOP for all the wrong reasons,
    > e.g. they think they will gain some respect from the gurus. I'm not
    > saying you did that, but I am always reading about failed projects
    > nowadays.


    Unlike in the good old days before OOP came along right Mike?
    When project never failed?

    LOL!

    Kunle


  4. #34
    Jason Sobell - iGadget Guest

    Re: Is inheritance overrated?

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:qjruuukg4cb0scch3tt6e1i4cf6p9kcrv2@4ax.com...
    > On 3 Dec 2002 06:49:41 -0800, "Arthur Wood" <wooda@nospam.com> wrote:
    >
    > >But so far, in almost 5 years of app development at the professional

    level,
    > >this was the only REAL application where I found inheritance to be really
    > >useful.

    >
    > But, Arthur, even then, why do it like that at all? Too much
    > complexity again! You could write a membership management proggie like
    > that in half a day with just an Access database, a data control, and a
    > grid. It would be as simple as heck and there would be nothing
    > inferior about the program thus produced.


    Having the _choice_ of coding in a structured fashion or not is what is
    introduced in .NET.
    You can still bodge up code in procedural fashion if you want to keep
    writing code the way you have in VB6

    > I believe many programmers start in on OOP for all the wrong reasons,
    > e.g. they think they will gain some respect from the gurus.


    Very true. Lots of people do indeed think that OOP is some sort of 'ivory
    tower', but when you consider some of the advantages of OO development
    (which I know you dispute all of) I think it is very healthy to understand
    _all_ methods of development so you can swap and choose between them.
    I use VB6 for small, easy delivery 'utilities' where I want to develop a
    'no-brainer'. I use .NET for anything of complexity where I intend
    modifying, reusing, or sharing any of the system.

    > I'm not
    > saying you did that, but I am always reading about failed projects
    > nowadays. And ten to one they (or some of them) are being done with
    > rigid attention to OOP diktat.


    It's not OOP diktat, it's a complete lack of understanding of the problem
    that causes so many failures.
    Methodologies such as Rational's attempted to address the issue, but were
    too heavyweight, and lets face it - we can't force weak programmers with no
    problem solving skills to develop a good solution no matter how many 'Use
    case scenarios' we get them to write

    > I'm pretty certain some failures
    > wouldn't have happened if only the coders could just learn to keep it
    > simple.


    Absolutely, but this is a difficult concept to grasp. An OO structure for a
    solution is inherently (sic) more difficult for habitual procedural
    developers to grasp than simply to 'hack up' some working code. Both of
    these are possible in .NET, as in almost any OO language (such as 'C' code
    written in C++).
    The trick is _finding_ the simple solution in VB.NET. If you practise, you
    can find one and write a solution with very little complexity very quickly.
    Yes, the same applies to VB6, but you generally end up with lots of variant
    type situations where it can't quite meet your requirements for generic
    handling of a situation.

    Cheers,
    Jason



  5. #35
    Michael Culley Guest

    Re: Is inheritance overrated?

    > And ten to one they (or some of them) are being done with
    > rigid attention to OOP diktat. I'm pretty certain some failures
    > wouldn't have happened if only the coders could just learn to keep it
    > simple.


    Usually the first project a company or programmer does in oop fails, after
    that initial hurdle I think oop is a good thing. You are correct in stating
    some of its disadvantages, it does need more advanced developers and is a
    little more complex. You think it is hugely complex just because you have
    never done it (everything seems complex before you do it), however, it is
    simpler and easier than you think.

    --
    Michael Culley



  6. #36
    Jason Smith Guest

    Re: Is inheritance overrated?

    Mike, it is clear you still don't understand how to use OO.

    You can open a beer bottle with a hammer, but not with the part you use to
    drive in nails. Understand? No? I'm not surprised.

    OO is a set of tools. Not all of them are always applicable, and sometimes
    none of them are. If you use them incorrectly, you end up with a broken
    bottle and beer all over the floor. Uh, sorry, back to the hammer analogy.
    If you use them correctly, you get the beer and keep your teeth.

    But okay, Mike, if you want to go on hammering nails in with that big flat
    forehead of yours, and opening beer bottles with your teeth, go right ahead.
    Heck, if someone gave you a hammer, you would probably just use it to test
    how strong your skull is anyway.


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:qjruuukg4cb0scch3tt6e1i4cf6p9kcrv2@4ax.com...
    > On 3 Dec 2002 06:49:41 -0800, "Arthur Wood" <wooda@nospam.com> wrote:
    >
    > >But so far, in almost 5 years of app development at the professional

    level,
    > >this was the only REAL application where I found inheritance to be really
    > >useful.

    >
    > But, Arthur, even then, why do it like that at all? Too much
    > complexity again! You could write a membership management proggie like
    > that in half a day with just an Access database, a data control, and a
    > grid. It would be as simple as heck and there would be nothing
    > inferior about the program thus produced.
    >
    > I believe many programmers start in on OOP for all the wrong reasons,
    > e.g. they think they will gain some respect from the gurus. I'm not
    > saying you did that, but I am always reading about failed projects
    > nowadays. And ten to one they (or some of them) are being done with
    > rigid attention to OOP diktat. I'm pretty certain some failures
    > wouldn't have happened if only the coders could just learn to keep it
    > simple.
    >
    > MM




  7. #37
    Ian Lowe Guest

    Re: Is inheritance overrated?

    Hi, Phil,

    It looks to me that the problem wasn't with inheritance, but rather that
    your first design simply wasn't a good match for your requirements.
    Specifically, it seems that you required a very generic content management
    system that can accept new types of content items at run-time without
    intervention of a programmer. In this case, requiring a specific class for
    each content type just doesn't match the requirements, whether using
    inheritance or not.

    Is this a common problem with inheritance? It depends on how you look at it.
    In general, implementation inheritance is a type of specialisation where
    subclasses present more specialised versions of a more generic parent.
    Consider, for example, the WinForms controls which present more and more
    specialised controls all inheriting ultimately from Windows.Forms.Control.
    In this sense, inheritance leads to specialisation so inheritance will only
    aid your design if specialisation can help. In your specific case, you want
    the opposite of specialisation for your content items; you want flexible,
    run-time genericity.

    On the other hand, one purpose of implementation inheritance is to allow for
    code re-use. If you have a group of related classes that all need to
    implement the same, non-trivial code, those classes may be good candidates
    for a refactoring into an inheritance hierarchy. This does not appear to be
    the case in your example.

    As a general rule-of-thumb, implementation inheritance is most helpful with
    the creation of frameworks and has less to offer for specific applications.
    In the latter case, interfaces may be all that is required.

    Ian.



  8. #38
    Jon C. Stonecash Guest

    Re: Is inheritance overrated?

    "Willy Van den Driessche" <wvddwebcomments@skynet.be> wrote:

    >> Another possibility that I considered was to place the common logic
    >> into a validation driver class, define a virtual parent for the
    >> validation specifics class that defined the map, validate, and convert
    >> methods, and then define children of that specifics class for each
    >> data type that needed to be validated. I did not do that because I
    >> found that there was a lot of overlap in the helper methods for each
    >> data type.

    >Could you please elaborate why an interface would not have been much better
    >? I don't see so many common functionality inside typical "validators".
    >Aren't the common (protected) methods hidden static methods that are
    >actually usable outside of validators too ?


    Sorry for the delay. I was out of town on business and did not have
    time to check these newsgroups.

    I could have done this with interfaces, but the class design that I am
    using for the validation has a fair amount of internal state. Any
    interface would have to pass a fair number of parameters to allow the
    interface to do the job. It was easier to make these protected fields
    and inherit from the validator. Not better, just easier.

    Your comment about reusing some of the common methods rings true. One
    of the bugs that I chased this week in this project resulted from
    using a validator before one of the dependencies that the validator
    class requires had been set up. If I had a little more time, I might
    have done some refactoring to isolate things a bit better.

    This project is essentially over for me, and like every project that I
    have ever done, has things done one way that I think could have been
    done differently and better. If I only knew then what I know now.
    The design of the project is solid and represents a significant step
    up for the client, but given a few more days/weeks (dollars!), I could
    have made it ever so much better!

    Jon Stonecash

    Jon C. Stonecash, Rainier Technology
    Internet: stonecash@cdev.com, Compuserve: 73014,1255

  9. #39
    Mike Mitchell Guest

    Re: Is inheritance overrated?

    On Fri, 6 Dec 2002 08:34:11 +1100, "Jason Sobell - iGadget"
    <iGadget_@hotmail.com> wrote:

    >......... An OO structure for a
    >solution is inherently (sic) more difficult for habitual procedural
    >developers to grasp than simply to 'hack up' some working code.


    Not just for habitual proceduralists, but for everyone. OOP is
    inherently more difficult, period. That is its problem. For where its
    applicability can be of use in certain esoteric problem solving, for
    business applications it's mostly hopeless overkill. There is nothing
    complex about ordinary, everyday business practices. Folks have been
    running businesses for centuries. The basics don't change. The
    concepts of profit and loss, stocks and shares, buy and sell, product
    development, cost management, and all the other standard business
    practices do not change. What changes is that the old boys, often
    without any formal qualifications, hang up their Hollerith cards and
    die off, to be replaced by new, eager graduates fresh from academe who
    take their place, their heads full of theory and empty of experience.
    This is what business nowadays has to utilise. Hardly surprising, when
    said graduates are fed on a diet of OOP and nothing but OOP, that they
    will not want to employ OOP as the one hammer to crack any nut when
    they are finally let loose upon an innocent public which still can't
    fathom how to set up the VCR.

    Pragmatism seems to have no place any longer. If it ain't OOP, it must
    be POOP!

    MM

  10. #40
    Mike Mitchell Guest

    Re: Is inheritance overrated?

    On Fri, 6 Dec 2002 09:39:47 +1100, "Michael Culley"
    <mculley@NOSPAMoptushome.com.au> wrote:

    >............ however, it is
    >simpler and easier than you think.


    No. Simpler and easier is how we all *do* think, and the natural,
    simple, efficacious way we *do* think is not to think of a dog or a
    cat being derived from a base "animal", or a tree having child
    "branches" and branches to have child "twigs". It's all nuts. So
    restrictive, so rigid, so intransigent. Completely unlike life as it
    is really lived. With OOP architecture, every building would look like
    another. Hey, fellah! Don't even think of building that east wall out
    of timber! It's gotta be brick, the base class says so. Eh? You
    "preferred" timber? What's preference got to do with anything? We only
    inherit brick walls here, sonny.

    Once we have finally woken up to the fact that even the emperor's
    handlers now believe that the daft old bugger's naked, that's when we
    can move on and redesign computing without designing in complexity,
    just to make ourselves look bright. Those with the truly big intellect
    always aim to keep it simple, because they know intrinsically that
    simplicity always has a better chance of working than complexity. If
    there's less to go wrong, there's less that can go wrong, and even if
    it does, there's a lot less of it to unravel in order to find and fix
    the problem.

    MM

  11. #41
    Mike Mitchell Guest

    Re: Is inheritance overrated?

    On Thu, 5 Dec 2002 17:27:40 -0700, "Jason Smith" <jsmith@hotmail.com>
    wrote:

    >You can open a beer bottle with a hammer, but not with the part you use to
    >drive in nails. Understand? No? I'm not surprised.


    Ah! The mentality of an OOP aficionado, I see! And if I had no hammer,
    but I was thirsty and had a stone? Why, I'd hit the bottle with the
    stone and filter the contents through a sock. Trouble is, the stone
    doesn't figure in your OOP hierarchy. I can quickly write a proc
    "Stone" to deal with the situation as it is at this moment in time;
    you must go back to your model and start doing some overloading,
    overriding, subclassing, or whatever else it is that you OOP chaps do
    to get a stone into that class model where previously it was a hammer!

    MM

  12. #42
    Larry Serflaten Guest

    Re: Is inheritance overrated?

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
    > On Fri, 6 Dec 2002 09:39:47 +1100, "Michael Culley"
    >
    > No. Simpler and easier is how we all *do* think, and the natural,
    > simple, efficacious way we *do* think is not to think of a dog or a
    > cat being derived from a base "animal", or a tree having child
    > "branches" and branches to have child "twigs". It's all nuts. So
    > restrictive, so rigid, so intransigent.


    Do you play any sort of instrument? Each note in a song is precisely
    defined, restrictive, rigid and on paper, is intransigent. Yet get two
    musicians to play the same song, from the same sheet of music, and you'll
    hear different things. How can that be, since they both are playing from
    the same sheet of music?

    You say we do not think of a dog being derived from a more base class,
    but ask any child if a dog is an example of a plant or an animal and many
    will give the right answer. There is an association.

    The same for trees and branches, ask a child what a tree is made of, and you
    will often hear wood. Ask the same child what a branch is made of and
    what do you suppose the answer will be? It will more often be the same
    answer they gave for the tree because a branch is a smaller part of a tree.

    A child can see these associations, even if you refuse to acknowledge them.

    >Completely unlike life as it is really lived. With OOP architecture, every
    >building would look like another.


    Exactly how do you suppose real life can be modeled in a world of 1's
    and 0's? No way can it be exact, otherwise it would be a duplicate world.
    But it is a representation that can be manipulated in the realm of 1's and 0's
    and that is the realm which the engineers must work in.

    It never ceases to amaze me how fantasitcally closed minded you are to
    new ideas, or even a few variations. You are made up of cells, different
    types of cells. The types of cells you have match the types of cells every
    other human has, yet amazingly, we do not all look alike. Perhaps that
    real world fact can open the blinders you have to how exact same object
    patterns can be used to produce different results.

    There is no such thing as a real world animal base class. But there is an
    association among animals when they share common traits, or behaviours.
    In the realm of 1's and 0's, how would you represent that association?

    Being completely predictable, you would go about adding common properties
    to all the structures that represent some kind of animal, and in the process
    would be adding duplicate code to manage those properties, in all the
    animal structures you ever build. But, come the day that you find you've
    missed a common trait, you might spend the half your time on new projects
    looking over older code to find where that extra trait has to be added in
    any 'reused code'.

    That's the problem. Its not that objects make programming easier to architect,
    rather it makes new architects easier to incorporate. If you never have to
    go back over old apps to add new functionality, you probably don't need to
    look twice at OOP because you can get by without it. But if you have to
    revisit code often, you'll want a common set of abstracted ideas that apply
    to everything you look at so you can get up to speed on what it is doing
    in a relatively short period of time. With objects, and object patterns, you
    can grasp the intent of the code from familiarity of similar patterns.

    Everything in life follows a pattern. You are even using patterns when you
    start a For/Next loop. It is, after all, a conditional jump under the hood, but
    it is a pattern used so often it is given easy to use syntax.

    That is what OOA basically is, a means to abstract patterns from common
    problems and their solutions. So what if you don't think patterns are useful,
    you are in a world full of patterns, whether you like it or not. Every time you
    open your mouth against the use of such patterns you stick both feet into it
    because you can't get by in life without following some familiar patterns.

    LFS







  13. #43
    PWilmarth Guest

    Re: Is inheritance overrated?


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >No. Simpler and easier is how we all *do* think, and the natural,
    >simple, efficacious way we *do* think is not to think of a dog or a
    >cat being derived from a base "animal", or a tree having child
    >"branches" and branches to have child "twigs". It's all nuts. So
    >restrictive, so rigid, so intransigent. Completely unlike life as it
    >is really lived.


    Well, your making the assumption that everyone in the world thinks like you
    do. That is a pretty broad assumption and suggests a certain narrow-mindedness
    on your part (but we already know this).The truth is that most of us do think
    of things as types. Almost every discipline organizes things into types.
    Why do we keep talking about a dog being a type of animal? Because many
    smart Biologists (some of them were Brits) looked at "living things" and
    organized them into types: Reptiles, Animals, Birds, Plants, etc.

    >With OOP architecture, every building would look like
    >another. Hey, fellah! Don't even think of building that east wall out
    >of timber! It's gotta be brick, the base class says so. Eh? You
    >"preferred" timber? What's preference got to do with anything? We only
    >inherit brick walls here, sonny.


    Keep talking, Mike. You keep showing your ignorance. I think that OOP provides
    multiple ways of constructing a building that allows you to use different
    building materials.

  14. #44
    PWilmarth Guest

    Re: Is inheritance overrated?


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    > And if I had no hammer, but I was thirsty and had a stone? Why, I'd hit
    >the bottle with thestone and filter the contents through a sock. Trouble
    >is, the stone doesn't figure in your OOP hierarchy. I can quickly write

    a >proc "Stone" to deal with the situation as it is at this moment in time;
    >you must go back to your model and start doing some overloading,
    >overriding, subclassing, or whatever else it is that you OOP chaps do
    >to get a stone into that class model where previously it was a hammer!
    >
    >MM


    Mike, Mike, Mike, you are hopeless. A stone is a type of tool, just as a
    hammer is. Ever study anthropology? Early man used stones as all types
    of tools, some effectively, some less effectively. The user decides how he/she
    implements that tool. I don't think that early man was even so foolish as
    to keep re-inventing the wheel every time they needed a tool. In fact, I
    think they learned how to fashion stones to be used as pretty specialized
    types of tools.

    If you want to go around bashing open beer bottles with a stone, that's
    your business. I would rather wait until I found (or better yet, built)

    a bottle opener. OOP just provides a way to describe (or build) your tool.

    If you didn't have such a good sense of humor, I don't think any of us would
    tolerate you at all. Sometimes, you're like my dotty old uncle . . . amusing,
    but hardly worth taking seriously.


  15. #45
    Jason Sobell - iGadget Guest

    Re: Is inheritance overrated?

    "Mike Mitchell" wrote:

    > >......... An OO structure for a
    > >solution is inherently (sic) more difficult for habitual procedural
    > >developers to grasp than simply to 'hack up' some working code.

    >
    > Not just for habitual proceduralists, but for everyone. OOP is
    > inherently more difficult, period. That is its problem. For where its
    > applicability can be of use in certain esoteric problem solving, for
    > business applications it's mostly hopeless overkill.


    Beware of assuming that all developers have your mindset. Many (including
    me) find that the OO element of a language solves more issues than it
    creates, allowing you to decide how much of your app is OO based, and how
    much remains procedural.
    Heavy use of OO constructs are 'hopeless overkill' only if you use it to
    develop some minor utility to (for example) edit a single database table or
    modify a config file, trying to force OO constructs on something that simply
    does not need it.

    > There is nothing
    > complex about ordinary, everyday business practices. Folks have been
    > running businesses for centuries. The basics don't change. The
    > concepts of profit and loss, stocks and shares, buy and sell, product
    > development, cost management, and all the other standard business
    > practices do not change.


    Which is why businesses manage quite happily with nothing more than an Excel
    spreadsheet?
    I suspect you are discussing businesses such as accountants, butchers,
    news-agents, and funeral homes
    Businesses such as banking, insurance, and anything that needs more than a
    copy of MYOB to survive _are_ complex.

    > What changes is that the old boys, often
    > without any formal qualifications, hang up their Hollerith cards and
    > die off, to be replaced by new, eager graduates fresh from academe who
    > take their place, their heads full of theory and empty of experience.
    > This is what business nowadays has to utilise. Hardly surprising, when
    > said graduates are fed on a diet of OOP and nothing but OOP, that they
    > will not want to employ OOP as the one hammer to crack any nut when
    > they are finally let loose upon an innocent public which still can't
    > fathom how to set up the VCR.


    Yep, and many of these people fall flat on their faces. In what way does
    this invalidate OOP? It sounds to me to be more of an education issue,
    explaining to students _how_ and _when_ OO concepts should be applied. You
    clearly recognise when it should _not_ be applied, but you extend that to
    100% of situations

    Cheers,
    Jason



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