Jump to content
David Schwartz

splitting interface + implementation

Recommended Posts

I recall reading somewhere about how to split up the Interface and implementation parts of a unit into diferent files. 

 

It may have been a chapter in a Delphi book as opposed to something online. 

 

I'm wondering if anybody remembers this and can tell me where to find it?

 

I've got a pile of Delphi books, most are eBooks on Kindle, and I have not had any luck searching for it because of so many overloads of these terms.

Share this post


Link to post
Just now, Martin Sedgewick said:

I have not heard of doing that. Why would you want to do that? Have you a specific reason?

FPC does things like that with include files, if different platforms have sufficiently different implementations.

 

Share this post


Link to post
3 hours ago, dummzeuch said:

The only way of doing that, that I am aware of, is include files.

Yes include files will work.

But be aware of that precompiled units will break easily, when making changes the include file, which will lead to nasty errors.

So this kind of unit + "include" should be always re-compiled.

Share this post


Link to post
4 hours ago, David Schwartz said:

I recall reading somewhere about how to split up the Interface and implementation parts of a unit into diferent files. 

This was likely advised by an ill C-er to spread the C-style madness over another languages. AFAIK no language uses this mechanism besides C which kinda alludes.

1 hour ago, Virgo said:

FPC does things like that with include files, if different platforms have sufficiently different implementations.

Yes and it makes source examining a real nighmare. Alas, there's no better option to avoid code duplication.

  • Like 2

Share this post


Link to post
On 10/1/2021 at 2:11 PM, Fr0sT.Brutal said:

This was likely advised by an ill C-er to spread the C-style madness over another languages. AFAIK no language uses this mechanism besides C which kinda alludes.

Ah, so those are the C header files...?! Basically only the descriptors?

On 10/1/2021 at 2:11 PM, Fr0sT.Brutal said:

Yes and it makes source examining a real nighmare. Alas, there's no better option to avoid code duplication.

Tbh I still don't get why splitting Interface and Implementation would help to avoid code duplication. If you have two units where the implementation section is the same, you can use helpers / a class which does the work / not to have two different units but use only the first one.

Take this with a grain of salt, though. I just can not - yet - imagine a scenario where this would be beneficial.

Share this post


Link to post

I don't think it used include files.

 

It's just something I remember seeing and wanted to review, but I can't remember where I saw it.

 

Maybe in a book or an article somewhere.

Edited by David Schwartz

Share this post


Link to post
8 hours ago, David Schwartz said:

I don't think it used include files.

There's no other way. The interface and implementation sections of a unit must be in a single translation unit and the only way to have multiple files in a single translation unit is with include files. 

Share this post


Link to post
45 minutes ago, David Heffernan said:

There's no other way. The interface and implementation sections of a unit must be in a single translation unit and the only way to have multiple files in a single translation unit is with include files. 

That may be true. I saw it discussed elsewhere and that's why I was looking for that article, because I didn't think it used them. Haven't found it yet, tho.

Share this post


Link to post
4 minutes ago, David Schwartz said:

because I didn't think it used them

As I demonstrated in my previous comment what you are looking for is impossible so clearly you must have misremembered. 

  • Haha 1

Share this post


Link to post
On 10/2/2021 at 10:38 PM, aehimself said:

Tbh I still don't get why splitting Interface and Implementation would help to avoid code duplication. If you have two units where the implementation section is the same, you can use helpers / a class which does the work / not to have two different units but use only the first one.

Take this with a grain of salt, though. I just can not - yet - imagine a scenario where this would be beneficial.

Well...

intf
  procedure DoXPlatformStuff

impl

 procedure DoXPlatformStuff
 {$ifdef windows}
   do
   lots
   of
   Windows
   stuff
 {$endif}
 {$ifdef lunix}
   do
   lots
   of
   Linux
   stuff
 {$endif}
 {$ifdef macos}
   do
   lots
   of
   MacOS
   stuff
 {$endif}
 ... repeat for all 100 platforms FPC supports

and do it for EVERY platform-specific function

Compare with includes:

intf
  procedure DoXPlatformStuff

impl

 {$ifdef windows}
   {$I 'dowindows.inc'}
 {$endif}
 {$ifdef lunix}
   {$I 'dolinux.inc'}
 {$endif}
 {$ifdef macos}
   {$I 'domacos.inc'}
 {$endif}
 ... repeat for all 100 platforms FPC supports

 

  • Like 2

Share this post


Link to post
19 minutes ago, aehimself said:

Call me old-fashioned, I'd simply use {$REGION}-s

