网站建设实质,wordpress带采集,品牌网站建设公司哪好,深圳市网是科技有限公司想象有个class用来表示网页浏览器。这样的class可能提供的众多函数中#xff0c;有一些用来清除下载元素高速缓存区#xff08;cache of downloaded elements#xff09;、清除访问过的URLs的历史记录#xff08;history of visited URLs#xff09;、以及移除系统中的所有…想象有个class用来表示网页浏览器。这样的class可能提供的众多函数中有一些用来清除下载元素高速缓存区cache of downloaded elements、清除访问过的URLs的历史记录history of visited URLs、以及移除系统中的所有cookies
class WebBrowser
{
public:// ...void clearCache();void clearHistory();void removeCookies();// ...
};许多用户会想一整个执行所有这些动作因此WebBrowser也提供这样一个函数
class WebBrowser
{
public:// ...void clearEverything(); // 调用clearCache、clearHistory、removeCookies// ...
};当然这一机能也可由一个non-member函数调用适当的member函数而提供出来
void clearBrowser(WebBrowser wb)
{wb.clearCache();wb.clearHistory();wb.removeCookies();
}那么哪一个比较好呢是member函数clearEverything还是non-member函数clearBrowser
面向对象守则要求数据以及操作数据的那些函数应该被捆绑在一块这意味它建议member函数是较好的选择。不幸的是这个建议不正确。这是基于对面向对象真实意义的一个误解。面向对象守则要求数据应该尽可能被封装然而与直观相反地member函数clearEverything带来的封装性比non-member函数clearBrowser低。此外提供non-member函数可允许对WebBrowser相关机能有较大的包裹弹性packaging flexibility而那最终导致较低的编译相依度增加WebBrowser的可延伸性。因此在许多方面non-member做法比member做法好。重要的是我们必须了解其原因。
让我们从封装开始讨论。如果某些东西被封装它就不再可见。愈多东西被封装愈少人可以看到它。而愈少人看到它我们就有愈大的弹性去变化它因为我们的改变仅仅直接影响看到改变的那些人事物。因此愈多东西被封装我们改变那些东西的能力也就愈大。这就是我们首先推崇封装的原因它使我们能够改变事物而只影响有限客户。
现在考虑对象内的数据。愈少代码可以看到数据也就是访问它愈多的数据可被封装而我们也就愈能自由地改变对象数据例如改变成员变量的数量、类型等等。如何量测“有多少代码可以看到某一块数据”呢我们计算能够访问该数据的函数数量作为一种粗糙的量测。愈多函数可访问它数据的封装性就愈低。
条款22曾说过成员变量应该是private因为如果它们不是就有无限量的函数可以访问它们它们也就毫无封装性。能够访问private成员变量的函数只有class的member函数加上friend函数而已。如果你要在一个member函数它不只可以访问class内的private数据也可以取用private函数、enums、typedefs等等和一个non-member non-friend函数它无法访问上述任何东西之间做抉择而且两者提供相同机能那么导致较大封装性的是non-member non-friend函数因为它并不增加“能够访问class内之private成分”的函数数量。这就解释了为什么clearBrowser一个non-member non-friend函数比clearEverything一个member函数更受欢迎的原因它导致WebBrowser class有较大的封装性。
在这一点上有两件事情值得注意。第一这个论述只适用于non-member non-friend函数。friend函数对class private成员的访问权力和member函数相同因此两者对封装的冲击力道也相同。从封装的角度看这里的选择关键并不在member和non-member函数之间而是在member和non-member non-friend函数之间当然封装并非唯一考虑条款24解释当我们考虑隐式类型转换应该在member和non-member函数之间抉择。
第二件值得注意的事情是只因在意封装性而让函数“成为class的non-member”并不意味着它“不可以是另一个class的member”。这对那些习惯于“所有函数都必须定义于class内”的语言如Eiffel、Java、C#的程序员而言可能是个温暖的慰藉。例如我们可以令clearBrowser成为某工具类utility class的一个static member函数。只要它不是WebBrowser的一部分或成为其friend就不会影响WebBrowser的private成员封装性。
在C比较自然的做法是让clearBrowser成为一个non-member函数并且位于WebBrowser所在的同一个namespace命名空间内
namespace WebBrowserStuff
{class WebBroser{// ...};void clearBrowser(WebBrowser wb);// ...
}然而这不只是为了看起来自然而已。要知道namespace和class不同前者可以跨越多个源码文件而后者不能。这很重要因为像clearBrowser这样的函数是个“提供便利的函数”如果它既不是member也不是friend就没有对WebBrowser的特殊访问权力也就只能提供“WebBrowser客户以其他方式也能取得”的机能。举个例子如果clearBrowser不存在客户端就只好自行调用clearCache、clearHistory、removeCookies。
一个像WebBrowser这样的class可能拥有大量便利函数某些与书签bookmarks有关某些与打印有关还有一些与cookies的管理有关……通常大多数客户只对其中某些感兴趣。没道理一个只对书签相关便利函数感兴趣的客户却与例如一个cookie相关便利函数发生编译相依关系。分离它们的最直接做法就是将书签相关便利函数声明于一个头文件将cookie相关便利函数声明于另一个头文件再将打印相关便利函数声明于第三个头文件依此类推
// 头文件“webbrowser.h”——这个头文件针对class WebBrowser自身及WebBrowser核心机能
namespace WebBrowserStuff
{class WebBrowser{// ...};// ... 核心机能例如几乎所有客户都需要的non-member函数
}// 头文件“webbrowserbookmarks.h”
namespace WebBrowserStuff
{// ... 与书签相关的便利函数
}// 头文件“webbrowsercookies.h”
namespace WebBrowserStuff
{// ... 与cookie相关的便利函数
}
// ...注意这正是C标准库的组织方式。标准程序库并不是拥有单一、整体、庞大的CStankardLibrary头文件并在其中内含std命名空间内的每一样东西而是有数十个头文件vector、algorithm、memory等等每个头文件声明std的某些机能。如果客户只想使用vector相关机能他不需要#include memory如果客户不想使用list也不需要#include list。这允许客户只对他们所用的那一小部分系统形成编译相依见条款13其中讨论降低编译依存性的其他做法。以此种方式切割机能并不适用于class成员函数因为一个class必须整体定义不能被分割为片片段段。
将所有便利函数放在多个头文件内但隶属同一个命名空间意味客户可以轻松扩展这一组便利函数。他们需要做的就是添加更多non-member non-friend函数到此命名空间内。举个例子如果某个WebBrowser客户决定写些与影像下载相关的便利函数他只需要在WebBrowserStuff命名空间内建立一个头文件内含那些函数的声明即可。新函数就像其他旧有的便利函数那样可用且整合为一体。这是class无法提供的另一个性质因为class定义式对客户而言是不能扩展的。当然客户可以派生出新class但derived class无法访问base class中被封装的即private成员于是如此的“扩展机能”拥有的只是次级身份。此外一如条款7所说并非所有class都被设计用来作为base class。
请记住 宁可拿non-member non-friend函数替换member函数。这样做可以增加封装性、包裹弹性和机能扩充性。
