I'm designing a library built on web scraping that tries to provide an API to a popular news site. I am representing each of its articles as a collection of 'elements' (IElement), such as images, videos, blocks of text, soundtracks, etc. The problem is, I can't think of anything each 'element' has in common.

  • Text? Nope, images (and videos, and soundtracks) don't have text.
  • A URL to access the file? Nope; while I will be visiting a remote URL to access an image or a video (since it's not practical to pass those around), I don't need to go to a URL to get the text (I can just pass it as a string).

The only thing I can think of is having a member that describes what type the element is, but that could potentially lead to a very unintuitive API. I don't want my API to end up looking like this:

// API code
enum ElementType
    Text, Hyperlink, Image, Video, Soundtrack

interface IArticle
    IEnumerable<IElement> Contents { get; }

interface IElement
    ElementType Type { get; }

class TextElement : IElement { /*details*/ }
class ImageElement : IElement { /*details*/ }

// .. and so on

// Usage in app code
foreach (var element in article.Contents)
    switch (element.Type)
        case ElementType.Text:
        case ElementType.Image:
        // and so on

As you can see, a lot of verbosity is added in this scenario because the user has to 1) switch on the element's type, 2) check for each ElementType, and then 3) downcast it to use implementation-specific features.

Is there an alternative to messy runtime type checking / downcasting in this scenario? How do other client apps (i.e. Facebook / Twitter clients) handle this kind of problem?

  • In what language? Dynamic languages, or languages with variants don't really face this problem.
    – Telastyn
    Jun 21, 2015 at 21:45
  • @Telastyn I'm writing the library in C# / .NET.
    – James Ko
    Jun 21, 2015 at 21:50

2 Answers 2


Part of your problem is that you are trying to reinvent the HTML document object model. Unless the content needs some special processing, it would be better to supply HTML fragments.

The type switch can be eliminated by using the visitor pattern: we define a visitor interface IElementVisitor that lists all cases, and add a void Accept(IElementVisitor) method to the IElement interface that will be implemented in each concrete type as

void Accept(IElementVisitor v) {

Then, a RenderVisitor would look like

class RenderVisitor : IElementVisitor {
  void Render(IElement e) { e.Accept(this); }
  void Visit(TextElement e) {
  void Visit(ImageElement e) {

Instead of the switch, we would now have new RenderVisitor().Render(element);.

  • An amazing answer. I had heard of the visitor pattern being used to emulate multiple dispatch before, but didn't really know how it might work. Thank you!
    – James Ko
    Jun 22, 2015 at 4:52

Use OOP, if you can. When you call an interface method or a base class method that is overridden, the language will cast the object to the implementing type and provide it as the this pointer. You won't need casting or a switch statement.

In this case, you might have a method like public void DoIt (), which is implemented in each class differently. The code in your switch cases moves into the specific subtypes' implementation of DoIt ()

  • A good concept, but unfortunately a typical library can't render images or text to the screen.
    – James Ko
    Jun 21, 2015 at 22:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.