REGION ruleZ! However, it's not about code navigation. It's about code structuring. I examined Delphi RTL units that use all-in-one approach and have large inactive/unfoldable pieces for non-current platforms and examined FPC sources which are assembled from numerous small platform-specific chunks. Both options aren't ideal but FPC one is a nightmare if you want to find something concrete. However, this simplifies navigation.

Edited by Fr0sT.Brutal

Share this post


Link to post

if I remember correctly it was in one of the Nick Hodges books - but that is off the top of my head without any guarantee

Share this post


Link to post

Dependency Injection.  Works like charm unless you need absolute raw performance.

I use that quite a bit for pluggable capabilities.

 

I am not a fan of .inc files at all.  I use platform specific units and ifdef the uses statements. 

I do have a xplatform unit that ifdefs the various implementations - many of who simply raise Exception.Create('Not implemented'); 😛

 

Share this post


Link to post
14 hours ago, baeckerg said:

if I remember correctly it was in one of the Nick Hodges books - but that is off the top of my head without any guarantee

That's what I was thinking, too. But I skimmed through the two "Coding in Delphi" books and didn't find it. Maybe the DI book?

Share this post


Link to post

Something just triggered the word "namespaces". I remember now that when discussing this topic on G+ there was the hope of splitting code of a namespace into multiple units.

Unfortunately I don't remember if anything ever was implemented for this.

Share this post


Link to post
Include files

I like to use separation in clear defined units, something like this.

That needs some kind of discipline, I'm not always that strict, but I would prefer such separation over cluttering one unit with a lot of includes

 

Just roughly scribbled the code like that:

unit MyUnit.Intf;

interface

Uses
{$if   DEFINED ( windows )}
    MyUnit.Intf.Win;
    
type
    TMyUnit = MyUnit.Intf.Win.TMyUnit;
    
{$ELSEIF DEFINED( linux ) }
    MyUnit.Intf.Linux;
    
type
    TMyUnit = MyUnit.Intf.Linux.TMyUnit;    
    
{$ELSEIF DEFINED( macos ) }
    MyUnit.Intf.Macos;
    
type
    TMyUnit = MyUnit.Intf.MAcos.TMyUnit;    
    
{$else}    
{$MESSAGE ERROR 'MyUnit.Intf: Unsupported platform' }
{$endif}

....

That results in two main advantages:

- NO INCLUDE's needed in the underlying sub-units

- a clear error message when unknown conditionals were used

 

 

Edited by Rollo62

Share this post


Link to post

My question was if anybody knows the BOOK that contains a discussion of this topic?

 

I'm looking for the chapter in a BOOK where this is discussed.

 

It was a DELPHI book, possibly by Nick Hodges

Share this post


Link to post
1 hour ago, David Schwartz said:

My question was if anybody knows the BOOK that contains a discussion of this topic?

 

I'm looking for the chapter in a BOOK where this is discussed.

 

It was a DELPHI book, possibly by Nick Hodges

 

On 10/1/2021 at 8:37 AM, David Schwartz said:

I recall reading somewhere about how to split up the Interface and implementation parts of a unit into different files. 

 

It has been demonstrated this is only possible using include files.  I'm not sure what you can expect to find in a book that can add to this knowledge, and I doubt very much that ALL CAPS is going to unlock any blockage.  Perhaps more likely is that what you are remembering was how to split something other than interface and implementation parts of a unit.  

Edited by David Heffernan

Share this post


Link to post

In that case, @David Schwartz, it is probably the DI book, as you speculated above.

https://www.amazon.com/Dependency-Injection-Delphi-Nick-Hodges/dp/1941266223

 

The other approach, using interfaces vs include files- has been touched here:
https://stackoverflow.com/questions/1011006/separating-interface-and-implementation-classes-in-delphi

and interfaces are discussed in Nick's Coding in Delphi and IIRC in the good old "Delphi in a Nutshell" by Ray Lischner.

 

Share this post


Link to post
3 hours ago, David Schwartz said:

My question was if anybody knows the BOOK that contains a discussion of this topic?

 

I'm looking for the chapter in a BOOK where this is discussed.

 

It was a DELPHI book, possibly by Nick Hodges

The only thing that includes terms "interface" and "implementation" and that CAN be separated in different files are interface declarations and classes that implement those interfaces and implementing classes will again have interface and implementation part in the unit file itself.

 

If it was Nick's book, it could be Coding in Delphi or Dependency Injection in Delphi, but again you will not find anything there about separating interface and implementation parts of the unit because that cannot be done (besides using include files), only how to use interfaces.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×