diff options
| author | gab@chromium.org <gab@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-05-20 05:30:17 +0000 |
|---|---|---|
| committer | gab@chromium.org <gab@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-05-20 05:30:17 +0000 |
| commit | f2068f96d7d4c14f3e10d5926eb49074d7e64f44 (patch) | |
| tree | 367f6c1e48734db9748563c309993dafb1842cfa /chrome/browser/chrome_browser_main.cc | |
| parent | c75ba52431a005504602023a4cdfb910356a95ca (diff) | |
| download | chromium_src-f2068f96d7d4c14f3e10d5926eb49074d7e64f44.zip chromium_src-f2068f96d7d4c14f3e10d5926eb49074d7e64f44.tar.gz chromium_src-f2068f96d7d4c14f3e10d5926eb49074d7e64f44.tar.bz2 | |
Refactor BrowserProcessPlatformPart.
The previous design was to have a class, BrowserProcessPlatformPart, which has various implementations for specific platforms and a common implementation for all other platforms. These implementations (e.g., browser_process_platform_part_(chromeos|aurawin).h) both implement the common methods defined in the common implementation (browser_process_platform_part.h) and some methods specific to their platform.
The main problem with this design is that each custom implementation needs to re-implement the default behavior even for the methods for which the base implementation would have been fine (since it's a compile-time choice and doesn't use inheritance).
This will become worst as more common methods get added to the base BrowserProcessPlatformPart, forcing every custom implementation to provide a copy of the default implementation for that method...
The previous design also forces ugly #if ... #elif ... #elif ... #else ...#endif style of includes just to use the common methods since all headers, but one, are discarded by gyp.
This will become worst as more platforms need custom BrowserProcessPlatformPart.
Both scenarios making this worst are happening as part of addressing https://codereview.chromium.org/14576015/diff/43017/chrome/browser/lifetime/application_lifetime.cc#newcode116 where adding a common call to BrowserProcessPlatformPart and using it to get rid of the ifdefs there implies one more common call and 2 more platforms.
With the new design:
There is a common base class which platform-specific implementation override as desired.
The #ifdef include-mess is dealt with by having a meta-include in browser_process_platform_part.h which knows which impl to include at compile-time.
This is a precursor CL to https://codereview.chromium.org/14576015
BUG=235648, 232842, 179830
Review URL: https://chromiumcodereview.appspot.com/14951007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201028 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/chrome_browser_main.cc')
| -rw-r--r-- | chrome/browser/chrome_browser_main.cc | 7 |
1 files changed, 1 insertions, 6 deletions
diff --git a/chrome/browser/chrome_browser_main.cc b/chrome/browser/chrome_browser_main.cc index fd61600..4fb44533 100644 --- a/chrome/browser/chrome_browser_main.cc +++ b/chrome/browser/chrome_browser_main.cc @@ -40,6 +40,7 @@ #include "chrome/browser/about_flags.h" #include "chrome/browser/browser_process.h" #include "chrome/browser/browser_process_impl.h" +#include "chrome/browser/browser_process_platform_part.h" #include "chrome/browser/browser_shutdown.h" #include "chrome/browser/chrome_browser_main_extra_parts.h" #include "chrome/browser/component_updater/component_updater_service.h" @@ -179,12 +180,6 @@ #include "ui/base/win/dpi.h" #endif // defined(OS_WIN) -#if defined(OS_WIN) && defined(USE_AURA) -#include "chrome/browser/browser_process_platform_part_aurawin.h" -#else -#include "chrome/browser/browser_process_platform_part.h" -#endif - #if defined(OS_MACOSX) #include <Security/Security.h> |