Is the "exposer (hack) pattern" a newly identified pattern or does it have another name?

Question

EDITED FOR CLARIFICATION

In 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;
        }

Answer 1

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.

Answer 2

I wouldn't want it known as a pattern because it really is not a pattern to recommend in general.

From you comment to Tom Squires' answer I understand that it is to expose stuff in classes of which you are not the author. And you need some way to get at stuff not exposed by the authors of those classes.

I use TProtectedSomeClass = class(TSomeClass) (Delphi) to get access to protected members of a class in libraries I don't control (even if I have the source). It is known as the "protected hack".

What you are doing feels like hacking as well and I think that if you name the pattern it would be good to have "hack" in the name of it. "Hacker" sounds nice and short. :-)

Answer 3

I don't know of an applicable anti pattern. I would just says its an arse backward way of coding. If you're writing code like that, you're either using the wrong classes or don't understand the correct implementation of those classes.

Edit from your comments (I didn't get that from the question) it seems you're coding like this to get around the limitations of a 3rd party API. The most appropriate term is a "hack". Hacks should be avoided where possible but clearly documented when they can't be avoided.