Adding a NetworkProfileHandler used by ManagedNetworkConfigurationHandler.

chromeos/network/network_profile_observer.h

+// Copyright (c) 2013 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 CHROMEOS_NETWORK_NETWORK_PROFILE_OBSERVER_H_
+#define CHROMEOS_NETWORK_NETWORK_PROFILE_OBSERVER_H_
+
+#include <string>
+
+#include "base/basictypes.h"
+#include "chromeos/network/network_profile.h"
+
+namespace chromeos {
+
+struct NetworkProfileState;
+
+class NetworkProfileObserver {
+ public:
+  NetworkProfileObserver() {}
+  virtual ~NetworkProfileObserver() {}

[stevenjb, 2013/04/26 21:00:49]

nit: these could be protected instead of using DISALLOW... (a bit cleaner for
pure virtual observer classes)

[pneubeck (no reviews), 2013/04/29 18:05:51]

We should keep it consistent with other observers, e.g.
NetworkStateHandlerObserver.

I'd prefer using the macro, instead of forgetting to private-ing the copy or
assignment operator.

[stevenjb, 2013/04/30 17:42:47]

NetworkStateHandlerObserver is not a pure virtual class.

If you use DISALLOW_COPY_AND_ASSIGN, then the destructor should not be inlined.
(Virtual functions, including destructors, should never be inlined. The only
exception we make is for pure interface classes, which should have a protected
inlined empty destructor).

[pneubeck (no reviews), 2013/05/03 17:32:55]

Ok. I lost you.

There are three things you mentioned:

1) Protect ctor/dtor instead of DISALLOW...

Declaring a non-public default constructor doesn't influence the implicitly
defined copy ctor and assignment operator.
So I don't understand that point.

2) Declaring the ctor protected

Doesn't change anything, this class is abstract.

3) Declaring the dtor protected

Would prevent polymorphic destruction of NetworkProfileObserver, which I think
should be fine.
Done.

4) Not inlining the destructor

The reason for not inlining the destructor, according to the styleguide, is that
there could be a surprising amount of implicit work hidden or it might increase
the number of includes. Both is apparently not the case here. There was also
some discussion on some mailinglist:
https://groups.google.com/a/google.com/forum/#!search/destructor$20inline/c-s...

Since not-inlining the destructor here leads to overhead for the reader and even
more boiler-plate, I'd prefer keeping it inlined.

+
+  virtual void OnProfileAdded(const NetworkProfile& profile) = 0;
+  virtual void OnProfileRemoved(const NetworkProfile& profile) = 0;
+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(NetworkProfileObserver);
+};
+
+
+}  // namespace chromeos
+
+#endif  // CHROMEOS_NETWORK_NETWORK_PROFILE_OBSERVER_H_