Abstracting classes

Discussion in 'Java' started by -, Jul 25, 2005.

  1. -

    - Guest

    I'm having a hard time deciding how to abstract classes:

    Method 1)
    package net.xxx.XXXConnection;
    package net.xxx.tcp.TcpXXXConnection;
    package net.xxx.udp.UdpXXXConnection;


    Method 2)
    package net.TcpConnection;
    package net.UdpConnection;
    package net.tcp.xxx.XXXTcpConnection;
    package net.udp.xxx.XXXUdpConnection;


    where xxx refers to protocols that use tcp and udp.


    Either way of doing it, I find my classes having portions of code that
    are duplicated.
    -, Jul 25, 2005
    #1
    1. Advertising

  2. Hi,

    > Either way of doing it, I find my classes having portions of code that
    > are duplicated.


    Perhaps, your Design is not good. Maybe you are using a class hierarchie
    where delegation would be better:

    abstract class Connection {
    public void write(...);
    }

    class TcpConnection extends Connection {...}

    class UdpConnection extends Connection {...}

    class XMLStream {
    private Connection conn;
    public void write(...) {
    con.write("<xml>");
    con.write(...);
    }
    }

    class BinaryStream {
    private Connection conn;
    public void write(...) {
    con.write(...);
    }
    }

    As for your original question: In this case, the package-structure would
    be somehow different!

    Ciao,
    Ingo
    Ingo R. Homann, Jul 25, 2005
    #2
    1. Advertising

  3. -

    Guest

    - skrev:
    > I'm having a hard time deciding how to abstract classes:
    >
    > Method 1)
    > package net.xxx.XXXConnection;
    > package net.xxx.tcp.TcpXXXConnection;
    > package net.xxx.udp.UdpXXXConnection;
    >
    >
    > Method 2)
    > package net.TcpConnection;
    > package net.UdpConnection;
    > package net.tcp.xxx.XXXTcpConnection;
    > package net.udp.xxx.XXXUdpConnection;
    >
    >
    > where xxx refers to protocols that use tcp and udp.
    >
    >
    > Either way of doing it, I find my classes having portions of code that
    > are duplicated.


    Hi,

    (Let's say you're implementing an FTP application, to avoid those
    XXXs.)

    I'd have to agree with Ingo's delegation proposal.

    Having an class such as FtpTcpConnection looks combinatorially
    explosive, and rigidly ties a higher layer implementation to a lower
    layer.

    I think you should look for an abstraction of both the TcpConnection
    and the UdpConnection, and call it the TransportLayerConnection. A
    factory in the transportlayer package can then return either the UDP or
    TCP implementation behind a TransportLayerConnection interface.

    Thus you'll have:
    package net.ftp;
    import net.transportlayer.TransportLayerConnection;
    import net.transportlayer.TransportLayerFactory;
    import net.transportlayer.udp.TcpConnection;
    import net.transportlayer.tcp.UdpConnection;

    As for duplicated code, regardless of package structure, you can always
    lump duplicated code into its own, common package. Give then example
    above, however, a clear candidate would be:
    package net.transportlayer.common;

    Finally, if your application sits higher in the stack than FTP, then
    any potential FtpConnection should be abstracted to something like
    SessionLayerConnection.

    ..ed

    --
    www.EdmundKirwan.com - Home of The Fractal Class Composition.
    , Jul 25, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tim Barnes
    Replies:
    0
    Views:
    326
    Tim Barnes
    Aug 24, 2003
  2. Christopher M. Balz
    Replies:
    0
    Views:
    324
    Christopher M. Balz
    Sep 14, 2003
  3. Replies:
    1
    Views:
    241
    Markus Schoder
    May 11, 2006
  4. Guest
    Replies:
    1
    Views:
    341
    Guest
    Mar 16, 2007
  5. Martin Hansen

    Abstracting exception handling

    Martin Hansen, Aug 5, 2010, in forum: Ruby
    Replies:
    14
    Views:
    219
    Martin Hansen
    Aug 6, 2010
Loading...

Share This Page