[Kde-pim] Extracting some code from KMail into a lib

[Ingo Klöcker]

On Friday 24 September 2010, Andras Mantia wrote:
> Thomas McGuire wrote:
> > Hi Andras,
> > 
> > why not make MailCommon a singleton and let KMKernel be a subclass
> > of it? That way, you could avoid passing it around all the time.
> > Otherwise I'm ok with this.
> 
> I was thinking of something similar, like having another singleton,
> but thought that having it in a lib (global static object) and
> having two singletons (MailCommon and KMKernel) might not be a good
> idea. I will give a mind-trip about what would be if KMKernel
> inherits MailCommon, though.

I agree with Thomas that it should be a proper singleton if it is a 
singleton. I don't see the problem with two singletons if in the desktop 
version MailCommon is just an interface to KMKernel.

A cleaner solution would be a pure interface IMailCommon and a Registry 
singleton where, at application start, a concrete implementation of 
IMailCommon is registered and from which the interface can be retrieved, 
i.e. something like

class IMailCommon
{
public:
  virtual ~IMailCommon() {}
  virtual foo() = 0;
  [...]
}

class Registry
{
  Registry();
public:
  static Registry * self() { // construct instance if necessary, then 
return pointer to it }
  void registerMailCommon( IMailCommon * mailCommon ) { 
_mailCommon.reset( mailCommon ); }
  IMailComon * mailCommon() const { _mailCommon.get(); }
private:
  boost::scoped_ptr<IMailCommon> _mailCommon;
}


Then in main.cpp for KMail desktop:
  Registry::self()->registerMailCommon( new KMKernel );

And everywhere where anything from IMailCommon is needed (e.g foo()):
  Registry::self()->mailCommon()->foo();

If you think this is too much to type then you can still add a #define 
for Registry::self()->mailCommon().


Quite frankly, I don't like a generic interface like IMailCommon. I'd 
prefer multiple smaller interfaces with clear responsibility (which 
would all be registered and accessible via Registry). KMKernel would 
implement all of those interfaces while the mobile version only 
implements some of those interfaces.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100924/57557ed0/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/