1 Replies - 674 Views - Last Post: 29 April 2014 - 06:08 AM Rate Topic: -----

#1 plh  Icon User is offline

  • New D.I.C Head

Reputation: 8
  • View blog
  • Posts: 14
  • Joined: 23-May 11

Architecture of REST client - can't enforce static fields

Posted 29 April 2014 - 02:31 AM

I'm developing a REST client and have an issue with the architecture of the application
This is the current code:

public abstract class Resource
       public abstract string ResourceName { get; }
        private static IResourceProvider resourceProvider = Services.ResourceProviderService.ResourceProvider;

        protected static T GetResource<T>(string resourceName, uint id)
            Contract.Requires(resourceName != null, "resourceName must not be null");
            Contract.Requires(resourceName != "", "resourceName must not be empty");

            return resourceProvider.GetResource<T>(resourceName, id);           

public interface IResource
       uint Id { get; }
       string ResourceName { get;}       

public class Language : Resource, Interfaces.IResource
       private const string resourceName = "languages";
       public override string ResourceName
           get { return resourceName; }
       public uint Id { get; set; }
       public string Name { get; set; }

       public static Language Get(uint id)
          return Resource.GetResource<Language>(resourceName, id);

I would like to enforce derived classes of Resource or implementations of IResource to have a static or constant field for the resource name.

I can't seem to find a solution for this, so if you have another way of implementing this I would love to hear it.


Is This A Good Question/Topic? 0
  • +

Replies To: Architecture of REST client - can't enforce static fields

#2 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 6108
  • View blog
  • Posts: 21,024
  • Joined: 05-May 12

Re: Architecture of REST client - can't enforce static fields

Posted 29 April 2014 - 06:08 AM

For the interface, you are stuck with the getter. Unfortunately, you have no way of enforcing that what is returned to you won't be different the next time you call the getter. In your shoes, what I would do put in an inline XML documentation comment noting that the value that is return should not change. Additionally, I would only ever call the getter once and let implementers discover for themselves that you meant it when you wanted the value to be constant. (If I were feeling particularly ornery, in the debug builds I would put in random calls to the getter and Assert that the value did not change.)

As for the class inheritance, you can declare a public abstract getter, but you are again in the same situation as the interface.

Right now, I'm thinking very narrowly, though. Perhaps somebody can apply some kind of Singleton like pattern, but it is for the actual property value instead of a class.
Was This Post Helpful? 2
  • +
  • -

Page 1 of 1