interfaces overused or used correctly?

  • Thread starter Thread starter Big
  • Start date Start date
B

Big

am a bit baffled as to why someone would take this
approach in all of our classes within the project I am
currently working on. Maybe someone else could attempt to
explain the following approach:

public class Class1 : IClass1
{
protected Class1()
{
}
public static IClass1 GetInstance()
{
return (IClass1) new Class1();
}
}

For every class in our system, there is an interface
defined. Instead of using a constructor, we use a
GetInstance method that calls new on our class but casts
the return value to the interface's type.

What advantages does this design approach have?
 
Big said:
am a bit baffled as to why someone would take this
approach in all of our classes within the project I am
currently working on. Maybe someone else could attempt to
explain the following approach:

public class Class1 : IClass1
{
protected Class1()
{
}
public static IClass1 GetInstance()
{
return (IClass1) new Class1();
}
}

For every class in our system, there is an interface
defined. Instead of using a constructor, we use a
GetInstance method that calls new on our class but casts
the return value to the interface's type.

What advantages does this design approach have?
Click to expand...

Well, this factory pattern is presumably meant to allow flexibility for
later implementations. Doing it for every class is silly though.
 
Thanks Jon. I appreciate your input very much.

Where is the flexibility gained? In the GetInstance method
due to the fact you could perform other operations before
instantiation or in the fact that it returns an interface
pointer?

Also, wont inherited classes break if I add a new method
to the base class interface?
 
Big said:
Thanks Jon. I appreciate your input very much.

Where is the flexibility gained? In the GetInstance method
due to the fact you could perform other operations before
instantiation or in the fact that it returns an interface
pointer?
Click to expand...

It's that there's nothing to stop Class1.GetInstance later returning a
completely different implementation - or possibly the same instance
every time (for a singleton) or possibly pooling instances, etc.
Also, wont inherited classes break if I add a new method
to the base class interface?
Click to expand...

Not sure what you mean by that. Could you give an example?
 
Thanks Jon. I do understand the power of the Factory
pattern here as you have described in your last post.

What I don't understand is why someone would chose to cast
the return value to the classes base interface? Isn't this
redundant since all classes have a public interface
composed of all public members. What advantage does the
casting in the GetInstance method provide?
----> return (IClass1) new Class1();
 
This design is reminiscent of the way COM worked( coCreateInstance). -
Factory pattern. From what I see, this design is applicable if you are
adopting SingleTon pattern where you have only a single instance ever
created. The constructor would need to be private in that case. Apart from
Singletons I dont see any other purpose of this design.
 
Big said:
Thanks Jon. I do understand the power of the Factory
pattern here as you have described in your last post.

What I don't understand is why someone would chose to cast
the return value to the classes base interface? Isn't this
redundant since all classes have a public interface
composed of all public members. What advantage does the
casting in the GetInstance method provide?
----> return (IClass1) new Class1();
Click to expand...

Indeed, that cast is redundant. No idea why it's there.
 
Manoj G said:
This design is reminiscent of the way COM worked( coCreateInstance). -
Factory pattern. From what I see, this design is applicable if you are
adopting SingleTon pattern where you have only a single instance ever
created. The constructor would need to be private in that case. Apart from
Singletons I dont see any other purpose of this design.
Click to expand...

There are other uses for factories apart from singletons. Pooling and
later implementation changes (so that the client interface is still
exactly the same, but a different implementation class is actually
used) are just two of them.
 
Could this possibly offer any protection from future use of the class by a
language that wasn't so strongly typed? I mean in C# if you calling a
method defined as:
public static IClass1 GetInstance()
you obviously have to place the result in a IClass1 type. But could you in
a less strongly typed language potentially do
object someObject = Class1.GetInstance()
and then manipulate someObject in unintended ways because it could see
Class1.SecretMethod() for example (which wasn't part of IClass1)?

As I'm typing this I'm thinking no, of course not, that isn't the way it
works since GetInstance() is going to return an IClass1 regardless, so I
guess I just need verification I'm thinking correctly at this point. Maybe
the original coder didn't understand that fully.
 
Back
Top