Banish boilerplate. Profile-keyed API factory for extension API classes.

chrome/browser/extensions/api/profile_keyed_api_factory.h

Index: chrome/browser/extensions/api/profile_keyed_api_factory.h
diff --git a/chrome/browser/extensions/api/profile_keyed_api_factory.h b/chrome/browser/extensions/api/profile_keyed_api_factory.h
new file mode 100644
index 0000000000000000000000000000000000000000..fa9deb36e1fe5aea65ac2a4d38f507dfc43dedb7
--- /dev/null
+++ b/chrome/browser/extensions/api/profile_keyed_api_factory.h
@@ -0,0 +1,91 @@
+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CHROME_BROWSER_EXTENSIONS_API_PROFILE_KEYED_API_FACTORY_H_
+#define CHROME_BROWSER_EXTENSIONS_API_PROFILE_KEYED_API_FACTORY_H_
+
+#include "chrome/browser/extensions/extension_system_factory.h"
+#include "chrome/browser/profiles/profile_dependency_manager.h"
+#include "chrome/browser/profiles/profile_keyed_service.h"
+#include "chrome/browser/profiles/profile_keyed_service_factory.h"
+
+namespace extensions {
+
+// Instantiations of ProfileKeyedAPIFactory should use this base class

[Jeffrey Yasskin, 2012/12/22 00:16:04]

You should mention that the fields need to be accessible to
ProfileKeyedAPIFactory<TheService>. I don't think it would hurt to make them
public, but I don't have a strong preference between that and friend'ing the
factory.

[Yoyo Zhou, 2012/12/26 17:46:33]

Mentioned.
I think it would be okay too if they were public, but I'd prefer for the
visibility to be made explicit.

By the way, I couldn't figure out a way to do this without using protected
visibility.

[Jeffrey Yasskin, 2012/12/26 19:21:55]

Yeah, ProfileKeyedBaseFactory isn't a friend of ProfileKeyedAPI, so it can't see
declarations in here. Making them protected lets the subclass see them, and
thence expose them using that friend declaration. I think.

+// and also declare a static const char* service_name() function (used in the

[Jeffrey Yasskin, 2012/12/22 00:16:04]

s/declare/define/

[Yoyo Zhou, 2012/12/26 17:46:33]

Done.

+// ProfileKeyedBase constructor).

[Jeffrey Yasskin, 2012/12/22 00:16:04]

"ProfileKeyedBaseFactory"?

[Yoyo Zhou, 2012/12/26 17:46:33]

Done.

+class ProfileKeyedAPI : public ProfileKeyedService {
+ protected:
+  // Defaults for flags that control ProfileKeyedAPIFactory behavior.
+  // See ProfileKeyedBaseFactory for usage.
+  static const bool kServiceRedirectedInIncognito = false;
+  static const bool kServiceIsNULLWhileTesting = false;
+};
+
+// A template for factories for ProfileKeyedServices that manage extension APIs.
+// T is a ProfileKeyedService that uses this factory template instead of
+// its own separate factory definition to manage its per-profile instances.
+template <typename T>
+class ProfileKeyedAPIFactory : public ProfileKeyedServiceFactory {
+ public:
+  static T* GetForProfile(Profile* profile) {
+    return static_cast<T*>(
+        GetInstance()->GetServiceForProfile(profile, true));
+  }
+
+  // Users of this factory template must manage their own instances
+  // (typically using LazyInstance or Singleton), because those cannot be
+  // included in more than one translation unit (and thus cannot be initialized

[Jeffrey Yasskin, 2012/12/22 00:16:04]

Please include the code users will need to write in their headers and .cc files.
(See processes_api.cc for my other comment on this.)

[Yoyo Zhou, 2012/12/26 17:46:33]

Done.

+  // in a header file).
+  static ProfileKeyedAPIFactory* GetInstance();
+
+  // Declare dependencies on other factories.
+  // By default, ExtensionSystemFactory is the only dependency; however,
+  // specializations can override this. For instance:
+  //
+  // template <>
+  // ProfileKeyedAPIFactory<PushMessagingAPI>::DeclareFactoryDependencies() {

[Jeffrey Yasskin, 2012/12/22 00:16:04]

And please remind them to declare the specialization in a header file just after
the definition of PushMessageAPI so that the compiler knows to call the
specialization instead of inlining the default. (The definition of the explicit
specialization will have to be 'inline' or in the .cc file since it's just an
ordinary function.)

[Yoyo Zhou, 2012/12/26 17:46:33]

Done.

+  //   DependsOn(ExtensionSystemFactory::GetInstance());
+  //   DependsOn(ProfileSyncServiceFactory::GetInstance());
+  // }
+  void DeclareFactoryDependencies() {
+    DependsOn(ExtensionSystemFactory::GetInstance());
+  }
+
+  ProfileKeyedAPIFactory()
+  : ProfileKeyedServiceFactory(T::service_name(),
+                               ProfileDependencyManager::GetInstance()) {
+    DeclareFactoryDependencies();
+  }
+
+  virtual ~ProfileKeyedAPIFactory() {
+  }
+
+ private:
+  // ProfileKeyedServiceFactory implementation.
+  virtual ProfileKeyedService* BuildServiceInstanceFor(
+      Profile* profile) const OVERRIDE {
+    return new T(profile);
+  }
+
+  // ProfileKeyedBaseFactory implementation.
+  // These can be effectively overridden with template specializations.
+  virtual bool ServiceRedirectedInIncognito() const OVERRIDE {
+    return T::kServiceRedirectedInIncognito;
+  }
+
+  virtual bool ServiceIsCreatedWithProfile() const OVERRIDE {
+    return true;
+  }
+
+  virtual bool ServiceIsNULLWhileTesting() const OVERRIDE {
+    return T::kServiceIsNULLWhileTesting;
+  }
+
+  DISALLOW_COPY_AND_ASSIGN(ProfileKeyedAPIFactory);
+};
+
+}  // namespace extensions
+
+#endif  // CHROME_BROWSER_EXTENSIONS_API_PROFILE_KEYED_API_FACTORY_H_