Presented without comment, because I honestly don't know enough about our software to tell what this does.

using System;
using System.Text;

namespace OurProgramInterfaces
{
    public interface IBaseInput:IBaseParams
    {




    }





}

and of course, its sister class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OurProgramInterfaces
{
    public interface IBaseOutput:IBaseParams
    {
    }
}

Marker interfaces?

There are valid reasons to use something like this; it's a common software idiom called "Marker Interfaces".  You have an empty interface that exists so you can test if a derived class should have a certain behavior (because C# doesn't support multiple inheritance).  For instance, let's say I have some domain entity, and I need to determine if it should have update timestamps applied to it.  I can create an interface called say ITrackable that doesn't do anything itself, implement it in my class, and then check later if my class implements it.

Given the above example I'd guess it's something like that.  There's probably some conditional logic that checks if x is IBaseInput or IBaseOutput and does something if it is.  May or may not be a WTF depending on usage.

lscharen:

Marker interfaces?

Google?

PJH:

lscharen:

Marker interfaces?

Google?

What's PJH supposed to Google, pray? "IBaseInput:IBaseParams" or what?

Actually, that does not make a lot of sense to me. If you want to check if a class supports certain behavior, check the name of the bloody class that actually defines that behavior! And checking that kind of stuff by naming is, well, asking for trouble.

"Look, guv', the log files are growin'. And every bleedin' line says sumfin' bout an eye track ball."

toon:

What's PJH supposed to Google, pray?

Nothing. I was expecting Ischaren to Google "Marker interfaces."

TGV:

Actually, that does not make a lot of sense to me. If you want to check if a class supports certain behavior, check the name of the bloody class that actually defines that behavior! And checking that kind of stuff by naming is, well, asking for trouble.

I'm not sure whether I don't understand the point you're trying to make, or whether you don't understand marker interfaces.

 

PJH:

toon:

What's PJH supposed to Google, pray?

Nothing. I was expecting Ischaren to Google "Marker interfaces."

Sorry; it seems I'm not the brightest knife in the chandelier drawer today.

My point was meant to be, that I don't understand why you'd have Ischaren google something he/she obviously already knows about.

toon:

My point was meant to be, that I don't understand why you'd have Ischaren google something he/she obviously already knows about.

It wasn't obvious. Indeed, the opposite appears to be the case.

everyone:

Marker interfaces?

After further inspection, it seems that these interfaces are used to create the class hierarchy - a certain operation has input parameters (an IBaseInput) and output parameters (an IBaseOutput). Both are always implementation of sub-interfaces - ISomeInput, etc.. Less of a WTF than I thought, but still quite strange.

Even so, they should contain some comments along the lines of "deliberately empty because <reasons>".

TGV:

Actually, that does not make a lot of sense to me. If you want to check if a class supports certain behavior, check the name of the bloody class that actually defines that behavior! And checking that kind of stuff by naming is, well, asking for trouble.

"Look, guv', the log files are growin'. And every bleedin' line says sumfin' bout an eye track ball."

Are you suggesting I should

object.GetType().Name.Contains("PartOfClassName")

? Good luck with that.

PJH:

toon:

My point was meant to be, that I don't understand why you'd have Ischaren google something he/she obviously already knows about.

It wasn't obvious. Indeed, the opposite appears to be the case.

Given the fact that Marker Interfaces were not mentioned in the OP, it seems quite obvious to me that Ischaren was suggesting Marker Interfaces was the answer. "Marker Interfaces?" as in "Could it be the case that these are used as Marker Interfaces?"

I'm actually using marker interfaces in some code of mine. It looks kind of like

public interface IAutoFrob {
}

public interface IAutoFrobInASpecificWay : IAutoFrob {
    int FrobRate { get; set; }
    FrobPreperationStatus GetFrobPreperationStatus(int foo, string bar);
}

The first class says the class can do a certain procedure automatically, the second says it will use a lot of features from the automatic system but it has a property and method to control it more fine-grained.

This is C#, not Java 1.1. Therefore you should use Attributes instead of Marker interfaces :)

Is there a particular scenario where Attributes would be useful (other than brand new shiny feature)?  Not being a dick here -- it just seems like 

