CODEWITHSUNDEEP
c#readonly
Corey Ogburn
Corey Ogburn

Reputation: 24727

Making "Read Only" objects to be returned from API wrapper?

I'm writing a wrapper for a REST API (which is a static class with static methods) at work and it should return a class or a struct holding all the parsed Json returned from the API request. I'm parsing the Json using System.Web.Script.Serialization like so:

JavaScriptSerializer jss = new JavaScriptSerializer();
QueryResult re = jss.Deserialize<QueryResult>(json);

I then want to set two additional parameters on the QueryResult: the original Request Url used and the exact Json returned by the API. The one contradiction is that I want the entire object to be read only once it's returned from the API wrapper. My first thought is to only let the variables be set through a constructor, but parsing Json the way that I am never lets me use a constructor. I thought about having two objects that are very similar, i.e. a private class that can't be seen outside of the wrapper that is used for parsing and then a public class who uses a constructor to set the read only parameters once, but that's very redundant and I'd rather do it just about any other way.

Are their any design patterns or tips to let me do this? I want it to be a syntactical error for them to try and assign to one of the properties, not just an ignored assignment.

Upvotes: 2

Views: 646

Answers (5)

Dan Tao
Dan Tao

Reputation: 128327

Update:

What I'm looking for is a way to be able to edit an object and then lock it down so that every field is read only after a particular line of code.

This sounds like an appropriate use case for the builder pattern. You have a mutable object that you can use just to set up the state of whatever you want to build; then this type is responsible for constructing an instance of an immutable ("locked down") type which is actually usable.

For example:

public class QueryResultBuilder
{
    private string _requestUrl;
    // plus other fields

    public QueryResultBuilder SetRequestUrl(string requestUrl)
    {
        _requestUrl = requestUrl;
        return this;
    }

    // plus other methods

    public QueryResult Build()
    {
        // This could be an internal constructor,
        // only used by this builder type.
        return new QueryResult(_requestUrl /* plus other parameters *);
    }
}

Then your calling code might look like this:

JavaScriptSerializer jss = new JavaScriptSerializer();
QueryResult re = jss.Deserialize<QueryResultBuilder>(json)
                    .SetRequestUrl("url")
                    .Build();

I honestly have no idea if this is an appropriate answer for your scenario, but one common solution to the "read-only object that can be 'updated'" problem is to have an immutable type that returns copies with modifications (much like DateTime.Add, for example).

So you could have an operation like...

class QueryResult
{
    // ...lots of other stuff...

    public QueryResult SetRequestUrl(string requestUrl)
    {
        QueryResult clone = this.Clone();

        // This property could have a private setter.
        clone.RequestUrl = requestUrl;

        return clone;
    }
}

Then calling code would need to do something like:

JavaScriptSerializer jss = new JavaScriptSerializer();
QueryResult re = jss.Deserialize<QueryResult>(json).SetRequestUrl("url");

Upvotes: 2

user47589
user47589

Reputation:

Can you make QueryResult implement an interface IQueryResult?

JavaScriptSerializer jss = new JavaScriptSerializer();
IQueryResult re = jss.Deserialize<QueryResult>(json);

Make the interface specify only property gets, not sets.

public interface IQueryResult
{
    int Foo { get; }
}

internal class QueryResult : IQueryResult
{
    public Foo { get; set; }
}

Sure, it's not absolutely guaranteed read-only. But it does avoid a duplicate class. If you can, make QueryResult an internal class so they can't cast to it, like I did above. That way you can manipulate it, but they can't.

Upvotes: 0

MattDavey
MattDavey

Reputation: 9017

you could add a mechanism to lockdown the object after it has been serialized...

class QueryResult
{
    private bool _locked;

    // Called after deserialization to lock the object...
    internal void LockDown()
    {
        this._locked = true;
    }

    public String Foo
    {
        get { return this._foo; }
        set 
        {
            if (this._locked)
                throw new InvalidOperationException();

            this._foo = value;
        }
    }
}

Upvotes: 0

dlev
dlev

Reputation: 48596

You've unfortunately discovered why serialization has often been considered orthogonal to proper OO design: it breaks encapsulation for the sake of convenience.

I think a wrapper object with get{} only properties is your best bet. Yeah, it's redundant, but it works, and it's pretty simple.

Also, you might want to consider why you need this functionality at all. What consumers of your service do with the data shouldn't be of much concern to you. Is there a particular reason you had in mind?

Upvotes: 1

Tom Hamming
Tom Hamming

Reputation: 10971

I don't see a good way of making it a compile-time error for someone to set a property while still allowing the serializer to work, but you could throw an exception if a property is set that already has a value:

class QueryResult
{
  public string Foo
  {
    get
    {
      return _foo; //private backing ivar
    }
    set
    {
      if (_foo == null)
        _foo = value;
      else
        throw new InvalidOperationException("Cannot set a property that already has a value.");
    }
  }
}

Just make sure all your types are nullable or have default values that will never be set (i.e. are outside the realistic set of possible property values).

Upvotes: 0

Related Questions