components: add wifi_sync component

components/wifi_sync/wifi_credential_syncable_service_factory.h

+// Copyright 2014 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 COMPONENTS_WIFI_SYNC_WIFI_CREDENTIAL_SYNCABLE_SERVICE_FACTORY_H_
+#define COMPONENTS_WIFI_SYNC_WIFI_CREDENTIAL_SYNCABLE_SERVICE_FACTORY_H_
+
+#include "base/macros.h"
+#include "base/memory/singleton.h"
+#include "components/keyed_service/content/browser_context_keyed_service_factory.h"
+
+namespace wifi_sync {
+
+class WifiCredentialSyncableService;
+
+// Singleton that owns all WifiCredentialSyncableServices and
+// associates them with Profiles. Listens for the Profile's
+// destruction notification and cleans up the associated
+// WifiCredentialSyncableServices.
+class WifiCredentialSyncableServiceFactory
+    : public BrowserContextKeyedServiceFactory {
+ public:
+  // Returns the SyncableService for |browser_context|, creating the
+  // SyncableService if one does not already exist.
+  static WifiCredentialSyncableService* GetForBrowserContext(
+      content::BrowserContext* browser_context);

[erikwright (departed), 2014/12/08 21:21:36]

forward-decl BrowserContext.

[mukesh agrawal, 2014/12/09 01:23:50]

content::BrowserContext must have been declared, because BuildServiceInstanceFor
uses it, and BuildServiceInstanceFor is a method declared in
BrowserContextKeyedServiceFactory. Should I forward-declare anyway?

(On the one hand, I see that the forward declaration would make the declaration
of the new function independent of the overridden function. On the other hand,
the forward declaration might be considered redundant. I'm happy to go either
way on it; I just want to make sure I learn the right way to think about it.)

[erikwright (departed), 2014/12/09 12:42:03]

You are correct that the principle is that the include of an implemented
interface should only be relied upon to make the declaration of the overridden
methods valid.

In some cases you might later remove an implemented interface but still use some
of the types referenced. Or a method from that interface might be removed, and
thus the transitive include lost, and then many implementors will suddenly be
missing includes.

In this case that seems unlikely, but simple IWYU rules save trouble in
rationalizing individual cases.

+
+  // Returns the singleton instance. As this class has no public
+  // instance methods, this function is not generally useful for
+  // external callers. This function is public only so that the
+  // Singleton template can reference it.
+  static WifiCredentialSyncableServiceFactory* GetInstance();
+
+ private:
+  friend struct DefaultSingletonTraits<WifiCredentialSyncableServiceFactory>;
+
+  WifiCredentialSyncableServiceFactory();
+  ~WifiCredentialSyncableServiceFactory() override;
+
+  // Implementation of BrowserContextKeyedServiceFactory.
+  KeyedService* BuildServiceInstanceFor(
+      content::BrowserContext* context) const override;
+
+  DISALLOW_COPY_AND_ASSIGN(WifiCredentialSyncableServiceFactory);
+};
+
+}  // namespace wifi_sync
+
+#endif  // COMPONENTS_WIFI_SYNC_WIFI_CREDENTIAL_SYNCABLE_SERVICE_FACTORY_H_