6 Comments

  1. Roger Orr

    If you’re running on a recent enough version of gcc then compiler warning -Wodr, in conjunction with -flto, can find this sort of problem at link time.

    Reply
  2. Timothy Onogu

    Ouch… That’s so annoying!
    Thanks for the lesson.

    By the way, I have a question for the paragraph if “Cause of the Problem”
    You said, the copy-paste programmer should have parametized the existing class.
    In you own suggestion, which option would have been best? And can you please comment on these options/scenerio.

    I have thought of few options including:
    (1) Simply Inheriting from the NamingHelper and do his Addition. //Note: No need for vtables here since there arent virtual functions and the NamingHelper2 wouldn’t ever be manipulated from base class. Either at compiletime or runtime

    (2) Liase with the maintainer of NameHelper to add an additional std::string member to his class. So that I can use it. This of cause is, far as the performance/usage requirements of NameHelper permits it.

    (3) If NameHelper was a class I just use as a client (i.e I don’t care about a bulk of its implementation details, I am only sticking to contracts). Should I wrap NameHelper in another ‘light’ class that just adds the behaviour I need?

    regards,
    Timothy

    Reply
    1. Timothy Onogu

      Forgive my typos please….

      Reply
    2. Arne Mertz

      By parametrizing the class I meant the original `SomeFooBarClass`, i.e. a class that, depending on some parameter would either behave the “Bar” way or the “Baz” way. I don’t remember what the two classes did exactly and what the difference was, so I have to be a bit vague. However, code duplication never is a good sign.

      As for your options: The `NameHelper` classes were very lightweight classes, not much more than data structures. The author was right to put it in the source file of `SomeFooBarClass` and not make it a full grown class with its own header and source, because it was only a little implementation detail. So the inheritance option is not applicable. The same applies for your option 3, putting a wrapper around it would have made it just a fat little class without much benefits.

      I would kind of go with option 2: If you don’t plainly copy `SomeFooBarClass` but parametrize/generalize it, then there is only one `doSomeNaming` method and only one `NameHelper` is needed. In order to deal with the Bar/Baz parametrization the `doSomeNaming` and the `NameHelper` would have been generalized a bit for the two possible options, and there would have been only one `NameHelper`, capable of dealing with both cases.

      Reply
      1. Timothy Onogu

        Ohh. Ok I get, Thanks for clarifying.
        With respect to your post,
        http://arne-mertz.de/2015/02/adherence-to-design-patterns/

        Originaly,

        NameHelper

        should be as simple as it was. Fine.

        Now that we needed same interface but slightly different behaviour, can we then adopt a design pattern? 🙂

        (i.e A minimal Policy-based design? Optionally supply an to change the behaviour? )

        Thanks.

        Reply
        1. Arne Mertz

          It depends. As far as I remember the difference in this case was only the info attribute, so it probably could be just made an empty string for the original case.
          would usually think twice (at least) before considering a design pattern for helper classes. helper classes usually provide only a small part of a functionality. using a design pattern usually implies having several classes providing a complete functionality, i.e. more than just a helper class.

          Reply

Leave a Reply

Your email address will not be published. Required fields are marked *