We Keep Coding

I need Implement interface some methods only

In my project have an interface. In the interface have lot of methods. Our company other developers are inherited the interface in to some classes and implement the all method weather I need implement some methods only. That time I got some error. “Does not implement interface member”. How can I solve this problem?
For example:-
public interface IComplianceRepository
{
IList<ComplianceModel> LoadComplianceModel(Guid userId);
bool CreateCompliance(ComplianceModel complianceModel);
IList<ComplianceType> LoadComplianceType();
IList<ComplianceStatu> LoadComplianceStatus();
IList<UserDetails> LoadUsersBySchoolId(int schoolId);
Compliance GetComplianceByComplianceId(int complianceId);
bool UpdateCompliance(ComplianceModel complianceModel);
UserProfile GetUserProfileDetails(Guid userId);
FinancialCompliance GetFinancialComplianceByComplianceId(int ComplianceId);
void GetComplianceModelByComplianceId(ComplianceModel complianceModel, int complianceId);
}
Many more developers used the above interface and implement the all method. But I don’t want implement the following methods
IList<ComplianceModel> LoadComplianceModel(Guid userId);
bool CreateCompliance(ComplianceModel complianceModel);
How can I solve this problem?

You can't. The only reason of an Interface to exist is so that the whole contract must be implemented in the classes that implement it.

If you cannot or don't want to change the interface, you should implement those methods and throw a NotSupportedException. I recommend using explicit interface inheritance for this, so the dummy methods don't appear on the class.
void IList<ComplianceModel> IComplianceRepository.LoadComplianceModel(Guid userId)
{
throw new NotSupportedException();
}
As an example in the BCL you can look at ReadOnlyCollection.ICollection.Add Method. It's an explicit interface implementation and it throws NotSupportedException. It's also an example for bad design, demonstrating the lack of an IReadOnlyList<T> interface in .net 4.0.
The real solution is refactoring your code. Have smaller interfaces which you implement completely. Take a look at the Interface segregation principle:
The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Create two interface, parent and child.
Parent will have exactly what you want, and child will have others.
public interface Parent {
// parent methods here
}
public interface Child : Parent{
// child methods here
}

