2

I know - I cannot, but.

I want all classes who will implement my interface to have the same owner (usually defined in constructor). What is the best practice to do that?

Should I use some base abstract class or something like this?

JustMe
  • 2,329
  • 3
  • 23
  • 43
  • 1
    Once you have an abstract base class then there is no point at all to have an interface. What you have at that point essentially is an interface. It's difficult to know what you mean by having the same owner. It sounds to me as though you are letting implementation seep into interface. – David Heffernan Oct 24 '12 at 20:52
  • @DavidHeffernan There are plenty of reasons to have an interface, even if you have an abstract base class. – GolezTrol Oct 24 '12 at 20:54
  • @Golez Like what? An abstract class is semantically the same as an interface. – David Heffernan Oct 24 '12 at 20:59
  • @GolezTrol - there are a plenty of reasons to write bad code :) – kludg Oct 24 '12 at 21:00
  • 1
    I guess the point you are missing is that Delphi interfaces are orthogonal to Delphi classes. Your interface can be implemented by a class with any ancestor and any constructor. And that is what the interfaces were designed for. – kludg Oct 24 '12 at 21:15
  • @Serg. You're right about that. Interfaces are designed so you don't *need* to have that abstract base class. However, interfaces serve other purposes as well. You and David make it sound like it is bad practice to use interfaces at all if their implementor share a common ancestor. I think the answer to this question shouldn't be that it's bad to use interfaces if you happen to have a common base class, but that you don't (or shouldn't) need a common base class in the first place once you start using interfaces. – GolezTrol Oct 25 '12 at 06:58
  • @Golez My point is that interfaces don't have implementation inheritance. If you want that then (nearly) abstract base class is your only option. Nobody is saying that interfaces are bad. You need to use the right tool for the job. TStrings is the classic example of a (nearly) abstract base class. – David Heffernan Oct 25 '12 at 07:29

2 Answers2

7

An interface defines a contract between implementor and consumer.

Part of that contract is enforced by the compiler. For example, that all implementations of the interface have the requisite functions of particular names, which take specific parameters.

But there is another part of an interface that is not enforced by the compiler. That's the part of the contract that is described in the interface documentation. You could decide that it suffices to tell all implementors what rules they must abide by. Many libraries take that stance. The Windows API is one prominent example.

If you are dead set on enforcement through code then an interface cannot help. You need something that expresses the constraint in code and in this case that's going to require implementation. Which means you would need to use a class. An (almost) abstract base class could get it done. The only concrete part of the class would enforce the ownership constraint. The rest of the class would be a series of abstract virtual methods. That's not an interface in the sense implied by the Delphi keyword. However, it's an interface in semantic terms.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 1
    Thanks, I read some more and rethinked my interfaces design. To my surprise I achieved more consistent architecture oO – JustMe Oct 25 '12 at 18:26
3

Of course you can choose to implement the interface in a common ancestor, or at least have a common ancestor for the classes that implement the interface. However, you cannot enforce this through the interface. An interface has no constructor and an interface cannot enforce which class can or cannot implement it.

I think the best option would be to expose an Owner property through the interface. That way, you can at least get the owner through the interface, and you will enforce the implementing classes to at least implement that property. B.t.w, an interface is allowed to have properties and methods that return objects or have object parameters.

GolezTrol
  • 114,394
  • 18
  • 182
  • 210