none
Design Review - Need Input RRS feed

  • Question

  • I'm basically just posting tonight to get some feedback from some of you more experienced architects out there.  I'm just starting to get into more use of Interfaces...already seasoned and know Abstract Classes which I've used in some pretty slick designs of my own.

    Anyway, I created a hack UML here: uml.pdf

    A few things about the diagram first:

    >> Everything is a property that does not have () which of course is a method

    >> Everything is public unless specified private

    >> The fields or methods in blue are highlighting the additional class specific fields in addition to the interface members

    >> I named the MainPhotoUpload a factory because that's how I see this right now working...at least in my mind it's a factory because it's grabbing a certain service instance based on the APIType

    >> The two grey classes is just showing you that there's going to be other Wrappers I create later for other APIs such as Flickr and Picasa which will work in this same way...implementing these core Interfaces and using this pattern I'm showing with the Facebook example here

    >> The properties you see in a service such as for example the FacebookPhotoService ... its FacebookAlbumPhoto property represents an instance of the FacebookAlbumPhoto so I can start working with it.  In other words it does the instantiation for me and exposes it as a property in the FacebookPhotoService....so I can use the FacebookPhotoService . FacebookAlbumPhoto property to get an instance of a FacebookAlbumPhoto and start calling methods or other members of FacebookAlbumPhoto.  So the service is like just a bridge to allow you to utilize the underlying core wrapper classes and start using them.

    Ultimately the goal is:

    1) Create as much reuse as possible for all the API wrappers we create going forward (Facebook, Flickr, etc.) pertaining to Photo specific functionality which is the scope of this model

    2) Enforce a pattern across any API we implement so that they'll all be somewhat consistent at least on the core members that you're going to see in any Photo API out there.  e.g. IPhoto, and the rest of the interfaces denote common properties and methods that you'll see in any Photo API like these

    3) A way to ultimately call the wrapper methods as well as to obtain the current session for that APIn or to get other Facebook objects by calling methods on those objects (e.g. FacebookAlbumPhoto, etc.).  So for example with Facebook, I want to be able to call the facebook methods for a certain class or access properties of a certain class indirectly by using a service.  The Main service acts as a Factory that goes out and gets the right service.  Then you use that service to ultimately start calling methods and utilizing the underlying wrapper classes (such as FacebookAlbumPhoto, etc.)

    So this is what I've come up with.  You'll see on page 2, some examples of how I envision these will be used in code later on for our business logic.

    This is not done of course. 

    I want to know:

    1) Is my approach at least seeming somewhat logical, respectable, usable and makes some sort of sense here?  to me it is but I want to see what some other architects think out there.  I mean I'm not looking for perfection here...just something that's fairly flexible and for now works and allows me to get at various services and that the way I'm using these services makes sense (i.e. having properties in those services that expose instances of sub classes)

    2) Any advice on improving or changing this without getting overly crazy (I don't need to know about 5 design patterns in how I can improve this...just give me some basic advice on interfaces, service classes like mine, or factory etc. that pertain to the scope of this)

    3) Anything I'm just doing totally wrong that is just clearly "Never do that".  For instance my fellow architect friend says I'm creating interfaces here but not really providing any value.  However for me it's providing some value to enforce some consistency/pattern and ultimately reuse for base commonalities between any Photo API wrappers we create later as well as I am actually using those Interface types in other classes later on such as the MainPhotoService.APIService property which I have as type IAPIService because I don't know which service I'll return until I check the incoming APIType enum in that constructor of the MainPhotoService.

    4) Is that really a "factory" pattern?  Is my approach logical and clean and extensible?

    if anything is not clear please ask. 

    UPDATED PDF at 10:44pm US Central (so see below)

    Note: if you've already downloaded that .pdf, please download it again as I fixed a couple things.  It's good to go now.

     

    UPDATED

    I got rid of a few things and renamed some to make more sense.  So now you can see the progression from the first design to this one:  uml2.pdf

     

    UPDATED

    uml3.pdf


    C# Web Developer
    • Moved by Harry Zhu Thursday, August 5, 2010 6:49 AM (From:Visual C# General)
    • Edited by NoEgo Thursday, August 5, 2010 6:01 PM
    Thursday, August 5, 2010 3:24 AM

All replies

  • On 8/4/2010 11:24 PM, NoEgo wrote:
    > *I want to know:*
    >
    > *1) *Is my approach at least seeming somewhat logical here? to me it is
    >
    > *2) *Any advice on improving or changing this without getting overly
    > crazy (I don't need to see 3 design patterns in how I can improve
    > this...just give me some basic advice or a different way to look at a
    > certain part of this in how I may want to approach this or that
    > differently, and so on)
     
    Head First Design patterns -- in Java (not hard to understand), as OOP
    is OOP in Java or .NET.
     
    http://oreilly.com/catalog/9780596007126
    http://www.dofactory.com/Patterns/Patterns.aspx
    http://www.dofactory.com/Framework/Framework.aspx
     
     
    >
    > *3) *Anything I'm just doing totally wrong. For instance my fellow
    > architect friend says I'm creating interfaces here but not really
    > providing any value. However for me it's providing some value to enforce
    > some consistency/pattern and ultimately reuse for base commonalities
    > between any Photo API wrappers we create later as well as I am actually
    > using those Interface types in other classes later on such as the
    > MainPhotoService.APIService property which I have as type IAPIService
    > because I don't know which service I'll return until I check the
    > incoming APIType enum in that constructor of the MainPhotoService.
     
    Using Interfaces has value when doing Unit Testing using a Test Driven
    Design approach. One does a Unit Test against Interfaces for behavior
    and mocking out objects. Interfaces also have value if using a wrapper
    or service wrapper. Interfaces along with using dependency injection
    with an MVP (Model View Presenter) as an example leads to code
    consistency, Unit Testing and OOP.
     
    http://msdn.microsoft.com/en-us/magazine/cc163904.aspx
     
    Using Unit Testing tools like Rhino Mocks, MBunit, Gallio and Reshaper
    give great value in overall application and code design in the various
    layers, like UI/MVPorMVC, BLL and DAL when Interfaces are used in the
    layers.
     
     
     
     
    Thursday, August 5, 2010 6:02 AM
  • *I want to know:*

    *1) *Is my approach at least seeming somewhat logical here? to me it is

    *2) *Any advice on improving or changing this without getting overly
    crazy (I don't need to see 3 design patterns in how I can improve
    this...just give me some basic advice or a different way to look at a
    certain part of this in how I may want to approach this or that
    differently, and so on)
     
    my response-------------------------------------------------------------------------------------------------------

    Head First Design patterns -- in Java (not hard to understand), as OOP is OOP in Java or .NET.

    http://oreilly.com/catalog/9780596007126
    http://www.dofactory.com/Patterns/Patterns.aspx
    http://www.dofactory.com/Framework/Framework.aspx

    --------------------------------------------------------------------------------------------------

    *3) *Anything I'm just doing totally wrong. For instance my fellow
    architect friend says I'm creating interfaces here but not really
    providing any value. However for me it's providing some value to enforce
    some consistency/pattern and ultimately reuse for base commonalities
    between any Photo API wrappers we create later as well as I am actually
    using those Interface types in other classes later on such as the
    MainPhotoService.APIService property which I have as type IAPIService
    because I don't know which service I'll return until I check the
    incoming APIType enum in that constructor of the MainPhotoService.
     
    my response-------------------------------------------------------------------------------------------------------------------

    Using Interfaces has value when doing Unit Testing using a Test Driven Design approach. One does a Unit Test against Interfaces for behavior and mocking out objects. Interfaces also have value if using a wrapper or service wrapper. Interfaces along with using dependency injection with an MVP (Model View Presenter) as an example leads to code consistency, Unit Testing and OOP.

    http://msdn.microsoft.com/en-us/magazine/cc163904.aspx

    Using Unit Testing tools like Rhino Mocks, MBunit, Gallio and Reshaper give great value in overall application and code design in the various layers, like UI/MVPorMVC, BLL and DAL when Interfaces are used in the layers.


    Thursday, August 5, 2010 8:51 AM
  • Yea, I'm reading that book now.

    C# Web Developer
    Thursday, August 5, 2010 2:24 PM
  • I am looking for specific responses to my uml, not just general "use interfaces for unit testing, yada yada...already know that general concensus".  I want to know if my design looks at least somewhat respectable and if the way I'm grabbing those services as well as the way I'm grabbing an instance of the underlying Facebook classes in order to start using them looks half way decent/respectable.

    If you were to use this code, would you a) like the pattern or b) have some issues with the way I'm retrieving or using a service or the way I'm getting instances of those underlying classes, or the way I'm using (my intent in using) Interfaces here.

    I'm already reading the Head First book.  I'm asking for a code review of my design and just a quick skim of some of my example code that illustrates how to use my service.


    C# Web Developer
    Thursday, August 5, 2010 2:27 PM
  •  
    *I want to know:*

    *1) *Is my approach at least seeming somewhat logical here? to me it is

    *2) *Any advice on improving or changing this without getting overly
    crazy (I don't need to see 3 design patterns in how I can improve
    this...just give me some basic advice or a different way to look at a
    certain part of this in how I may want to approach this or that
    differently, and so on)
     
    my response-------------------------------------------------------------------------------------------------------

    Head First Design patterns -- in Java (not hard to understand), as OOP is OOP in Java or .NET.

    <http://oreilly.com/catalog/9780596007126>
    <http://www.dofactory.com/Patterns/Patterns.aspx>
    <http://www.dofactory.com/Framework/Framework.aspx>

    --------------------------------------------------------------------------------------------------

    *3) *Anything I'm just doing totally wrong. For instance my fellow
    architect friend says I'm creating interfaces here but not really
    providing any value. However for me it's providing some value to enforce
    some consistency/pattern and ultimately reuse for base commonalities
    between any Photo API wrappers we create later as well as I am actually
    using those Interface types in other classes later on such as the
    MainPhotoService.APIService property which I have as type IAPIService
    because I don't know which service I'll return until I check the
    incoming APIType enum in that constructor of the MainPhotoService.
     
    my response-------------------------------------------------------------------------------------------------------------------

    Using Interfaces has value when doing Unit Testing using a Test Driven Design approach. One does a Unit Test against Interfaces for behavior and mocking out objects. Interfaces also have value if using a wrapper or service wrapper. Interfaces along with using dependency injection with an MVP (Model View Presenter) as an example leads to code consistency, Unit Testing and OOP.

    <http://msdn.microsoft.com/en-us/magazine/cc163904.aspx>

    Using Unit Testing tools like Rhino Mocks, MBunit, Gallio and Reshaper give great value in overall application and code design in the various layers, like UI/MVPorMVC, BLL and DAL when Interfaces are used in the layers.

    Thursday, August 5, 2010 2:46 PM
  • On 8/4/2010 11:24 PM, NoEgo wrote:
    *I want to know:*

    *1) *Is my approach at least seeming somewhat logical here? to me it is

    *2) *Any advice on improving or changing this without getting overly
    crazy (I don't need to see 3 design patterns in how I can improve
    this...just give me some basic advice or a different way to look at a
    certain part of this in how I may want to approach this or that
    differently, and so on)

    Head First Design patterns -- in Java (not hard to understand), as OOP is OOP in Java or .NET.

    http://oreilly.com/catalog/9780596007126
    http://www.dofactory.com/Patterns/Patterns.aspx
    http://www.dofactory.com/Framework/Framework.aspx



    *3) *Anything I'm just doing totally wrong. For instance my fellow
    architect friend says I'm creating interfaces here but not really
    providing any value. However for me it's providing some value to enforce
    some consistency/pattern and ultimately reuse for base commonalities
    between any Photo API wrappers we create later as well as I am actually
    using those Interface types in other classes later on such as the
    MainPhotoService.APIService property which I have as type IAPIService
    because I don't know which service I'll return until I check the
    incoming APIType enum in that constructor of the MainPhotoService.

    Using Interfaces has value when doing Unit Testing using a Test Driven Design approach. One does a Unit Test against Interfaces for behavior and mocking out objects. Interfaces also have value if using a wrapper or service wrapper. Interfaces along with using dependency injection with (Model View Presenter) as an example leads to code consistency, Unit Testing and OOP.

    http://msdn.microsoft.com/en-us/magazine/cc163904.aspx
    http://en.wikipedia.org/wiki/Domain-driven_design

    http://en.wikipedia.org/wiki/Test-driven_development


    Using Unit Testing tools like Rhino Mocks, MBunit, Gallio and Reshaper give great value in overall application and code design in the various layers, like UI/MVPorMVC, BLL and DAL when Interfaces are used in the layers.


    Thursday, August 5, 2010 3:13 PM
  •  
    Head First Design patterns -- in Java (not hard to understand), as OOP is OOP in Java or .NET.

    http://oreilly.com/catalog/9780596007126
    http://www.dofactory.com/Patterns/Patterns.aspx
    http://www.dofactory.com/Framework/Framework.aspx


    Using Interfaces has value when doing Unit Testing using a Test Driven Design approach. One does a Unit Test against Interfaces for behavior and mocking out objects. Interfaces also have value if using a wrapper or service wrapper. Interfaces along with using dependency injection with (Model View Presenter) as an example leads to code consistency, Unit Testing and OOP.

    http://msdn.microsoft.com/en-us/magazine/cc163904.aspx
    http://en.wikipedia.org/wiki/Domain-driven_design

    http://en.wikipedia.org/wiki/Test-driven_development


    Using Unit Testing tools like Rhino Mocks, MBunit, Gallio and Reshaper give great value in overall application and code design in the various layers, like UI/MVPorMVC, BLL and DAL when Interfaces are used in the layers.

    Thursday, August 5, 2010 3:18 PM
  •  
     
    *I want to know:*

    *1) *Is my approach at least seeming somewhat logical here? to me it is

    *2) *Any advice on improving or changing this without getting overly
    crazy (I don't need to see 3 design patterns in how I can improve
    this...just give me some basic advice or a different way to look at a
    certain part of this in how I may want to approach this or that
    differently, and so on)
     
    my response-------------------------------------------------------------------------------------------------------

    Head First Design patterns -- in Java (not hard to understand), as OOP is OOP in Java or .NET.

    http://oreilly.com/catalog/9780596007126
    http://www.dofactory.com/Patterns/Patterns.aspx
    http://www.dofactory.com/Framework/Framework.aspx

    --------------------------------------------------------------------------------------------------

    *3) *Anything I'm just doing totally wrong. For instance my fellow
    architect friend says I'm creating interfaces here but not really
    providing any value. However for me it's providing some value to enforce
    some consistency/pattern and ultimately reuse for base commonalities
    between any Photo API wrappers we create later as well as I am actually
    using those Interface types in other classes later on such as the
    MainPhotoService.APIService property which I have as type IAPIService
    because I don't know which service I'll return until I check the
    incoming APIType enum in that constructor of the MainPhotoService.
     
    my response-------------------------------------------------------------------------------------------------------------------

    Using Interfaces has value when doing Unit Testing using a Test Driven Design approach. One does a Unit Test against Interfaces for behavior and mocking out objects. Interfaces also have value if using a wrapper or service wrapper. Interfaces along with using dependency injection with an MVP (Model View Presenter) as an example leads to code consistency, Unit Testing and OOP.

    http://msdn.microsoft.com/en-us/magazine/cc163904.aspx

    Using Unit Testing tools like Rhino Mocks, MBunit, Gallio and Reshaper give great value in overall application and code design in the various layers, like UI, MVP or  MVC, BLL and DAL when Interfaces are used in the layers.


    Thursday, August 5, 2010 3:21 PM
  • "not hard to understand" is relative to each individual.   I don't know if you mean that book is not hard to understand (because Head First books are great teaching tools) or that any developer shouldn't find it hard to understand...that is Design Patterns in general.

    Not all design patterns or the concepts of "why" or "where" you'd use them is not always easy to understand or clear unless you have a use for them...and it takes a lot of practice and experience using them to master them.


    C# Web Developer
    Thursday, August 5, 2010 3:48 PM
  • So...you guys repasted what you posted. I did not find any of that generalized info any use to me as I've stated I wanted feedback on my UML.
    C# Web Developer
    Thursday, August 5, 2010 3:50 PM
  •  
    Interfaces have value in Domain Driven Design, Test Driven Design and Object Oriented Programming. And if you're not trying to implement Interfaces in layers or n-tiers and using the concepts, then I think it leads to poor coding and design.  
    Thursday, August 5, 2010 4:03 PM
  • darnold, so do you have an example?  And so you're saying since my Interfaces are at the lowest level (it's the lowest layer itself) then it's really not good design even though it promotes consistency and I'm even using some Interface values as variables in instance classes above it?

    C# Web Developer
    Thursday, August 5, 2010 5:05 PM
  • Hi NoEgo... had a look ot the PDF and here is what I think... all be it this is only my opinon based on the information provided.

    The PhotoServices classes look as though they all have more than a CurrentSession in common. If you rename FacebookAlbumPhoto and FickerAlbumPhoto to just AlbumPhoto then that can be part of the interface. There is no need to call these things Facebook and Flicker because the class name has that information

    IAPIService

         CurrentSession

         AlbumPhoto

         ProfilePhoto

     

    FaceBookPhotoService : IAPIService

     

    Not convinced about the AlbumPhoto and ProfilePhoto, this just might be my lack of understanding but I imagine you'd just have a Photo and ok a ProfilePhoto but maybe perhaps an Album class instead or the AlbumPhoto, the AlbumPhoto has more responsibility that it needs to.  Not sure you see... difficult to tell what's best there. Would you need an IPhoto interface there... well maybe what you need is a PhotoGetter type class that knows how to get a Photo.  Yes that might be better... then you could have an IPhotoGetter interface (please these names I am using are terrible) that other classes can implement to get a Photos from specific providers Facebook, Flicker... basically a Photo is a Photo regardless of where it came from... or is it... you see I don't know....

    Here is a top tip for you ... too much up front design is not worthless but not as valuable as it should be. All it takes is a change and the design and code needs to change also, big designs up front are not flexible when it comes to change. What you should do is have a look at test driven development.... or test driven design. Takes practise but the design of the system kind of continually grows to meet the requirements. It results in code that is testable and flexible to change. It's a brilliant way to design software. The guys above posted links that will help.

    If your wanting smaller steps, and you don't know about it, then look into unit testing as a starting place. Pragmatic Unit Testing in C# with NUnit is a book that will get you started.If you don't do test driven design then you want to have unit tests in there so the design can change in such a way that you know if you break anything... the design you have will change so rather than getting it right first time put in place unit tests that help support changes to the design.

     

    I think you did alright you know, not 100% but you know it's a good go and who knows it's probably better than I can tell because you may have information I don't which justified some design decisions. In terms of a starting point it's ideal... because in your mind you have some where to start... you've thought about it and that's more that others. Can't fault that... no way.

    Might not have answered all your questions there; it's late and your question was rather long; post again and let me know if there is areas you want more on.

     


    …we each have more potential than we might ever presume to guess.
    Thursday, August 5, 2010 5:07 PM
  • "Not convinced about the AlbumPhoto and ProfilePhoto, this just might be my lack of understanding but I imagine you'd just have a Photo and ok a ProfilePhoto but maybe perhaps an Album class instead or the AlbumPhoto"

    correct, this was just to illustrate a small set of classes.  I'd have other classes such as FacebookAlbum, FacebookProfile and a bunch of more entities.  There are basically several kinds of photos meaning different areas of their site.  I may not need to split that in the end but for now, I just went with it and will change that if needed....just shows stubs basically.

    "Would you need an IPhoto interface there"

    I just wanted to put commonality in an interface and then when I start to create this same kind of Wrapper for other Photo API libraries, I'll have a common set of members in each so that it's consistent.  So basically the only reason I'm using Interfaces here is to require a pattern and to reuse a pattern and have consistent base members across different implementations.

    I'm not trying to use Interfaces just for the sake of using them.  I want to utilize them more and trying to understand when and how they can be applied best in whatever project I may be working on.  So for instance for this project, I needed to put together some common things that all APIs will have and that's how I did it, started from an Interface because each implementation will be different based on the API but I know that for example a photo in Flickr, Picasa, and the rest will have a FileName, etc.

    "FaceBookPhotoService : IAPIService"

    I can't do this because not every API that implements that (if it did as you're explaining) will have the same methods, number of methods, or method names.  For instance Flickr may not have some of the entities that Facebook has.  So I can't just put abstract method stubs inside the IAPIService and then share that across all those services...the implementation and creation of the core entities (profile, album, photo) could be different.  For the most part yes, it's all going to be pretty close to the same but I can't assume this.  Flickr for example has custom entities because they have features Facebook doesn't and vice versa.  But I know they will all certainly need and have a user Session.

    Thanks a lot for your feedback, let me know if you think of anything else.  I also added an updated uml v3 in the thread.


    C# Web Developer
    Thursday, August 5, 2010 6:08 PM
  •  
    Test just to see if I can even reply to this post, which I have tried 3 times unsuccessfully.
    Friday, August 6, 2010 3:18 AM
  • Hey NoEgo... yet reviews like this are very difficult because of one person has more information than the other. Everyone defends their decisions.

    I still think the IApiService can include the AlbumPhoto and ProfilePhoto methods in it; if fact these are probably the PhotoGetters I was going on about in my first reply. Here is the kind of code I would want to write if I were wanting to get a photo from Facebook

     

    IApiService service = new FaceBookService("username", "password")

    Photo photo = service.GetPhoto("photoName")

    photo.Download()

     

    and here is the code I would want to write if I wanted a photo from Flicker

     

    IApiService service = new FlickerService("username", "password")

    Photo photo = service.GetPhoto("photoName")

    photo.Download()

     

     

    Of course yeah man how each Service would download the Photo is different but that difference is abstracted away by the design... the FaceBookService.GetPhoto() will do something completely different from the FlickerService.GetPhoto method but what they both do (they Get a Photo) will be the same. If you can't do something like this then maybe something like this is needed....

     

     

    Dictionary<string, string> context = new Dictionary<string, string>()

    context["user"] = "username"

    context["pass"] = "password"

    context["photo"] = "photoname"

     

    IApiService service = new FacebookService()

    Photo photo = service.GetPhoto(context)

    photo.Download()

     

    --------------------------------------------

     

    Dictionary<string, string> context = new Dictionary<string, string>()

    context["user"] = "username"

    context["pass"] = "password"

    context["photo"] = "photoname"

    context["album"] = "albumname"

     

    IApiService service = new FlickerService()

    Photo photo = service.GetPhoto(context)

    photo.Download()

     

    But I'm not 100% with the above... I'd go with it until something better came along.

     

    The idea of putting interfaces in the code is to enable code like the above, it's to generalise code, to abstract out the differences so it's easier to replace whole subsystems or API services .... looking at the UML you have to do this with IApiService otherwise there isn't much point having the interface there at all. You don't want to be writting code like this...

     

    if (typeof(service) == FacebookPhotoService)

         service.FacebookAlbumPhoto(...)

    else

         service.FlickerAlbumPhoto(...)

     

    Hey man, regardless of that, just start coding up and see what happens.

    As I said before the more effort you put into design the less valuable that effort becomes.

    Just go for it and see what design you end up with, cos it won't be the design you started with.

     


    …we each have more potential than we might ever presume to guess.
    Friday, August 6, 2010 8:54 AM
  • thanks Derek.

    I just don't want a service that has a sh**load of methods in it like it's a hodge podge full of methods for all entities...defeats the entire reason to abstract and create specific classes in the first place. in it.  I mean you don't want a service object that has 100 methods in it.  You want only your service object to be a conduit to your subclasses which abstract out the different subtypes of album or whatever it may be.  And again not every 3rd party API is going to all have the same set of properties and methods...so you need to have FlickrAlbumPhoto and FacebookAlbumPhoto, etc. because they will implement IPhoto...what IS common but then have other custom properties and methods that relate only to that specific subtype behavior (in this case specific photo type).  Flickr may for example have just for example sake a PhotoNickName (yea doesn't make sense but just to illustrate) and Facebook doesn't.  You can't assume IPhoto is going to stand for each and every photo type and API out there.  IPhoto should only hold COMMON members that all APIs definitely have.


    C# Web Developer
    Saturday, August 7, 2010 3:26 AM
  • "if (typeof(service) == FacebookPhotoService)"

    but you wouldn't need to if FacebookPhotoService implements IAPIService.  You can just use polymorphism and switch out any IAPIService with any subclass that's implemented it right?  I guess I'm still not seeing the other points about the iterfaces and their use then.  Even though I'm not really using a lot of interface variables and such, I'm still ensuring a consistent pattern.


    C# Web Developer
    Saturday, August 7, 2010 5:49 PM
  • So here's a few things more.

    1) I have not (yet) done a lot of unit testing but trying to get into it more but my intent is surely motivated to start doing more.  I do have a couple books already including the pragmatic.  However, going to the create tests first then code is a little extreme for me in the sense that I'm just not experience enough yet and unfortunately I'm working for a shithole who would frown on even using Interfaces or drive design by tests first instead of tests after...so going too much into unit testing especially write tests first before code would cause the place I work to ____ their pants rather than pat me on the back.  So right now, I'm just doing what I can to plan this out the best way I know how at this point...again I really want to incorporate interfaces more and I think that enforcing some sort of consistent pattern in common members across APIs is important regardless if I am or not using IWhatever variables and method params, ...meaning I'm not really using the polymorphism benefit of Interfaces.  However I'm trying to find a way not only to drive a good consistent commonality pattern,  For example I know that all classes dealing with photos are ti implement IPhoto therefore I know they all have x base members but each are implemented totally different in the guts of those members...but they will all definitely provide the same type of functionality though.  However they do it I don't care which is the whole point of using Interfaces...just that in my case I'm using it more for enforcing a pattern knowing that I could also benefit from polymorphism later if I ever wanted to use some interface members in concrete classes, etc. because I know that all types of x concrete classes implemented common members from x type of interface.

    2) My UML design isn't aimed to be perfect.  That UML...which I call it is a decent stab at a model which I believe is going to work...It's pretty bare at this point but makes somewhat some sense and I did spend a few hours thinking this through.  I took a look at what I thought would be common knowing that my interfaces will have to change....which I hear is the wrong way to design, that you are to design from your interfaces out and not design your interfaces around the implementation of the outside wrapper classes which will be implementing your interfaces.  Well...I don't see how you can do that when you have to take into consideration all photo type APIs to figure out what is common and can be shared between all of those 3rd party APIs.  I mean you have to really design your interfaces around what's common to those as a whole.

    3) Ok for your Dictionary concept that's actually a good idea it seems.   I had a a method in a previous Facebook wrapper I started last year... that I did not finish (we shifted focus to another project) as we do about every freakin week...sigh) but I was kinda doing that "sort of"..using a dictionary to specify the querystring params to form the Uri for whatever type of API request I was making:

    CreateRequestURI(_apiKey, _version, _parameters, _applicationSecret);

    Then my CreateRequestURI called another method of mine:

                private string FormatParameters(Dictionary<string, string> parameters)
                {
                    StringBuilder formattedParams = new StringBuilder();
                    int count = 0;

                    foreach(KeyValuePair<string,string> param in parameters)
                    {
                        count++;
                        formattedParams.Append(param.Key);
                        formattedParams.Append("=");
                        formattedParams.Append(HttpUtility.UrlEncode(param.Value));
                        if(count < parameters.Count)
                            formattedParams.Append("&");
                    }

                    return formattedParams.ToString();
                }

    so that constructed the querystring portion of the URI for me.

    Anyway this time around, I wanted to use the same concept for HttpRequests for performing API method calls.  Same type of deal, I'll pass in the list of querystring values needed for the specific method I want to call:

        public interface IAPIMethodRequest : IAPIRequest
        {

            /// <summary>
            /// Formats the parameters to be sent in the querystring of an API HtpRequst
            ///
            /// This method should be reusable in that you can pass in any list of
            /// name value pairs and the type of API and it will build the querystring
            /// portion of the HttpRequest.  You then append the returned string with the
            /// base URI that is sent.
            /// </summary>
            /// <typeparam name="T"></typeparam>
            /// <param name="list">The list.</param>
            /// <param name="APIType">Type of the API.</param>
            /// <returns></returns>
            string FormatParameters<T>(IEnumerable<T> list, Enum @APIType);

        }

    so with this I am able to send in a list of key/value pairs of values that will be added to the querystring HttpRequest.  I've actually had a concreate method do something like this in one of my wrappers which is actually running in live production but was totally an unrelated type of project use this type of thing but it was passing in an actual dictionary of key/value pairs which I then split and added as querystring values to the HttpRequest.

    But I mean do I really want a bunch of method stubs in my Interface all expecting a dictionary in place of method params?  I don't know if that's really usable in that it doesn't convey intent or explain how the method is really used without having to absolutely look at the underlying code.  I mean sure it's ok to pass in a dictionary sometimes but I mean to have a bunch of these methods in your Interface that passes in a dictionary of method params to make somehow the signature "flexible" to any implementation of it seems kinda misleading to me as someone who would be the user of my service.  So you're kinda saying do this on a larger scale with your context dictionary example...more particular to this new uml I have created in that you're saying to pass in dictionaries on a global level to some method members to make them flexible.  I don't know, is that a common thing to just do across the board like this?  Just wondering.  Anyone else do this who is reading this reply?  Opinions, good/bad?

    4) Last thing I want to talk about is UML.  I also have not done a lot of that if any but my hack way of doing it (don't have time right now to master EA) really helped me think about how I would structure my pattern and this entire service.  Without drawing stuff like this out, I end up creating a pile.  So then if you say you shouldn't try to structure too much up front then I would assume you're not an advocate for UML?

    I hope I am making any sense here when trying to explain my thought process behind the reasons why I did certain things...


    C# Web Developer
    Wednesday, August 11, 2010 2:11 AM