If a class implements an interface, it has to implement all of the functionality on that interface. An interface is a contract of functionality, so anything which claims to satisfy that contract must actually do so. Now, you don't have to meaningfully implement everything in that contract. The standard way to do this for a method you know you're not going to use, for example, would be this:
public void SomeMethodIKnowIWontUse()
{
throw new NotSupportedException();
}
So if that method is ever actually used then it will throw an exception. (This would be an indication that you were wrong when you thought it wouldn't be used, and you should implement it.)
Keep in mind that this can quickly lead to a "code smell." If you have a lot of object members which don't need to be implemented then clearly the design is wrong...
Another possibility here is that the interface is incorrectly designed. Perhaps it's trying to be too many things to too many people? This could be a violation of the Single Responsibility Principle. For example, take this interface:
public interface CatchAll
{
void FunctionForOneResponsibility();
void FunctionForCompletelyDifferentResponsibility();
}
Using terribly contrived names, it's clear that this interface has too many responsibilities. It should be this instead:
public interface OneResponsibilitySatisfier
{
void FunctionForThisResponsibility();
}
public interface AnotherResponsibilitySatisfier
{
void FunctionForThisOtherResponsibility();
}
There's no rule that says you need to have few interfaces, or that an interface needs to have many members. Each one should provide a contract of meaningful functionality for its responsibility and nothing more. If by coincidence you have one class which would be used to satisfy both responsibilities, it can implement both interfaces:
public class CrossCuttingObject : OneResponsibilitySatisfier, AnotherResponsibilitySatisfier
{
public void FunctionForThisResponsibility() { }
public void FunctionForThisOtherResponsibility() { }
}

Interfaces exist as a contract between implementers and users of the interface. The users/consumers require that all the methods be implemented. First, ask yourself if your implementation without these methods is still useful. If so, ask yourself if you need to inherit from this interface at all.
If after this reflection, you still have valid reasons to implement this interface without implementing all the methods, you can create stub methods:
IList<ComplianceModel> LoadComplianceModel(Guid userId)
{
throw NotSupportedException();
}
or, more dangerously, but possibly less disruptively:
IList<ComplianceModel> LoadComplianceModel(Guid userId)
{
return null;
}

This is an ideal scenario for Interface segregation. Please refer this design principle here (oodesign.com/interface-segregation-principle.html) You are require to segregate the contracts, don't put all eggs in one basket.

Advantage of using Interface over abstract class for repository pattern? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Interface vs Base class
Its common to see the repository pattern implemented using Interfaces
public interface IFooRepository
{
Foo GetFoo(int ID);
}
public class SQLFooRepository : IFooRepository
{
// Call DB and get a foo
public Foo GetFoo(int ID) {}
}
public class TestFooRepository : IFooRepository
{
// Get foo from in-memory store for testing
public Foo GetFoo(int ID) {}
}
But you could equally do this using abstract classes.
public abstract class FooRepositoryBase
{
public abstract Foo GetFoo(int ID);
}
public class SQLFooRepository : FooRepositoryBase
{
// Call DB and get a foo
public override Foo GetFoo(int ID); {}
}
public class TestFooRepository : FooRepositoryBase
{
// Get foo from in-memory store for testing
public override Foo GetFoo(int ID); {}
}
What are the specific advantages of using an Interface over an Abstract Class in a repository scenario?
(i.e. don't just tell me that you can implement multiple interfaces, I know this already - why would you do that in a repository implementation)
Edit to clarify - pages like "MSDN - Choosing Between Classes and Interfaces" can be paraphrased as "Choose classes over interfaces unless there is a good reason not to" - what are the good reasons in the specific case of a Repository pattern

The main advantage of using an interface over an abstract class in this instance is that an interface is entirely transparent: This is more of an issue where you don't have access to the source of the class you're inheriting from.
However, this transparency allows you to produce unit tests of a known scope: If you test a class that accepts an interface as a parameter (using the dependency injection method), you know you're testing the class with a known quantity; the testing implementation of the interface will only contain your testing code.
Similarly, when testing your repository, you know you're testing just your code in the repository. This helps to limit the number of possible variables/interactions in the test.

Personally, I tend to have an interface that holds the signature for the methods that are purely "business-related" for example Foo GetFoo(), void DeleteFood(Foo foo), etc. I also have a generic abstract class that holds protected methods like T Get() or void Delete(T obj).
I keep my methods protected in the abstract Repository class so that the outside world is not aware of the plumbery (Repository will look like object) but only of the business model via the interface.
On top of having the plumbery shared another advantage is that I have for example a Delete method (protected) available to any repository but it is not public so I am not forced to implement it on a repository where it has no business meaning to delete something from my data source.
public abstract class Repository<T>
{
private IObjectSet objectSet;
protected void Add(T obj)
{
this.objectSet.AddObject(obj);
}
protected void Delete(T obj)
{
this.objectSet.DeleteObject(obj);
}
protected IEnumerable<T>(Expression<Func<T, bool>> where)
{
return this.objectSet.Where(where);
}
}
public interface IFooRepository
{
void DeleteFoo(Foo foo);
IEnumerable<Foo> GetItalianFoos();
}
public class FooRepository : Repository<Foo>, IFooRepository
{
public void DeleteFoo(Foo foo)
{
this.Delete(foo);
}
public IEnumerable<Foo> GetItalianFoos()
{
return this.Find(foo => foo.Country == "Italy");
}
}
The advantage of using the abstract class over an interface for the plumbery is that my concrete repositories do not have to implement method they don't need (Delete or Add for example) but they are at their disposal if they need it. In the current context, there is no business reason for to some Foos so the method is not available on the interface.
The advantage of using an interface over an abstract class for the business model is that the interface provides the answers to how it make sense to manipulate Foo from a business side (does it make sense to Delete some foos? To create some? etc.). It's also easier to use this interface when Unit testing. The abstract Repository I use cannot be unit tested because it is usually tightly coupled with the database. It can only be tested in integration tested. Using an abstract class for the business purpose of my repositories would prevent me from using them in unit tests.

This is a general question that applies to any class hierarchy, not just repositories. From a pure OO point of view, an interface and a pure abstract class are the same.
If your class is part of a public API, the primary advantage of using an abstract class is that you can add methods in the future with little risk of breaking existing implementations.
Some people also like to define an interface as "something that a class can do" and a base class as "what a class is", and therefore will only use interfaces for peripheral capabilities and always define the primary function (eg. repository) as a class. I'm not sure where I stand on this.
To answer your question, I don't think there is any advantage to using an interface when it defines the primary function of the class.

While others may have more to add, from a purely practical point of view, most IoC frameworks work better with interface -> class mappings. You can have different visibilities on your interfaces & classes, whereas with inheritance, the visibilities must match.
If you're not using an IoC framework, from my point of view there is no difference. Providers are based on abstract base classes.

I guess the key difference would be, that an abstract class can contain private properties & methods, wherein an Interface cannot, as it's only a simple contract.
The result being an interface is always "no shenanigans here - what you see is what you get" whilst an abstract base class may allow side effects.

Take a look at the implementation of Tim McCarthy's Repository Framework.
< http://dddpds.codeplex.com/ >
He uses interfaces like IRepository<T> for defining the contracts, but he also uses abstract classes like RepositoryBase<T> or his SqlCeRepositoryBase < T > that implements IRepository<T>. The abstract base class is code to eliminate a lot dublicate code. A type specific repository just have to inherit frome the abstract base class and needs to add the code for its purpose. Users of the API can just code against the interface by contract.
So you can combine both approaches to use the advantages of them.
Additionally, I think most IoC-Frameworks can handle abstract classes.

Since the pattern originates in Domain Driven Design, here's a DDD answer :
The contract of a Repository is usually defined in the Domain layer. This allows objects in the Domain and Application layers to manipulate abstractions of Repositories without caring about their real implementation and the underlying storage details - in other words, to be persistence-ignorant. Besides, we often want specific behaviors to be included in the contracts of some repositories (in addition to your vanilla Add(), GetById(), etc.) so I prefer the ISomeEntityRepository form than just IRepository<SomeEntity> - we'll see why they need to be interfaces later.
The concrete implementations of Repositories, on the other hand, reside in the Infrastructure layer (or in the Tests module for test repositories). They implement the above repository contract but also have their own range of persistence-specific characteristics. For instance, if you're using NHibernate to persist your entities, having a superclass to all the NHibernate repositories with the NHibernate session and other NHibernate-related generic plumbing in it could come in handy.
Since you can't inherit several classes, one of these 2 things that your final concrete Repository inherits has to be an interface.
It's more logical for the Domain layer contract to be an interface (ISomeEntityRepository) since it's a purely declarative abstraction and mustn't make any assumption about what underlying persistence mechanism will be used - i.e. it mustn't implement anything.
The persistence-specific one can be an abstract class (NHibernateRepository or NHibernateRepository<T> in the Infrastructure layer) which allows you to centralize there some behaviors that are common to the whole range of persistent-store-specific repositories that will exist.
This results in something like :
public class SomeEntityRepository : NHibernateRepository<SomeEntity>, ISomeEntityRepository
{
//...
}

Base entity class. NHibernate

Would it be a good practice to implement entity base class like that:
[Serializable]
public abstract class Entity<T> : IComparable<Entity<T>>, IFormattable
{
public abstract Int32 CompareTo(Entity<T> entity);
public abstract String ToString(String format, IFormatProvider provider);
// ...
}
So all derived classes must implement those interfaces.
Is it reasonable to put IComparable<T> interface on entity class?
Thanks!

It's not a good (or bad) practice - it comes down entirely to your needs.
Specifying IComparable at such as general level comes with the risk that it may not make sense to compare some objects further down in the inheritance chain. Even if you can compare two objects, would it always make sense to? You may be requiring lines of code to be written to satify a contract which would never be used - beware of YAGNI circumstances.
However, this would be fine if you need to create an absolute contract so that any objects inheriting from Entity can be compared. This allows you to make positive assumptions in your code.

What would T be? Your domain class? If that's the case why not make the Entity class non-generic and directly inherit from Entity?
In general, I've found it to be a good practice to derive all domain classes that can be handled by a particular Repository from a common interface or base class. This allows the Repository to be generic to that interface, providing compile-time checking that you are attempting to use the Repository to persist something that the Repository has mapped. If you use a base class, though, don't map it unless you need a way to uniquely identify any Entity regardless of its actual subclass type; otherwise you'll get that Entity table (with any common fields) as a table in your DB and it can become difficult to manually trace through your data layer.
However, a common, mapped Entity may be desireable; you may want to uniquely identify Persons and Companies by a common ID column that is unique even through Persons and Companies are saved to different tables.
Here's a sterilized example of the hierarchy I've used in one of my projects:
//identifies a class as persistable, and requires the class to specify
//an identity column for its PK
public interface IDomainObject { long Id {get;} }
//In a repository-per-DB model, just because it's an IDomainObject doesn't mean
//a repo can work with it. So, I derive further to create basically "marker"
//interfaces identifying domain objects as being from a particular DB:
public interface ISecurityDomainObject:IDomainObject { }
public interface IDataDomainObject:IDomainObject { }
public interface IData2DomainObject:IDomainObject { }
//There may be logic in your repo or DB to prevent certain concurrency issues.
//You can specify that a domain object has the necessary fields for version-checking
//either up at the IDomainObject level, a lower level, or independently:
public interface IVersionedDomainObject:IDomainObject
{
long Version {get;}
string LastUpdatedBy {get;}
DateTime LastUpdatedDate {get;}
}
//Now, you can use these interfaces to restrict a Repo to a particular subset of
//the full domain, based on the DB each object is persisted to:
public interface IRepository<TDom> where TDom:IDomainObject
{
//yes, GTPs can be used as GTCs
T GetById<T>(long Id) where T:TDom;
void Save<T>(T obj) where T:TDom;
//not only must the domain class for SaveVersioned() implement TRest,
//it must be versionable
void SaveVersioned<T>(T versionedObj) where T:TDom, IVersionedDomainObject
}
//and now you can close TDom to an interface which restricts the concrete
//classes that can be passed to the generic methods of the repo:
public class ISecurityRepo:IRepository<ISecurityDomainObject> { ... }

If your entities require comparability and formatting than using a base class is a very good practice.
sometimes the identity field is also implemented in the base class.

I think I missed something on the "Programming to an interface" concept

So I am still very new to C# and using interfaces, and when I thought I understood them I realized I don't completely. The confusion I have found that I am seeking some clarification here for is, when you create an interface, and have a class inherit from it
public Interface ISomeInterface
{
//some methods/properties
}
public class FooClass : ISomeInterface
{
//implemented ISomeInterfaces methods/properties
}
And you use this class object in an implementation somewhere in your program
public class BarClass
{
private ISomeInterface _someInterface;
public BarClass(ISomeInterface someInterface)
{
_someInterface = someInterface;
}
//rest of class
}
My confusion is why do I see it setup this way. I thought that I would have instantiated a new object of type FooClass, as well as used an object of type FooClass in the constructor as such:
public class BarClass
{
private FooClass _fooClass;
public BarClass(FooClass fooClass)
{
_fooClass = fooClass;
}
//rest of class
}
What am I missing to understanding this? I didn't think I would directly be declaring objects of an Interface?
Thanks in advance.

The idea is that BarClass should not be tightly coupled to a specific implementation of ISomeInterface.
If you use this:
public BarClass(FooClass fooClass)
it means that the BarClass can work only with this specific FooClass implementation and nothing else. Whereas if you use:
public BarClass(ISomeInterface fooClass)
now the BarClass is no longer tightly coupled to FooClass. This means that the consumer of the BarClass can now pass any implementation of the interface he wants as long as it respects the defined contract (interface). So if he wants FooClass he passes an instance of FooClass, but if he is not satisfied with FooClass he can write his own implementation and pass it to the constructor and from the point of view of the BarClass this is absolutely transparent (it doesn't need to be modified).
The weak coupling between your classes is one of the most fundamental aspects of OOP as it allows you to easily replace one component with another without having to rewrite your entire application.

Suppose FooClass wrote something to a database. You'd like to test BarClass without having to actually set up a database. If you created a different TestFoo that implemented the same interface, you could pretend to be the database and more easily test your class; BarClass wouldn't have to know that it wasn't talking to the 'real' FooClass.

Do you have a C/C++ background? Then you should be aware that
private ISomeInterface _someInterface;
would be written as
private:
ISomeInterface& _someInterface;
In C++ (assuming you have an abstract base class called ISomeInterface).
This means you are storing a reference to an object implementing ISomeInterface not such an object itself. The advantage of this is that you can pass ANY object to BarClass that implements ISomeInterface which gives you more flexibility, e.g. for unit testing.

By using the interface definition instead of the concrete implementation, your code is now more loosely coupled. This technique is used in dependency injection.
In addition, this comes in handy when you need to need to implement FooClass differently. If you used the concrete implementation, you will need to make code changes where ever you have declared FooClass. Programming against the interface shields you from the effects of such changes.

One of the main benefit to program to ISomeInterface instead of FooClass, is that you might probably change your implementation of FooClass. For example, consider a database driven blog application:
interface IBlogStorage{
getPosts();
}
you then have a class like:
class XMLBlogSotrage: IBlogStorage{}
and suppose you implement everything to the interface. later on, you think XML is too slow and you want to use RDBMS, then:
class MsSQLBlogStorage:IBlogStorage{}
In this case, you don't need to change anything in other codes, you just need to create a new class and plug it in! Those already existed codes, doesn't need to bother where is the storage.

Another way of thinking about the interplay between interfaces and classes is to flip them upside down. That means to start with classes first. Let's say you have several classes that expose a method called "Sort()". Then you have another class that has a method that requires references to these classes and in turn calls their "Sort()" methods. Instead of having several methods with different parameters, you can create and attach an interface to those classes (very quick fix as these classes already contain the implementation).
A.Sort()
B.Sort()
C.Sort()
interface ISortable {void Sort();}
A : ISortable
B : ISortable
C : ISortable
D.SortSomething(ISortable foo)
{
foo.Sort()
}
Maybe this is too abstract. My favorite use of interfaces is enabling my classes to participate in foreach loops.
class SomeCollection : IEnumerable
{
List<SomeItem> _items = new List<SomeItem>();
// This is the only code I need to enable this class to participate in foreach loop.
public Enumerator GetEnumerator()
{
return _items.GetEnumerator();
}
}
Once you discover how interfaces can simplify your codes, you can even begin creating interfaces before writing your classes.

C# Interface for multiple classes

I have a data provider project to access the database. this is composed by various classes (PersonDataProvider, JobDataProvider ...)
I want to create an Interface.
Do I have to create an Interface for each class?
I was tempted to create one interface and than inherit on all the classes. This involves making all the projects classes partial and change the classes name.......But i think is not the best solution.
Any suggestion?

You don't inherit an Interface you implement it. There's no need to make a class partial to add an interface to it.
An interface is a contract that the class subscribes to saying that it will honour the methods described in the interface and will implement them appropriately. For your scenario you'd create a single interface and implement it in your classes, you can then pass the instances of the various accessor classes as instances of the interface.
For example:
public interface IDataProvider
{
void LoadData();
}
The data providers would then look as follows:
public class MyDataProvder1 : IDataProvider
{
// Some methods
// Must implement LoadData
public void LoadData()
{
// Do something
}
}
public class MyDataProvder2 : IDataProvider
{
// Some methods
// Must implement LoadData
public void LoadData()
{
// Do something
}
}
You can then pass the objects as IDataProvider as follows:
IDataProvider DataProviderA = new MyDataProvider1();
IDataProvider DataProviderB = new MyDataProvider2();
// Call function that expects an IDataProvider
DoSomething(DataProviderA);
DoSomething(DataProviderB);
...
public void DoSomething(IDataProvider DataProvider)
{
DataProvider.LoadData();
}
Hopefully that clears it up for you.

I think you are approaching this incorrectly.
When you make an interface, you're making a contract for those classes. Think of it as "my class will act as a IMyInterface".
If all of your classes have a common usage scenario, then a single, common interface may be appropriate (IDataProvider, given the class names..?).

Using interface depends how you want to arrange the classes. Interface allows some sort of plug and play behaviour. So, if you need a single interface, this will mean that you shall have a single set of interfaces accross all the classes implementing the interface. In such a case, your classes PersonDataProvider, JobDataProvider etc. will have the same set of methods. If you feel, they need to be different and still be available through a single provider facade, you can think of using a facade pattern.
The facade will have interfaces for individual provider and the provider classes will implement them.

First off, I'm assuming there are standard method calls across all your xDataProvider classes. For example, instead of a SelectPerson method, you have a Select method on the PersonDataProvider class. If not, you have some work to do to make this a valid exercise.
Within Visual Studio, there is an Extract Interface refactoring option. Right-click in a xDataProvider class and choose Refactor - Extract Interface. Now name it (IDataProvider, for example) and choose the methods / properties you want in your interface, click OK and your done with this class.
Then just implement this IDataProvider interface in your other xDataProvider classes. Assuming you've already implemented similar methods in all you DataProvider classes, you won't have to write any more code (beyond the : IDataProvider).