Empty abstract class enforce structure I've been looking into empty abstract classes and from what I have read, they are generally bad practice. I intend to use them as the foundation for a small search application that I am writing. I would write the initial search provider and others would be allowed to create their own providers as well. My code's intent is enforce relationships between the classes for anyone who would like to implement them.

Can someone chime in and describe why or why not this is still a bad practice and what, if any, alternatives are available?

namespace Api.SearchProviders
{
public abstract class ListingSearchResult
{
    public abstract string GetResultsAsJSON();
}

 public abstract class SearchParameters
 {
 }

 public interface IListingSearchProvider
 {
     ListingSearchResult SearchListings(SearchParameters p);
 } 
 }
To build on @Jesse C. Slicer's comment above: interfaces are for defining contracts, whereas abstract classes are meant to add some base implementation code.  An abstract class without any implementation code does not add anything an interface does not already provide.  Even worse, it blocks inheriting from other (potentially useful) classes.

Relationships can be defined either way.

You are free to provide an abstract class to callers which takes care of some of the base functionality, or you can extract an abstract base class during a later re-factoring pass if you like, but your API should still stick to the interfaces as much as possible.