Bridge pattern? What is the use?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Adrian

    #1

    Bridge pattern? What is the use?

    The code below was taken from an example.
    All the "noise" in the example was thrown out.
    This is supposedly according to the bridge
    pattern. What in the code (which lines)
    represent the bridge pattern (make this code
    to be according to the bridge pattern),
    and what is the advantage of employing the
    bridge pattern? It seems "l'art pour l'art" to me.

    Adrian

    using System.Collecti ons;

    namespace trial_seven
    {
    class Class1
    {
    [STAThread]
    static void Main(string[] args)
    {
    Customers customers = new Customers("Chic ago");
    customers.Data = new CustomersData() ;
    customers.show( );
    customers.show( );
    }

    class CustomersBase
    {
    private DataObject dataObject;
    protected string group;
    public CustomersBase(s tring group)
    {
    this.group = group;
    }

    public DataObject Data
    {
    set
    {
    dataObject = value;
    }
    get
    {
    return dataObject;
    }
    }

    public virtual void show()
    {
    dataObject.Show Record();
    }
    }

    class Customers:Custo mersBase
    {
    public Customers (string group):base(gro up)
    {
    }
    }

    abstract class DataObject
    {
    public abstract void ShowRecord();
    }

    class CustomersData:D ataObject
    {
    private ArrayList customers = new ArrayList();
    private static int current = 0;

    public CustomersData()
    {
    customers.Add(" Jim Jones");
    customers.Add(" Frank Rapper");
    }
    public override void ShowRecord()
    {
    Console.WriteLi ne(customers[current++]);
    }
    }
    }
    }


  • Chris Fulstow

    #2
    Re: Bridge pattern? What is the use?

    l'art pour decoupler une abstraction de son execution ;)


    Adrian wrote:
    The code below was taken from an example.
    All the "noise" in the example was thrown out.
    This is supposedly according to the bridge
    pattern. What in the code (which lines)
    represent the bridge pattern (make this code
    to be according to the bridge pattern),
    and what is the advantage of employing the
    bridge pattern? It seems "l'art pour l'art" to me.
    >
    Adrian
    >
    using System.Collecti ons;
    >
    namespace trial_seven
    {
    class Class1
    {
    [STAThread]
    static void Main(string[] args)
    {
    Customers customers = new Customers("Chic ago");
    customers.Data = new CustomersData() ;
    customers.show( );
    customers.show( );
    }
    >
    class CustomersBase
    {
    private DataObject dataObject;
    protected string group;
    public CustomersBase(s tring group)
    {
    this.group = group;
    }
    >
    public DataObject Data
    {
    set
    {
    dataObject = value;
    }
    get
    {
    return dataObject;
    }
    }
    >
    public virtual void show()
    {
    dataObject.Show Record();
    }
    }
    >
    class Customers:Custo mersBase
    {
    public Customers (string group):base(gro up)
    {
    }
    }
    >
    abstract class DataObject
    {
    public abstract void ShowRecord();
    }
    >
    class CustomersData:D ataObject
    {
    private ArrayList customers = new ArrayList();
    private static int current = 0;
    >
    public CustomersData()
    {
    customers.Add(" Jim Jones");
    customers.Add(" Frank Rapper");
    }
    public override void ShowRecord()
    {
    Console.WriteLi ne(customers[current++]);
    }
    }
    }
    }

    Comment

    • Adrian

      #3
      Re: Bridge pattern? What is the use?

      "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
      news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
      l'art pour decoupler une abstraction de son execution ;)

      >
      Yes that is where I got it from :(

      "decoupler une abstraction de son execution"
      That is happening twice in my perception,
      but that doesn't seem to be specific for
      what the code is purporting to represent,
      namely a bridge. I could image show, called
      in main, and, in turn, calling ShowRecord, to
      be the bridge. But what is so useful about
      doing that? Obfuscation or 3-tier stuff?



      Comment

      • Chris Fulstow

        #4
        Re: Bridge pattern? What is the use?

        Not the easiest pattern to get your head around, but this article
        explains it pretty well:


        Adrian wrote:
        "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
        news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
        l'art pour decoupler une abstraction de son execution ;)
        Yes that is where I got it from :(
        >
        "decoupler une abstraction de son execution"
        That is happening twice in my perception,
        but that doesn't seem to be specific for
        what the code is purporting to represent,
        namely a bridge. I could image show, called
        in main, and, in turn, calling ShowRecord, to
        be the bridge. But what is so useful about
        doing that? Obfuscation or 3-tier stuff?

        Comment

        • Dave Sexton

          #5
          Re: Bridge pattern? What is the use?

          Hi Adrian,

          Maybe this link will clear it up more for you:

          G.O.F. on Bridge:
          Learn how to use the C# Bridge design pattern to decouple an abstraction from its implementation, with quick and easy examples. 100% Source code.



          I believe you have partially identified the bridge. The part that you didn't acknowledge is the two abstract classes and the
          decoupling of the implementation.

          The GOF example is much clearer, IMO. Look at the C# code sample.

          To equate their sample to your sample:

          [STAThread]
          static void Main(string[] args)
          {
          Customers customers = new Customers("Chic ago");
          customers.Data = new CustomersData() ;
          customers.show( );

          customers.Data = new PrimaryCustomer sData();
          customers.show( );

          customers.Data = new SpecialProcessC ustomersData();
          customers.show( );
          }


          Also, note that show can call multiple methods on the Data object if necessary, so it doesn't have to simply be pass-thru as in
          these examples. In that case the concrete CustomerBase implementation acts as a facade as well. Also, concrete CustomerBase
          implementations would commonly have different, higher-level methods than the associated Data object.

          Its useage might be even clearer if you look at a method that takes a parameter of type, "CustomerBa se". In that case the benefit
          of both the abstraction and decoupling of implementation is more apparent:

          public void ShowCustomerToU ser(CustomerBas e customer)
          {
          customer.show() ;
          }

          HTH

          --
          Dave Sexton

          "Adrian" <not@all.access iblewrote in message news:452ccb2f$0 $723$5fc3050@dr eader2.news.tis cali.nl...
          "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
          news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
          >l'art pour decoupler une abstraction de son execution ;)
          >http://en.wikipedia.org/wiki/Bridge_pattern
          >>
          Yes that is where I got it from :(
          >
          "decoupler une abstraction de son execution"
          That is happening twice in my perception,
          but that doesn't seem to be specific for
          what the code is purporting to represent,
          namely a bridge. I could image show, called
          in main, and, in turn, calling ShowRecord, to
          be the bridge. But what is so useful about
          doing that? Obfuscation or 3-tier stuff?
          >
          >
          >

          Comment

          • Adrian

            #6
            Re: Bridge pattern? What is the use?

            Is using abstract and concrete classes (decoupling)
            for hiding the concrete classes from users? If not,
            why is it done?



            "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
            news:O$nJFjS7GH A.4500@TK2MSFTN GP02.phx.gbl...
            Hi Adrian,
            >
            Maybe this link will clear it up more for you:
            >
            G.O.F. on Bridge:
            Learn how to use the C# Bridge design pattern to decouple an abstraction from its implementation, with quick and easy examples. 100% Source code.

            >
            >
            I believe you have partially identified the bridge. The part that you
            didn't acknowledge is the two abstract classes and the
            decoupling of the implementation.
            >
            The GOF example is much clearer, IMO. Look at the C# code sample.
            >
            To equate their sample to your sample:
            >
            [STAThread]
            static void Main(string[] args)
            {
            Customers customers = new Customers("Chic ago");
            customers.Data = new CustomersData() ;
            customers.show( );
            >
            customers.Data = new PrimaryCustomer sData();
            customers.show( );
            >
            customers.Data = new SpecialProcessC ustomersData();
            customers.show( );
            }
            >
            >
            Also, note that show can call multiple methods on the Data object if
            necessary, so it doesn't have to simply be pass-thru as in
            these examples. In that case the concrete CustomerBase implementation
            acts as a facade as well. Also, concrete CustomerBase
            implementations would commonly have different, higher-level methods than
            the associated Data object.
            >
            Its useage might be even clearer if you look at a method that takes a
            parameter of type, "CustomerBa se". In that case the benefit
            of both the abstraction and decoupling of implementation is more apparent:
            >
            public void ShowCustomerToU ser(CustomerBas e customer)
            {
            customer.show() ;
            }
            >
            HTH
            >
            --
            Dave Sexton
            >
            "Adrian" <not@all.access iblewrote in message
            news:452ccb2f$0 $723$5fc3050@dr eader2.news.tis cali.nl...
            "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
            news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
            l'art pour decoupler une abstraction de son execution ;)

            >
            Yes that is where I got it from :(

            "decoupler une abstraction de son execution"
            That is happening twice in my perception,
            but that doesn't seem to be specific for
            what the code is purporting to represent,
            namely a bridge. I could image show, called
            in main, and, in turn, calling ShowRecord, to
            be the bridge. But what is so useful about
            doing that? Obfuscation or 3-tier stuff?

            >
            >

            Comment

            • Dave Sexton

              #7
              Re: Bridge pattern? What is the use?

              Hi Adrian,

              Exactly. By using an abstract class you can swap out the implementation in the caller whenever you need to refactor your code and
              it enables your code to be dynamic enough when you need to vary implementations at runtime. The consumer of the class doesn't need
              to be aware of the implemention, it just needs a reference to the interface (abstract class in this case).

              Be aware when using patterns that decouple implemention by using polymorphism that if you see something like the following you
              should probably invest your time in finding a more appropriate pattern to meet your needs:

              public void ShowCustomerToU ser(CustomerBas e customer)
              {
              if (customer.GetTy pe() == typeof(SpecialP rocessCustomerD ata))
              {
              // we require a special process to occur first, in this case
              customer.Specia lProcess();
              }

              // all customers may be "shown"
              customer.show() ;
              }

              Hopefully you see the benefit of the bridge pattern and how it could be used to alleviate any need for the explicit Type check
              above. The idea is to "abstract" the "ShowCustomerTo User" method from requiring a reference or any knowledge at all of the
              implementation of the specified "customer" object.

              public class SpecialProcessC ustomerData : DataObject
              {
              public void show()
              {
              // TODO: special processing
              // TODO: show something
              }
              }

              --
              Dave Sexton

              "Adrian" <not@all.access iblewrote in message news:452ce2a7$0 $752$5fc3050@dr eader2.news.tis cali.nl...
              Is using abstract and concrete classes (decoupling)
              for hiding the concrete classes from users? If not,
              why is it done?
              >
              >
              >
              "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
              news:O$nJFjS7GH A.4500@TK2MSFTN GP02.phx.gbl...
              >Hi Adrian,
              >>
              >Maybe this link will clear it up more for you:
              >>
              >G.O.F. on Bridge:
              >http://www.dofactory.com/Patterns/PatternBridge.aspx
              >>
              >>
              >I believe you have partially identified the bridge. The part that you
              didn't acknowledge is the two abstract classes and the
              >decoupling of the implementation.
              >>
              >The GOF example is much clearer, IMO. Look at the C# code sample.
              >>
              >To equate their sample to your sample:
              >>
              > [STAThread]
              > static void Main(string[] args)
              > {
              > Customers customers = new Customers("Chic ago");
              > customers.Data = new CustomersData() ;
              > customers.show( );
              >>
              > customers.Data = new PrimaryCustomer sData();
              > customers.show( );
              >>
              > customers.Data = new SpecialProcessC ustomersData();
              > customers.show( );
              > }
              >>
              >>
              >Also, note that show can call multiple methods on the Data object if
              necessary, so it doesn't have to simply be pass-thru as in
              >these examples. In that case the concrete CustomerBase implementation
              acts as a facade as well. Also, concrete CustomerBase
              >implementation s would commonly have different, higher-level methods than
              the associated Data object.
              >>
              >Its useage might be even clearer if you look at a method that takes a
              parameter of type, "CustomerBa se". In that case the benefit
              >of both the abstraction and decoupling of implementation is more apparent:
              >>
              >public void ShowCustomerToU ser(CustomerBas e customer)
              >{
              > customer.show() ;
              >}
              >>
              >HTH
              >>
              >--
              >Dave Sexton
              >>
              >"Adrian" <not@all.access iblewrote in message
              news:452ccb2f$0 $723$5fc3050@dr eader2.news.tis cali.nl...
              "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
              news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
              >l'art pour decoupler une abstraction de son execution ;)
              >http://en.wikipedia.org/wiki/Bridge_pattern
              >>
              Yes that is where I got it from :(
              >
              "decoupler une abstraction de son execution"
              That is happening twice in my perception,
              but that doesn't seem to be specific for
              what the code is purporting to represent,
              namely a bridge. I could image show, called
              in main, and, in turn, calling ShowRecord, to
              be the bridge. But what is so useful about
              doing that? Obfuscation or 3-tier stuff?
              >
              >
              >
              >>
              >>
              >
              >

              Comment

              • Adrian

                #8
                Re: Bridge pattern? What is the use?

                In case of: / if you do as you suggest:
                customers.Data = new PrimaryCustomer sData();
                customers.show( );
                customers[] isn't filled
                and the appp errors out



                "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
                news:O$nJFjS7GH A.4500@TK2MSFTN GP02.phx.gbl...
                Hi Adrian,
                >
                Maybe this link will clear it up more for you:
                >
                G.O.F. on Bridge:
                Learn how to use the C# Bridge design pattern to decouple an abstraction from its implementation, with quick and easy examples. 100% Source code.

                >
                >
                I believe you have partially identified the bridge. The part that you
                didn't acknowledge is the two abstract classes and the
                decoupling of the implementation.
                >
                The GOF example is much clearer, IMO. Look at the C# code sample.
                >
                To equate their sample to your sample:
                >
                [STAThread]
                static void Main(string[] args)
                {
                Customers customers = new Customers("Chic ago");
                customers.Data = new CustomersData() ;
                customers.show( );
                >
                customers.Data = new PrimaryCustomer sData();
                customers.show( );
                >
                customers.Data = new SpecialProcessC ustomersData();
                customers.show( );
                }
                >
                >
                Also, note that show can call multiple methods on the Data object if
                necessary, so it doesn't have to simply be pass-thru as in
                these examples. In that case the concrete CustomerBase implementation
                acts as a facade as well. Also, concrete CustomerBase
                implementations would commonly have different, higher-level methods than
                the associated Data object.
                >
                Its useage might be even clearer if you look at a method that takes a
                parameter of type, "CustomerBa se". In that case the benefit
                of both the abstraction and decoupling of implementation is more apparent:
                >
                public void ShowCustomerToU ser(CustomerBas e customer)
                {
                customer.show() ;
                }
                >
                HTH
                >
                --
                Dave Sexton
                >
                "Adrian" <not@all.access iblewrote in message
                news:452ccb2f$0 $723$5fc3050@dr eader2.news.tis cali.nl...
                "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
                news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
                l'art pour decoupler une abstraction de son execution ;)

                >
                Yes that is where I got it from :(

                "decoupler une abstraction de son execution"
                That is happening twice in my perception,
                but that doesn't seem to be specific for
                what the code is purporting to represent,
                namely a bridge. I could image show, called
                in main, and, in turn, calling ShowRecord, to
                be the bridge. But what is so useful about
                doing that? Obfuscation or 3-tier stuff?

                >
                >

                Comment

                • Adrian

                  #9
                  Re: Bridge pattern? What is the use?

                  By the way I did add on another child of DataObject.

                  "Adrian" <not@all.access iblewrote in message
                  news:452ceadf$0 $740$5fc3050@dr eader2.news.tis cali.nl...
                  In case of: / if you do as you suggest:
                  >
                  customers.Data = new PrimaryCustomer sData();
                  customers.show( );
                  >
                  customers[] isn't filled
                  and the appp errors out
                  >
                  >
                  >
                  "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
                  news:O$nJFjS7GH A.4500@TK2MSFTN GP02.phx.gbl...
                  Hi Adrian,

                  Maybe this link will clear it up more for you:

                  G.O.F. on Bridge:
                  Learn how to use the C# Bridge design pattern to decouple an abstraction from its implementation, with quick and easy examples. 100% Source code.



                  I believe you have partially identified the bridge. The part that you
                  didn't acknowledge is the two abstract classes and the
                  decoupling of the implementation.

                  The GOF example is much clearer, IMO. Look at the C# code sample.

                  To equate their sample to your sample:

                  [STAThread]
                  static void Main(string[] args)
                  {
                  Customers customers = new Customers("Chic ago");
                  customers.Data = new CustomersData() ;
                  customers.show( );

                  customers.Data = new PrimaryCustomer sData();
                  customers.show( );

                  customers.Data = new SpecialProcessC ustomersData();
                  customers.show( );
                  }


                  Also, note that show can call multiple methods on the Data object if
                  necessary, so it doesn't have to simply be pass-thru as in
                  these examples. In that case the concrete CustomerBase implementation
                  acts as a facade as well. Also, concrete CustomerBase
                  implementations would commonly have different, higher-level methods than
                  the associated Data object.

                  Its useage might be even clearer if you look at a method that takes a
                  parameter of type, "CustomerBa se". In that case the benefit
                  of both the abstraction and decoupling of implementation is more
                  apparent:

                  public void ShowCustomerToU ser(CustomerBas e customer)
                  {
                  customer.show() ;
                  }

                  HTH

                  --
                  Dave Sexton

                  "Adrian" <not@all.access iblewrote in message
                  news:452ccb2f$0 $723$5fc3050@dr eader2.news.tis cali.nl...
                  "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
                  news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
                  >l'art pour decoupler une abstraction de son execution ;)
                  >http://en.wikipedia.org/wiki/Bridge_pattern
                  >>
                  Yes that is where I got it from :(
                  >
                  "decoupler une abstraction de son execution"
                  That is happening twice in my perception,
                  but that doesn't seem to be specific for
                  what the code is purporting to represent,
                  namely a bridge. I could image show, called
                  in main, and, in turn, calling ShowRecord, to
                  be the bridge. But what is so useful about
                  doing that? Obfuscation or 3-tier stuff?
                  >
                  >
                  >
                  >
                  >

                  Comment

                  • Dave Sexton

                    #10
                    Re: Bridge pattern? What is the use?

                    Hi Adrian,

                    I'm not sure I understand what you mean. The app won't even compile because the PrimaryCustomer sData class isn't defined. I was
                    just trying to illustrate a point: Being able to assign any implementation to the Data property is part of the flexibility provided
                    by the bridge pattern.

                    If you tried to compile the application after creating your own PrimaryCustomer sData class then it's your implementation that is
                    failing.

                    Care to post your code?

                    --
                    Dave Sexton

                    "Adrian" <not@all.access iblewrote in message news:452ceadf$0 $740$5fc3050@dr eader2.news.tis cali.nl...
                    In case of: / if you do as you suggest:
                    >
                    > customers.Data = new PrimaryCustomer sData();
                    > customers.show( );
                    >
                    customers[] isn't filled
                    and the appp errors out
                    >
                    >
                    >
                    "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
                    news:O$nJFjS7GH A.4500@TK2MSFTN GP02.phx.gbl...
                    >Hi Adrian,
                    >>
                    >Maybe this link will clear it up more for you:
                    >>
                    >G.O.F. on Bridge:
                    >http://www.dofactory.com/Patterns/PatternBridge.aspx
                    >>
                    >>
                    >I believe you have partially identified the bridge. The part that you
                    didn't acknowledge is the two abstract classes and the
                    >decoupling of the implementation.
                    >>
                    >The GOF example is much clearer, IMO. Look at the C# code sample.
                    >>
                    >To equate their sample to your sample:
                    >>
                    > [STAThread]
                    > static void Main(string[] args)
                    > {
                    > Customers customers = new Customers("Chic ago");
                    > customers.Data = new CustomersData() ;
                    > customers.show( );
                    >>
                    > customers.Data = new PrimaryCustomer sData();
                    > customers.show( );
                    >>
                    > customers.Data = new SpecialProcessC ustomersData();
                    > customers.show( );
                    > }
                    >>
                    >>
                    >Also, note that show can call multiple methods on the Data object if
                    necessary, so it doesn't have to simply be pass-thru as in
                    >these examples. In that case the concrete CustomerBase implementation
                    acts as a facade as well. Also, concrete CustomerBase
                    >implementation s would commonly have different, higher-level methods than
                    the associated Data object.
                    >>
                    >Its useage might be even clearer if you look at a method that takes a
                    parameter of type, "CustomerBa se". In that case the benefit
                    >of both the abstraction and decoupling of implementation is more apparent:
                    >>
                    >public void ShowCustomerToU ser(CustomerBas e customer)
                    >{
                    > customer.show() ;
                    >}
                    >>
                    >HTH
                    >>
                    >--
                    >Dave Sexton
                    >>
                    >"Adrian" <not@all.access iblewrote in message
                    news:452ccb2f$0 $723$5fc3050@dr eader2.news.tis cali.nl...
                    "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
                    news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
                    >l'art pour decoupler une abstraction de son execution ;)
                    >http://en.wikipedia.org/wiki/Bridge_pattern
                    >>
                    Yes that is where I got it from :(
                    >
                    "decoupler une abstraction de son execution"
                    That is happening twice in my perception,
                    but that doesn't seem to be specific for
                    what the code is purporting to represent,
                    namely a bridge. I could image show, called
                    in main, and, in turn, calling ShowRecord, to
                    be the bridge. But what is so useful about
                    doing that? Obfuscation or 3-tier stuff?
                    >
                    >
                    >
                    >>
                    >>
                    >
                    >

                    Comment

                    • Adrian

                      #11
                      Re: Bridge pattern? What is the use?

                      Dave, I can see what you are getting at here. How the bridge pattern does a
                      better job
                      then polymorphism.

                      I have successfully implemented your suggestions to bear out the workings of
                      the example a bit better now.

                      Your remarks do a good job in explaining the know-why of the bridge pattern.

                      Unfortunately too often *only* know-how and know-when is explained.

                      Many thanks,
                      Adrian. (Nom de plume.)

                      "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
                      news:O2CC8PT7GH A.3960@TK2MSFTN GP05.phx.gbl...
                      Hi Adrian,
                      >
                      Exactly. By using an abstract class you can swap out the implementation
                      in the caller whenever you need to refactor your code and
                      it enables your code to be dynamic enough when you need to vary
                      implementations at runtime. The consumer of the class doesn't need
                      to be aware of the implemention, it just needs a reference to the
                      interface (abstract class in this case).
                      >
                      Be aware when using patterns that decouple implemention by using
                      polymorphism that if you see something like the following you
                      should probably invest your time in finding a more appropriate pattern to
                      meet your needs:
                      >
                      public void ShowCustomerToU ser(CustomerBas e customer)
                      {
                      if (customer.GetTy pe() == typeof(SpecialP rocessCustomerD ata))
                      {
                      // we require a special process to occur first, in this case
                      customer.Specia lProcess();
                      }
                      >
                      // all customers may be "shown"
                      customer.show() ;
                      }
                      >
                      Hopefully you see the benefit of the bridge pattern and how it could be
                      used to alleviate any need for the explicit Type check
                      above. The idea is to "abstract" the "ShowCustomerTo User" method from
                      requiring a reference or any knowledge at all of the
                      implementation of the specified "customer" object.
                      >
                      public class SpecialProcessC ustomerData : DataObject
                      {
                      public void show()
                      {
                      // TODO: special processing
                      // TODO: show something
                      }
                      }
                      >
                      --
                      Dave Sexton
                      >
                      "Adrian" <not@all.access iblewrote in message
                      news:452ce2a7$0 $752$5fc3050@dr eader2.news.tis cali.nl...
                      Is using abstract and concrete classes (decoupling)
                      for hiding the concrete classes from users? If not,
                      why is it done?



                      "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
                      news:O$nJFjS7GH A.4500@TK2MSFTN GP02.phx.gbl...
                      Hi Adrian,
                      >
                      Maybe this link will clear it up more for you:
                      >
                      G.O.F. on Bridge:
                      Learn how to use the C# Bridge design pattern to decouple an abstraction from its implementation, with quick and easy examples. 100% Source code.

                      >
                      >
                      I believe you have partially identified the bridge. The part that you
                      didn't acknowledge is the two abstract classes and the
                      decoupling of the implementation.
                      >
                      The GOF example is much clearer, IMO. Look at the C# code sample.
                      >
                      To equate their sample to your sample:
                      >
                      [STAThread]
                      static void Main(string[] args)
                      {
                      Customers customers = new Customers("Chic ago");
                      customers.Data = new CustomersData() ;
                      customers.show( );
                      >
                      customers.Data = new PrimaryCustomer sData();
                      customers.show( );
                      >
                      customers.Data = new SpecialProcessC ustomersData();
                      customers.show( );
                      }
                      >
                      >
                      Also, note that show can call multiple methods on the Data object if
                      necessary, so it doesn't have to simply be pass-thru as in
                      these examples. In that case the concrete CustomerBase implementation
                      acts as a facade as well. Also, concrete CustomerBase
                      implementations would commonly have different, higher-level methods
                      than
                      the associated Data object.
                      >
                      Its useage might be even clearer if you look at a method that takes a
                      parameter of type, "CustomerBa se". In that case the benefit
                      of both the abstraction and decoupling of implementation is more
                      apparent:
                      >
                      public void ShowCustomerToU ser(CustomerBas e customer)
                      {
                      customer.show() ;
                      }
                      >
                      HTH
                      >
                      --
                      Dave Sexton
                      >
                      "Adrian" <not@all.access iblewrote in message
                      news:452ccb2f$0 $723$5fc3050@dr eader2.news.tis cali.nl...
                      "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
                      news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
                      l'art pour decoupler une abstraction de son execution ;)

                      >
                      Yes that is where I got it from :(

                      "decoupler une abstraction de son execution"
                      That is happening twice in my perception,
                      but that doesn't seem to be specific for
                      what the code is purporting to represent,
                      namely a bridge. I could image show, called
                      in main, and, in turn, calling ShowRecord, to
                      be the bridge. But what is so useful about
                      doing that? Obfuscation or 3-tier stuff?



                      >
                      >
                      >
                      >

                      Comment

                      • Adrian

                        #12
                        Re: Bridge pattern? What is the use?

                        Dave, please see my other post to you.
                        Many thanks.



                        "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
                        news:eQGzcbT7GH A.844@TK2MSFTNG P03.phx.gbl...
                        Hi Adrian,
                        >
                        I'm not sure I understand what you mean. The app won't even compile
                        because the PrimaryCustomer sData class isn't defined. I was
                        just trying to illustrate a point: Being able to assign any
                        implementation to the Data property is part of the flexibility provided
                        by the bridge pattern.
                        >
                        If you tried to compile the application after creating your own
                        PrimaryCustomer sData class then it's your implementation that is
                        failing.
                        >
                        Care to post your code?
                        >
                        --
                        Dave Sexton
                        >
                        "Adrian" <not@all.access iblewrote in message
                        news:452ceadf$0 $740$5fc3050@dr eader2.news.tis cali.nl...
                        In case of: / if you do as you suggest:
                        customers.Data = new PrimaryCustomer sData();
                        customers.show( );
                        customers[] isn't filled
                        and the appp errors out



                        "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
                        news:O$nJFjS7GH A.4500@TK2MSFTN GP02.phx.gbl...
                        Hi Adrian,
                        >
                        Maybe this link will clear it up more for you:
                        >
                        G.O.F. on Bridge:
                        Learn how to use the C# Bridge design pattern to decouple an abstraction from its implementation, with quick and easy examples. 100% Source code.

                        >
                        >
                        I believe you have partially identified the bridge. The part that you
                        didn't acknowledge is the two abstract classes and the
                        decoupling of the implementation.
                        >
                        The GOF example is much clearer, IMO. Look at the C# code sample.
                        >
                        To equate their sample to your sample:
                        >
                        [STAThread]
                        static void Main(string[] args)
                        {
                        Customers customers = new Customers("Chic ago");
                        customers.Data = new CustomersData() ;
                        customers.show( );
                        >
                        customers.Data = new PrimaryCustomer sData();
                        customers.show( );
                        >
                        customers.Data = new SpecialProcessC ustomersData();
                        customers.show( );
                        }
                        >
                        >
                        Also, note that show can call multiple methods on the Data object if
                        necessary, so it doesn't have to simply be pass-thru as in
                        these examples. In that case the concrete CustomerBase implementation
                        acts as a facade as well. Also, concrete CustomerBase
                        implementations would commonly have different, higher-level methods
                        than
                        the associated Data object.
                        >
                        Its useage might be even clearer if you look at a method that takes a
                        parameter of type, "CustomerBa se". In that case the benefit
                        of both the abstraction and decoupling of implementation is more
                        apparent:
                        >
                        public void ShowCustomerToU ser(CustomerBas e customer)
                        {
                        customer.show() ;
                        }
                        >
                        HTH
                        >
                        --
                        Dave Sexton
                        >
                        "Adrian" <not@all.access iblewrote in message
                        news:452ccb2f$0 $723$5fc3050@dr eader2.news.tis cali.nl...
                        "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
                        news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
                        l'art pour decoupler une abstraction de son execution ;)

                        >
                        Yes that is where I got it from :(

                        "decoupler une abstraction de son execution"
                        That is happening twice in my perception,
                        but that doesn't seem to be specific for
                        what the code is purporting to represent,
                        namely a bridge. I could image show, called
                        in main, and, in turn, calling ShowRecord, to
                        be the bridge. But what is so useful about
                        doing that? Obfuscation or 3-tier stuff?



                        >
                        >
                        >
                        >

                        Comment

                        • Dave Sexton

                          #13
                          Re: Bridge pattern? What is the use?

                          Hi Adrian,

                          Glad I could help.
                          Unfortunately too often *only* know-how and know-when is explained.
                          I agree, but books and in-depth articles usually fill in the blanks nicely.

                          --
                          Dave Sexton

                          "Adrian" <not@all.access iblewrote in message news:452cf517$0 $730$5fc3050@dr eader2.news.tis cali.nl...
                          Dave, I can see what you are getting at here. How the bridge pattern does a
                          better job
                          then polymorphism.
                          >
                          I have successfully implemented your suggestions to bear out the workings of
                          the example a bit better now.
                          >
                          Your remarks do a good job in explaining the know-why of the bridge pattern.
                          >
                          Unfortunately too often *only* know-how and know-when is explained.
                          >
                          Many thanks,
                          Adrian. (Nom de plume.)
                          >
                          "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
                          news:O2CC8PT7GH A.3960@TK2MSFTN GP05.phx.gbl...
                          >Hi Adrian,
                          >>
                          >Exactly. By using an abstract class you can swap out the implementation
                          in the caller whenever you need to refactor your code and
                          >it enables your code to be dynamic enough when you need to vary
                          implementations at runtime. The consumer of the class doesn't need
                          >to be aware of the implemention, it just needs a reference to the
                          interface (abstract class in this case).
                          >>
                          >Be aware when using patterns that decouple implemention by using
                          polymorphism that if you see something like the following you
                          >should probably invest your time in finding a more appropriate pattern to
                          meet your needs:
                          >>
                          >public void ShowCustomerToU ser(CustomerBas e customer)
                          >{
                          > if (customer.GetTy pe() == typeof(SpecialP rocessCustomerD ata))
                          > {
                          > // we require a special process to occur first, in this case
                          > customer.Specia lProcess();
                          > }
                          >>
                          > // all customers may be "shown"
                          > customer.show() ;
                          >}
                          >>
                          >Hopefully you see the benefit of the bridge pattern and how it could be
                          used to alleviate any need for the explicit Type check
                          >above. The idea is to "abstract" the "ShowCustomerTo User" method from
                          requiring a reference or any knowledge at all of the
                          >implementati on of the specified "customer" object.
                          >>
                          >public class SpecialProcessC ustomerData : DataObject
                          >{
                          > public void show()
                          > {
                          > // TODO: special processing
                          > // TODO: show something
                          > }
                          >}
                          >>
                          >--
                          >Dave Sexton
                          >>
                          >"Adrian" <not@all.access iblewrote in message
                          news:452ce2a7$0 $752$5fc3050@dr eader2.news.tis cali.nl...
                          Is using abstract and concrete classes (decoupling)
                          for hiding the concrete classes from users? If not,
                          why is it done?
                          >
                          >
                          >
                          "Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
                          news:O$nJFjS7GH A.4500@TK2MSFTN GP02.phx.gbl...
                          >Hi Adrian,
                          >>
                          >Maybe this link will clear it up more for you:
                          >>
                          >G.O.F. on Bridge:
                          >http://www.dofactory.com/Patterns/PatternBridge.aspx
                          >>
                          >>
                          >I believe you have partially identified the bridge. The part that you
                          didn't acknowledge is the two abstract classes and the
                          >decoupling of the implementation.
                          >>
                          >The GOF example is much clearer, IMO. Look at the C# code sample.
                          >>
                          >To equate their sample to your sample:
                          >>
                          > [STAThread]
                          > static void Main(string[] args)
                          > {
                          > Customers customers = new Customers("Chic ago");
                          > customers.Data = new CustomersData() ;
                          > customers.show( );
                          >>
                          > customers.Data = new PrimaryCustomer sData();
                          > customers.show( );
                          >>
                          > customers.Data = new SpecialProcessC ustomersData();
                          > customers.show( );
                          > }
                          >>
                          >>
                          >Also, note that show can call multiple methods on the Data object if
                          necessary, so it doesn't have to simply be pass-thru as in
                          >these examples. In that case the concrete CustomerBase implementation
                          acts as a facade as well. Also, concrete CustomerBase
                          >implementation s would commonly have different, higher-level methods
                          than
                          the associated Data object.
                          >>
                          >Its useage might be even clearer if you look at a method that takes a
                          parameter of type, "CustomerBa se". In that case the benefit
                          >of both the abstraction and decoupling of implementation is more
                          apparent:
                          >>
                          >public void ShowCustomerToU ser(CustomerBas e customer)
                          >{
                          > customer.show() ;
                          >}
                          >>
                          >HTH
                          >>
                          >--
                          >Dave Sexton
                          >>
                          >"Adrian" <not@all.access iblewrote in message
                          news:452ccb2f$0 $723$5fc3050@dr eader2.news.tis cali.nl...
                          "Chris Fulstow" <chrisfulstow@h otmail.comwrote in message
                          news:1160562469 .360612.124760@ b28g2000cwb.goo glegroups.com.. .
                          >l'art pour decoupler une abstraction de son execution ;)
                          >http://en.wikipedia.org/wiki/Bridge_pattern
                          >>
                          Yes that is where I got it from :(
                          >
                          "decoupler une abstraction de son execution"
                          That is happening twice in my perception,
                          but that doesn't seem to be specific for
                          what the code is purporting to represent,
                          namely a bridge. I could image show, called
                          in main, and, in turn, calling ShowRecord, to
                          be the bridge. But what is so useful about
                          doing that? Obfuscation or 3-tier stuff?
                          >
                          >
                          >
                          >>
                          >>
                          >
                          >
                          >>
                          >>
                          >
                          >

                          Comment

                          Working...