SitePoint Sponsor

User Tag List

Results 1 to 3 of 3
  1. #1
    SitePoint Zealot
    Join Date
    Feb 2008
    Posts
    109
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Any patterns to help with this problem?

    Hi all,

    I hope this question isn't too general, but before I start all the coding I thought it wise to get get some advice on the best way to model the following.

    Concept:
    Take a string --> identify a merchant data source --> identify a product reference --> use reference to get product data --> feedback product data to user

    Make sense?

    The method of identifying parent data source (merchant) will always be the same, however identifying product reference is dependant on which merchant is selected i.e. the format the reference included in the input string will change depending on merchant.

    In addition to this, data source for product data will not be consistant i.e. sometimes it will be from a web service, sometimes from a database, sometimes from a flat file. The end product object will always be standard, so data will be 'morphed' to shape.

    My initial thoughts are to use a factory to create a specific merchant object by parsing the string. Specific Merchant objects would then know how to identify the product reference within the remainder of the input string, and further would know how to go about generating a product object.

    I feel I ought to abstract responsibility for gathering product data and generating a completed product object away from the merchant object. Even though the format of a product reference (found in the input string) is unique to each merchant I'm not persuaded that the merchant object is the right place for parsing logic relating to this.

    Can anyone provide any insight here? Ultimately I'll have over 100 merchants, leading to 100 different parsing and data gathering mechanisms, so I don't want to mess this up from the start.

    Cheers,

    Steve

  2. #2
    SitePoint Zealot
    Join Date
    May 2008
    Location
    Montreal
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, we could certainly find a way to make use of every GoF pattern in this problem; however, that will not make your code any more clear, nor will it get you closer to your problem domain. The right question is almost never: how can I box this problem into some patterns. If a problem fits a pattern then by all means use a pattern, but be weary of fitting problems to patterns.

    That being said, a few things stand out.

    I would say start off by defining an interface (literal and figurative) for how you will interact with a datasource. Have a few classes implement that interface for web services, databases, etc. The obvious goal is to abstract away the peculiarities of each datasource such that the same data stored in a flat file, web service, or database will always be represented in the same way after being found through one of your data sources. Your data source should not be concerned with parsing the connection string, only knowing how to interpret data from a source.

    You will generally want your string parsing to be separate from your datasources. This presents a bit of a problem because some of your datasources might end up being highly specific while others might be general and reusable. On the other hand, it seems that the connection part of a data source is fairly simple and easy to abstract away. The connection might be a file pointer, database handle, cURL instance, etc. So, it might be prudent to box this type of functionality up so that you can easily create these various connections. The main thing you want to think about is that your data sources should have a consistent interface, even with their constructors. If we can pass them any sort of connection then you can let them work with it and not care where the data is coming from.

    In terms of parsing the strings, here is where things could get tricky. How easy is it to figure out that you will be using one merchant over another? How do you want to store the patterns to recognize the various merchants? If you are storing everything is a big array mapping pattern => handler then that would be fairly simple; however, it would mean that in the worst case you would have to try to match every pattern to get to the right one.

    It seems that your string parser has two responsibilities: identify merchant/data source, identify product reference. Depending on the complexity of what is stored for merchant info it might not be necessary to abstract a connection out of the data sources but instead move it into the data sources as abstract classes implementing your interface, then have the custom datasource classes extend these abstract classes. One bit of warning if you choose this class structure is that as you push your implementation classes deeper into a class heirarchy, it will be more difficult to take advantage of similarities between classes. That is why I would still opt for handling the connection part of things elsewhere, such that your datasources only interpret and reformat data.

    The string parser is thus a tool to be called upon. Its results will be used to create a connection and figure out what merchant data source to use. The merchant data sources use a connection to return standardized data. Using the product reference, you can query the data source for some standard representation of data, and output it as you wish to the user.

  3. #3
    SitePoint Zealot
    Join Date
    Feb 2008
    Posts
    109
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Peter Goodman View Post
    If a problem fits a pattern then by all means use a pattern, but be weary of fitting problems to patterns.
    Fair point - the post wasnt very well titled, but I realise I'm talking more about setting up a decent model rather than specific patterns.

    Just to recap your comments and to add a few further details then. I'm helping a friend out with this so thought I'd best check before spilling the whole idea!

    The strings being parsed are URLs - online store URLs, so the idea is to work out the merchant from the domain then look up some information on the product ID referenced in the URL.

    Parsing for the merchant should be pretty easy - I was planning on keeping a database table and looking it up there. I guess this would be a merchant 'datastore' to adopt the language we've been using here. The only other property of a merchant will be locale to help with internationalisation.

    Would I be right in interpretting your suggested approach as being close to a mapper? Where each merchant has some kind of "Product Datastore Mapper" associated that is capable of querying the datasource (via passed in connection) for the requested product ID, and returning a generic product object as a result.

    I can see the advantage of seperating out the parsing of the product id, enabling mapper (datastore accessor) reuse. Presumably I'd need a 'parser' class (that follows an abstract interface) for each merchant? I figured I'd need to do this at some point, the whole encapsulating the concept that varies thing, I just wasnt sure where best to do it.

    Seperating the "parser / finding object" from the datastore mapper means that if possible I can reuse the mappers, but if I can't I guess I double up on classes - a parser and a mapper/datastore for each merchant?

    Interesting stuff this, glad I offered to help out with this project, should help out with my OO learning curve!

    Cheers,

    Steve


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
  •