EDITED FOR CLARIFICATIONIn the past, I have seen a whole manner of resolutions and fudges. Some really stand out. One particular resolution that I initially thought of as a fudge possibly deserves a category of its own. It could be considered a hack or a pattern, as a design pattern is just a piece of reusable code. So, it still conforms to the definition: http://en.wikipedia.org/wiki/Software_design_pattern It possibly already has a name but I have not seen it in the literature. I was wondering if anyone knows another name for what I labelled the exposer (hack) pattern. I have included an example of it below. This code is used to expose data that is not available to a data source. Instead, the results are not generated until a data bind method is called. Unfortunately, these results are not stored anywhere in the data source after execution. This is due to an oversight (or bad design) in the third party API. So, the results are passed a repeater to store locally, before returning these out as a populated PageDataCollection:public static PageDataCollection Search(this SearchDataSource searchDataSource){            PageDataCollection results = new PageDataCollection();            //This is a dummy repeater whose only purpose is to provide a way of            //iterating over the search results            Repeater dummy = new Repeater();            dummy.ItemDataBound += delegate(Object sender, RepeaterItemEventArgs e)            {                if (e != null && e.Item != null && e.Item.DataItem != null)                {                    PageData pageData = e.Item.DataItem as PageData;                    if (pageData != null)                    {                        results.Add(pageData);                    }                }            };            dummy.DataSource = searchDataSource;            dummy.DataBind();            return results;        }
Is the exposer (hack) pattern a newly identified pattern or does it have another name?
design patterns
Given your reference to problematic 3rd party API you can't just get rid of, your workaround looks pretty close to Escape Hatch:Context: You are in a paradigm (e.g. language, runtime environment, scribble on back of envelope) and you need to express or  do some thing which does not fit.Problem: You are being restricted by your current tool set.Forces: You may not be able to ditch your current tool for various reasons: technical, legal, political or legacy code...By the way if you've got a lot of issues of that kind, consider arranging an Anticorruption Layer:If your application needs to deal with a database or another application whose model is undesirable or inapplicable to the model you want within your own application, use an AnticorruptionLayer to translate to/from that model and yours.