Is inheritance overrated? - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 5 FirstFirst 1234 ... LastLast
Results 16 to 30 of 68

Thread: Is inheritance overrated?

  1. #16
    Jon C. Stonecash Guest

    Re: Is inheritance overrated?

    "Phil Weber" <pweber@nospam.fawcette.com> wrote:

    >http://www.philweber.com/net/stories...eOverrated.htm
    >


    A lot of inheritance examples use a relative "tall" tree, but I find
    that inheritance is most useful to me when the inheritance is
    restricted to just one or two levels. I use inheritance when I see a
    bunch of objects that look and work in very similar manners. I will
    give you an example from my current project.

    The application accepts data from a variety of sources. There is a
    front-end process that "slices and dices" the data into a common
    database format. Even though the data is supposed to be strongly
    typed, each data item is initially stored in a string format. One of
    the initial steps in the process of importing the data is to edit the
    strings. The basic logic of editing each data item consists of three
    steps:

    1. Map the incoming value to a common coding. Three examples: a) The
    incoming data contains SSN values, sometimes with the dashes,
    sometimes without the dashes, sometimes without the dashes and leading
    zeros; the map function for SSN must cleanup the SSN for subsequent
    processing. b) the incoming data contains a variety of dates, in
    different formats; the map function must format the incoming date into
    a standard format for subsequent processing. c) The incoming data has
    coded values such as gender and marital status; these values must be
    mapped to a standard coding structure for subsequent processing. Note
    that every data item must be mapped, but the mapping behavior differs
    for each data item.

    2. Validate the mapped format of the each data item. Without going
    through specific examples, the logic to validate each data item will
    be different, but the output will not: an indicator of validality and
    zero or more error messages to report on any problems.

    3. Convert the validated data into the correct data type. Again,
    without gong through a lot of examples, each incoming data item will
    be converted to a specific data type for updating the data base.

    I have a parent DataValidator class that, at least for the puposes of
    our discussion, exposes a single method: GetValidValue. The input to
    this method is the string value, the output is an Object that holds
    the converted value (if the mapping and validation went OK) or a
    DBNull value (if anything went wrong, with error messages sent to a
    common error message handler). This method acts as a filter: good
    data gets through, bad data does not. The general logic is that the
    validation code gets the appropriate validator, calls the
    GetValidValue method with the incoming string, and stores the output.
    The bulk of the control logic is found in this DataValidator class.
    At the appropriate points in the code, it makes calls to virtual (must
    override) methods to perform the mapping, validation, and conversion.
    These methods are found in each child class that inherits
    DataValidator. The DataValidator also provides some common protected
    methods to handle common functions such as processing date values that
    can be called from the individual child objects.

    BTW, the rationale for using the classes is two fold: First, many of
    the incoming data types (such as SSN) show up multiple places in the
    input and having the validation objects ensures that they are edited
    properly each time. Second, the validator class centralizes all of
    the processing for a given data type, making maintenance much easier.

    I also have a factory method that, given the name of the incoming data
    type, returns the correct validation class.

    In theory, the logic to validate an incoming SSN could be as simple
    as:

    myGoodSSN = GetValidator(NAME_SSN).GetValidValue(myIncomingSSN)

    In practice, it takes a few more lines to make debugging easier and to
    handle the fact that the incoming data may contain DBNull values.

    The key here is that all of the objects provide the SAME external
    interface. They do not add or substract data. They do provide
    DIFFERENT implementations for the common methods. I find that
    inheritance works very well for this case.

    Could I have done this some other way? Absolutely!

    One possibility that I considered was to define a common interface and
    implement that interface for each validation object. I did not do
    that because there was a lot of common or shared logic for each
    validator and it seemed to make sense to place that in a common
    parent.

    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. I would have ended up pushing all of these helper methods
    up to the common parent for specifics. If I did that, there would be
    no real reason to keep the driver parent and the specifics parent
    separate. Not entirely a bad idea but I did not go that way.



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

  2. #17
    Willy Van den Driessche Guest

    Re: Is inheritance overrated?

    > 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 ?
    --
    For a work in progress :
    http://users.skynet.be/wvdd2/



  3. #18
    Willy Van den Driessche Guest

    Re: Is inheritance overrated?

    > You are attempting to say that something done to an object, is
    > a property/method of that object. Load and Save are tasks that
    > your content item is submitted to because the content item does
    > not control the result of the operation. For example, you could
    > save your object to a DB, as you intend, or to a file, or send it
    > across the wire, etc. It does not matter to the content item what
    > becomes of its data, only that it knows how to expose it.
    >

    By having a Save and Load method into his objects, Phil is on no way
    violating any OO principle or misusing implementation inheritance.
    There is another thing violated here and that's the separation of business
    logic and storage logic. Phil's design would make it impossible to store
    his objects in any other way than he coded it ( a storage - class approach
    would have allowed for multiple storage classes and therefore multiple ways
    to store and load the objects). But - as long as you are aware of this -
    there is little wrong with it. Choosing only one storage method is a viable
    option (from an OO perspective) since it makes for fewer classes and an
    easier design.
    --
    For a work in progress :
    http://users.skynet.be/wvdd2/



  4. #19
    Mike Mitchell Guest

    Re: Is inheritance overrated?

    On Thu, 28 Nov 2002 02:19:37 -0800, "Phil Weber"
    <pweber@nospam.fawcette.com> wrote:

    >http://www.philweber.com/net/stories...eOverrated.htm


    It's all way too complex. That's the fundamental problem with all of
    it, in my opinion.

    MM

  5. #20
    james Guest

    Re: Is inheritance overrated?

    Well, at least you did state that it was your opinion. A whole lot of other
    coders think that inheritance is a great tool. Sorry you don't get it.
    But, then again, you don't have to know or use inheritance in order to code
    in VB.NET.
    Or better yet, code it in Kylix or Delphi as you told another poster to do.
    You do know that Delphi is also able to do inheritance, didn't you ? And
    again, even in Delphi you don't have to use it. It's just another way to
    get things done. And sometimes it's even easier with inheritance.
    james

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:ldtnuus6orif4r6rohhb2m86lkeme6che6@4ax.com...
    > On Thu, 28 Nov 2002 02:19:37 -0800, "Phil Weber"
    > <pweber@nospam.fawcette.com> wrote:
    >
    >
    >http://www.philweber.com/net/stories...eOverrated.htm
    >
    > It's all way too complex. That's the fundamental problem with all of
    > it, in my opinion.
    >
    > MM




  6. #21
    Arthur Wood Guest

    Re: Is inheritance overrated?


    "Phil Weber" <pweber@nospam.fawcette.com> wrote:
    >http://www.philweber.com/net/stories...eOverrated.htm
    >
    >

    Phil,
    You said in the article that you had not found a real situation which
    called for inheritance. Let me pass on my experience with the concept.


    I built a small application, in VB6, for a Chruch that my family was attending
    at the time, to manage the membership list. The app called for tracking
    Family members who might be either Adults, or Children. Both classes had
    a First and Last(Family) name, a Date of Birth, and an indicator whether
    they were members(explicit) of the congregation. Adults also had an Employer,
    JobTitle, and Office Phone #, while Children had a Grade in School, School
    Name and Confirmation date.

    So I created a Base IPerson Class (Interface) to hold the common properties,
    and then created cAdult and cChild Classes which Implemented the IPerson
    interface, with the appropriate additional properties. I could then have
    a Family Collection object, holding objects of type IPerson (either Adult
    or Child Sub-classes). In addition, I modified the behavior ot the Birthdate
    property for adults to only return the Month and Date (most adults did not
    want to show their 'true' age), but for a Child, the Propetry returned the
    Full date.

    Worked like a charm.

    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.

    Arthur Wood

  7. #22
    Kunle Odutola Guest

    Re: Is inheritance overrated?

    Arthur Wood 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.


    I am not sure if there is any intent that this should be a reflection on the
    usefulness of inheritance Arthur. If not, you should ignore my comment
    below.

    If it was, then you should be aware that in certain domains -
    developing/extending ADT libraries or building/extending graphical editors
    like Visio for instance - inheritance is _almost_ a requirement.

    Kunle


  8. #23
    MarkN Guest

    Re: Is inheritance overrated?


    I use inheritance and interfaces a whole lot. I usually work my way from
    Interfaces (I've discovered than naming things starting with an 'I' is a
    bad thing) to Super and Abstract Classes as I discover things. The IDE will
    tell me if a it is an interface or not so need for the naming convention.
    Also, my IDE has built in refactoring so refactoring this way is easy.

    BTW, Arthur, what happens when the child becomes an adult?

    Mark

    "Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:
    >Arthur Wood 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.

    >
    >I am not sure if there is any intent that this should be a reflection on

    the
    >usefulness of inheritance Arthur. If not, you should ignore my comment
    >below.
    >
    >If it was, then you should be aware that in certain domains -
    >developing/extending ADT libraries or building/extending graphical editors
    >like Visio for instance - inheritance is _almost_ a requirement.
    >
    >Kunle
    >



  9. #24
    Daniel Pratt Guest

    Re: Is inheritance overrated?

    Hi Phil,

    "Phil Weber" <pweber@nospam.fawcette.com> wrote in message
    news:3de5eb1c$1@tnews.web.devx.com...
    > http://www.philweber.com/net/stories...eOverrated.htm


    My experience:

    In my spare cycles I've been working on a prototype that will be the
    basis for converting our currently VB6 app to .NET. We have a *lot* of forms
    in our application (it's a full-fledged specialized accounting app). In
    order to simplify development, the forms in our VB6 app are actually user
    controls that get "hosted" on a common form. We refer to these user controls
    as "screens" to distinguish them from normal user controls. The common
    elements on each screen (toolbar buttons, etc...) are actually on the host
    form. There is one interface that each screen must implement, plus a few
    optional ones depending on the functionality (for example, if a screen is
    "navigable" it will implement the "INavigable" interface). The host form
    modifies its appearance and behavior depending on which interfaces are
    implemented.

    In the .NET prototype its pretty much the same setup, except that
    inheritance is employed to simplify the development of screens. There is one
    base screen user control from which all screens inherit. From the base
    screen control are inherited screen controls that, in turn, become the base
    for spefic types of screens. This has made the development of screens much
    more straightforward, with far less helper classes and cut-and-paste. I'm
    quite pleased with the results, thus far.

    Regards,
    Dan



  10. #25
    Michael Culley Guest

    Re: Is inheritance overrated?

    > (I've discovered than naming things starting with an 'I' is a
    > bad thing)


    Do you mean decided?

    --
    Michael Culley




  11. #26
    MarkN Guest

    Re: Is inheritance overrated?


    That too.

    "Michael Culley" <mculley@NOSPAMoptushome.com.au> wrote:
    >> (I've discovered than naming things starting with an 'I' is a
    >> bad thing)

    >
    >Do you mean decided?
    >
    >--
    >Michael Culley
    >
    >
    >



  12. #27
    Larry Serflaten Guest

    Re: Is inheritance overrated?

    "MarkN" <vb.@127.0.0.1> wrote
    > >> (I've discovered than naming things starting with an 'I' is a
    > >> bad thing)



    Then perhaps Interfaces should not start with an I, but more like
    Attributes, and Exceptions, the class name should be suffixed
    with the full word:

    Public Interface PersonInterface
    ' Declaration code
    End Interface

    Public Class Adult
    Implements PersonInterface
    ' Implementation code
    End Class

    Reading it outright is fairly self documenting.....

    LFS






  13. #28
    MarkN Guest

    Re: Is inheritance overrated?


    Exceptions and Attributes are different.

    Using "Interface" is no better than "I". I agree with self documenting but
    I'll bet you are not doing Windows programming without an IDE. Now VB Classic
    is a pain for OO development, I can see why one would use "I" or "int_" but
    with tools like .Net it is only creating problems. One you are coding -
    it really doesn't matter if something is an interface or not.

    As for your example - the interface class definition says it is an interface.
    And using implements says that too.


    "Larry Serflaten" <serflaten@usinternet.com> wrote:
    >"MarkN" <vb.@127.0.0.1> wrote
    >> >> (I've discovered than naming things starting with an 'I' is a
    >> >> bad thing)

    >
    >
    >Then perhaps Interfaces should not start with an I, but more like
    >Attributes, and Exceptions, the class name should be suffixed
    >with the full word:
    >
    >Public Interface PersonInterface
    > ' Declaration code
    >End Interface
    >
    >Public Class Adult
    > Implements PersonInterface
    > ' Implementation code
    >End Class
    >
    >Reading it outright is fairly self documenting.....
    >
    >LFS
    >
    >
    >
    >
    >



  14. #29
    Larry Serflaten Guest

    Re: Is inheritance overrated?

    "MarkN" <vb.@127.0.0.1> wrote
    >
    > Exceptions and Attributes are different.


    But the recommended naming guidelines say use Exception, or Attribute as a suffix.
    It certainly isn't needed, but is an aid to the reader, as would be the Interface suffix.

    > Using "Interface" is no better than "I".


    Using I is out of character with the rest of the language that normally spells things
    out. Also, in an alphabetized list, all the "I"s line up in one area instead of near
    the implementing class (when the implementing class and its interface are named alike).



    > As for your example - the interface class definition says it is an interface.
    > And using implements says that too.


    The custom attribute declaration indicates its an attribute, as does the custom
    exception declaration, they both inherit from their respective base classes. But that
    is not really the business end of it. More use is made of base class as it is put
    to work, rather than when it is declared, and as shown, using the interface suffix
    makes it non-mistakable that an interface is being implemented opposed to some
    other type of class.

    You can use it as you see fit, as can I.... :-)

    LFS



  15. #30
    Arthur Wood Guest

    Re: Is inheritance overrated?


    Kunle,
    Yes, I am aware of the situations whaere inheritance can be VERY useful,
    but what I was getting at was that for the types of development that I (and
    the company I work for - a government contractor in the Washington DC area),
    the need for the style of development has rarely (if ever) presented itself.
    We generally develop custom apps (which are quite different almost EVERY
    time), rather than a generic base which can be extended as needed.

    And no, the comment was not intended to be a reflection of the usefulness
    of inheritance in general, just a comment that my personal experience was
    as I stated.

    Arthur Wood


    "Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:
    >Arthur Wood 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.

    >
    >I am not sure if there is any intent that this should be a reflection on

    the
    >usefulness of inheritance Arthur. If not, you should ignore my comment
    >below.
    >
    >If it was, then you should be aware that in certain domains -
    >developing/extending ADT libraries or building/extending graphical editors
    >like Visio for instance - inheritance is _almost_ a requirement.
    >
    >Kunle
    >



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