0

I create an interface for database access to a MySQL database. Currently, this is the only way to access day, but to make it easier to test and in the event that the data access might change, I used an interface.

However, now I am faced with the dilemma of which methods I should put on the interface and which methods I should put on the concrete implementation" directly. Is there a rule of thumb for this?

I will give an example below where I have some CRUD operations for a ICar interface, but then some other utility functions that are just on the concrete implementation. Should these be on the interface as well? I wouldn't want a user to have to implement every method if they didn't need to?

interface ICar {
   Car GetCar(int id);
   void DeleteCar(int id);
   void InsertCar(Car car)
   Car UpdateCar(Car car);
}

class Car : ICar {

  Car GetCar(int id) {}

  void DeleteCar(int id) {}

  void InsertCar(Car car) {}

  Car UpdateCar(Car car) {}

  // methods not on interface, but should they be

  public string GetCarVIN(Car car) {}

  public string GetCarColor(Car car) {}

  public string GetCarMake(Car car) {}

  public string GetCarModel(Car car) {}

  public string GetCarOwner(Car car) {}
}
xaisoft
  • 445
  • 5
  • 12
  • Umm, what methods do you want to expose to the outside world? – Telastyn Mar 27 '15 at 03:52
  • @Telastyn - Well, the obvious CRUD methods, but what if for example, one client wants to get the Owner one way and another wants the Owner another way, does this make it good for an interface, this is what I am struggling with? – xaisoft Mar 27 '15 at 03:54
  • Interfaces should represent methods the client of the interface needs. Not methods the implementer of it provides. – Euphoric Mar 27 '15 at 07:29
  • @gnat: From the sample code, the issue is more about whether the repository object should provide convenience methods that act on individual data. Bad for OOP but maybe okay for convenience trumps everything. – rwong Mar 28 '15 at 21:49

4 Answers4

3

OP is having this confusion because of poor naming.

The reason OP asks this question is because OP has a confusion between the Repository Pattern and general object-oriented design.

The repository object sits between the OOP design - say, a Car class, and the database.

The "repository-object" relation shall not be confused with the "interface-implementation" relation or the "class-object" / "static-instance" relations.

A Car object provides access to the properties that a car (in real life) will usually have (named VIN, Color, Make, Model and Owner in the code example).

On the contrary, the repository object looks like a CarCollection in the abstract sense. The repository object is where CRUD operation belongs to.

To fix this issue, CRUD methods should exist on a CarRepository class (and optionally implementing an ICarRepository interface), and then Car-related methods should exist on a Car object and/or a ICar interface.

In C#, you can both keep the interfaces clean and still give the convenience to your users by using Extension methods.

Keep in mind that if the conceptual mix-up of repository object with data object is enough to give OP headaches, users of such conceptual mix-up is going to get the same kind of headaches, unless the users are being forewarned about it.

public interface ICarRepository
{
    ICar GetCar(int carId);

    // ... other CRUD and query methods,
    // ... but NO car-properties here.
}

public interface ICar
{
    string Owner { get; }
    string VIN { get; }

    // ... other car-properties here.
}

namespace ExtensionMethods
{
    public static class CarExtensions
    {
        public static string GetCarOwnerFromId(this ICarRepository carRepo, int carId)
        {
            return carRepo.GetCar(carId).Owner;
        }

        public static string GetCarVINFromId(this ICarRepository carRepo, int carId)
        {
            return carRepo.GetCar(carId).VIN;
        }
    }
}
rwong
  • 16,695
  • 3
  • 33
  • 81
2

The interface should be as generic as possible. So, while this is an interface of Cars, if we assume that any car will be capable of having an owner, then the method for getting the owner should be inside the interface.

However, any non-generic method, e.g. the method for taking the model of the Car's TV should not be inside the interface, since not all cars will have a TV.

Try to include the methods that any car can have inside the interface. All the other methods that only some cars will possess will be left outside the interface.

Dimos
  • 419
  • 2
  • 10
0

However, now I am faced with the dilemma of which methods I should put on the interface and which methods I should put on the concrete implementation" directly. Is there a rule of thumb for this?

Split the difference and create an abstract class.

radarbob
  • 5,808
  • 18
  • 31
  • That'll work up until he wants to "implement" two of these `abstract class` faux-interfaces at the same time. Abstract classes are not interfaces, they're just a convenient and somewhat dangerous method of reusing method definitions. – Doval Mar 27 '15 at 21:25
  • `public abstract class` vis-a-vis `public interface`. Yeah, they're different. But they both provide an _interface_ – radarbob Mar 27 '15 at 21:30
0

If you intend to use the interface for easier testing, then it should expose all the logic you wish to test on the Car business object. That means every operation that relates to the Car and not the technical implementation.

In your example, I would include all those methods in the ICar.

I would not leave out some methods even if only some cars have them. You should put those in a separate interface, or use inheritance, depending on the situation.

Martin
  • 36
  • 2