if (instanceof Foo) { doSomethingConcrete() }

Is fairly straightforward. Attributes could give you a richer set of things to inspect, but maybe at the cost of a level of indirection that could cause more problems in the long run. Is there a particular area where this would be useful? Just curious, as my imagination has hit the wall after 14 hours at work...

TGV:

Actually, that does not make a lot of sense to me. If you want to check if a class supports certain behavior, check the name of the bloody class that actually defines that behavior! And checking that kind of stuff by naming is, well, asking for trouble.

 

The whole point of a marker interface is that the classes that you're looking for don't even exist at this time.  For example, in Java the Serializable marker interface tells Java that you can serialize the class to a file.  Clearly the people who wrote serialization didn't know about every custom class anyone would ever want to serialize.

In C#, there are attributes which are generally preferred, but there can be cases where a marker interface is more appropriate..  For example, a marker interface can be used as a constraint for generics, allowing for some additional compile-time type checking; you can't do a compile-time generic constraint on an attribute.

chooks:

Is there a particular scenario where Attributes would be useful (other than brand new shiny feature)?  Not being a dick here -- it just seems like 

if (instanceof Foo) { doSomethingConcrete() }

Is fairly straightforward. Attributes could give you a richer set of things to inspect, but maybe at the cost of a level of indirection that could cause more problems in the long run. Is there a particular area where this would be useful? Just curious, as my imagination has hit the wall after 14 hours at work...

 

Attributes have a few advantages over marker interfaces.  One big one is inheritance - an interface is always inherited, but an attribute may or may not be inherited.  Plus, you can tag individual methods and properties with attributes, but not with marker interfaces.

Cat:

chooks:

Is there a particular scenario where Attributes would be useful (other than brand new shiny feature)?  Not being a dick here -- it just seems like 

if (instanceof Foo) { doSomethingConcrete() }

Is fairly straightforward. Attributes could give you a richer set of things to inspect, but maybe at the cost of a level of indirection that could cause more problems in the long run. Is there a particular area where this would be useful? Just curious, as my imagination has hit the wall after 14 hours at work...

 

Attributes have a few advantages over marker interfaces.  One big one is inheritance - an interface is always inherited, but an attribute may or may not be inherited.  Plus, you can tag individual methods and properties with attributes, but not with marker interfaces.

Attributes may also be passed parameters.

Cat:

Attributes have a few advantages over marker interfaces.

 

Attributes are accessed via reflection, which is much slower than a simple instanceof check. Sometimes you need efficiency, not features.

A good example for a marker interface is Java's RandomAccess, btw.

 

PJH:

toon:

My point was meant to be, that I don't understand why you'd have Ischaren google something he/she obviously already knows about.

It wasn't obvious. Indeed, the opposite appears to be the case.

Seemed pretty obvious he was saying "[perhaps they're] marker interface?"

derari:

Attributes are accessed via reflection, which is much slower than a simple instanceof check. Sometimes you need efficiency, not features.

A good example for a marker interface is Java's RandomAccess, btw.

 

One shouldn't be performing instanceof checks- or attribute checks, for that matter- in a tight loop to begin with, though. 

 

 I agree with Mihi. Java has annotations now, which are far more powerful, and I would hope and assume the C# has a similar feature.

In fact, Java annotations were more or less based of C#'s attributes. :)

And if you think RandomAccess as an interface is a good idea, have a look at implementation of Collections.synchronizedList method (or some other examples) - it makes it really hard to implement wrapper implementations for lists. Having an isRandomAccess() method inside the List interface would have made it so much easier (having the additional benefit that everyone who implements a List himself is forced to think about this decision, and cannot forget to implement RandomAccess).

derari:

Cat:

Attributes have a few advantages over marker interfaces.

 

Attributes are accessed via reflection, which is much slower than a simple instanceof check. Sometimes you need efficiency, not features.

A good example for a marker interface is Java's RandomAccess, btw.

 

If the relative efficiency between an instanceof and an attribute check actually matters, your design is stupid.

This is the Interface Orgy design pattern. I am convinced there is a guy over in India teaching that this design pattern solves all problems if you make it deep enough. If I ever meet that guy I'm going to slit his throat right in front of his family. Or yeah, they're markers :)