Results 1 to 3 of 3

Thread: Using 'best' design for my problem

  1. #1
    Join Date
    Oct 2011
    Posts
    51
    Thanks
    5
    Thanked 2 Times in 2 Posts
    Qt products
    Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Using 'best' design for my problem

    Hi!

    I'm writing a client server application that uses protobuf as data interchange format. Now, when my server gets an protobuf message, he choose what action it can take (depending on message type, the messages has tree structure, and basically the 'ending' leafs are actions that server can take) and then it passes this message directly to methods that handles them. Everything is working great (and in fact it is really handy to have a has_foo methods), but... I think this breaks separation of concerns design principle, and whenever I will want to change the communication protocol (e.g. to unix socket where serialization is not needed) I will have to rewrite... almost whole application.
    Normally I would create an interface and an adaptor library to separate protbuf generated code (and maybe some other protocols) from the server implementation itself. Something like.

    Qt Code:
    1. class IMessage {
    2. virtual bool has_foo() const;
    3. virtual int foo() const;
    4. virtual void set_foo(int);
    5. // my messages contains soemtimes 20 fields
    6. }
    7.  
    8. class PbAdapter : public IMessage {
    9. // implementation
    10. }
    To copy to clipboard, switch view to plain text mode 

    But this is a lot of code which needs to be written, and I thought that using so big interfaces for "stupid" data structure is an overkill. Second idea was to create a structure with optional fields and then copy (or move) from it and to it.

    Qt Code:
    1. struct Message{
    2. boost::optional<int> foo;
    3. }
    4.  
    5. Message adapter(pb::Message pb){
    6. Message m;
    7. m.foo = pb.foo();
    8. }
    To copy to clipboard, switch view to plain text mode 

    using this approach, I'll have an possibility for check if field exists ( optional::is_initialized() ) and a simple way of handling those messages. But I need to copy data from my struct to protobuf when creating a protobuf message (this is done 'automatically' when I use protobuf directly) so it's not a ideal approach either.

    So the question is: Should I use an interface, or a simple structure and don't bother copying of the messages, or use the second approach with some "std::move" magic and move. Or maybe something else
    And i know that premature optimizations are the root of all evil but when there is a chance to not copy an object, why not use it?

    Question almost the same a: http://programmers.stackexchange.com...esign-patterns

  2. #2
    Join Date
    Oct 2009
    Posts
    483
    Thanked 97 Times in 94 Posts
    Qt products
    Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: Using 'best' design for my problem

    Both approaches require you to write a similar amount of boilerplate code (an adapter interface in approach #1, a copy to another format in approach #2). If I were you I would avoid the copies and go with approach #1.

    Google distributes a libprotoc library that parses .proto files. You could use it to parse your .proto files and generate the adapter.

  3. #3
    Join Date
    Oct 2011
    Posts
    51
    Thanks
    5
    Thanked 2 Times in 2 Posts
    Qt products
    Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: Using 'best' design for my problem

    ok thanks, and what do you think about using delegates for data access?

Similar Threads

  1. gui design problem
    By nkint in forum Newbie
    Replies: 0
    Last Post: 23rd April 2013, 12:10
  2. Problem with design interface
    By tux-world in forum Newbie
    Replies: 5
    Last Post: 10th March 2010, 14:19
  3. Opengl/Qt Design Problem!
    By IcePic in forum Qt Programming
    Replies: 0
    Last Post: 3rd March 2009, 07:18
  4. Replies: 3
    Last Post: 5th October 2008, 23:41
  5. Design problem/question
    By Valheru in forum Qt Programming
    Replies: 2
    Last Post: 27th September 2006, 21:45

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Qt is a trademark of The Qt Company.