On Friday, 2013-06-28, Jan Kundrát wrote: > On Friday, 28 June 2013 15:17:46 CEST, Thomas Lübking wrote: > > Error logging or similar can connect a generic "Job::error(int > > id, QString desc)" slot and you don't have to define the > > signals, resp. members/getters lilke m_/id() multiple times. > > I still don't see a big benefit in this. It would make sense to me if there > was e.g. a common code path on what to do when hitting such a failure, or > if the jobs were managed in some unified manner. > > I would prefer not to use class inheritance just to save some code.
I usually do a base job class when I have multiple jobs in an API and want consistent behavior, so that developers working with the API can treat jobs the same all over the place. Which usually boils down to error() and errorString(), result(Job*) signal, autoDelete handling. That way code dealing with jobs is always the same: 1) create job 2) connect result signal 3) start in result slot 1) check error 2a) cast to actual job 2b) retrieve any data Job implementation is also consistent in that you either set error or result data and call the method that emits signal and schedules deletion. Obviously modelled after KJob, but without the I/O related things like progress. It is of course also possible to copy that "base" code into multiple base classes that do not share a common ancestor :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
