C++.Coding.Standards.1918.Rules.Guidelines [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

C++.Coding.Standards.1918.Rules.Guidelines [Electronic resources] - نسخه متنی

Herb Sutter, Andrei Alexandrescu

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید


Examples


Example 1: Proper encapsulation.
Most classes (e.g.,

Matrix, File, Date, BankAccount, Security ) should have all private data members and expose adequate interfaces. Allowing calling code to manipulate their internals directly would directly work against the abstraction they provide and the invariants they must sustain.

A

Node aggregate, as commonly used in the implementation of a

List class, typically contains some data and two pointers to

Node:next_ and

prev_.Node 's members don't need to be hidden from

List . But now consider Example 3.

Example 2:

treeNode.
Consider a

TRee<T> container implemented in terms of

treeNode<T> , an aggregate used within

TRee that holds previous//pointers and a

T object payload.

treeNode 's members can all be public because they don't need to be hidden from

TRee , which directly manipulates them. But

tree should hide

treeNode altogether (e.g., as a private nested class, or defined only in

tree 's implementation file), because it is an internal detail of

tree that callers shouldn't depend on or manipulate. Finally,

TRee does

not hide the contained

T objects, because the payload is the caller's responsibility; containers use the iterator abstraction to expose the contained objects while hiding internal structures.

Example 3: Getters and setters.
If there is no better domain abstraction available, public and protected data members (e.g.,

color ) can at least be made private and hidden behind get and set functions (e.g.,

GetColor, SetColor ); these provide a minimal abstraction and robust versioning.

Using functions raises the level of discourse about "color" from that of a concrete state to that of an abstract state that we are free to implement as we want: We can change to an internal color encoding other than

int , add code to update the display when changing color, add instrumentation, and make many other changes without breaking calling code. At worst, callers just recompile (i.e., we preserve source-level compatibility); at best, they don't have to recompile or relink at all (if the change also preserves binary compatibility). Neither source nor binary compatibility is possible for such changes if the starting design has a public

color member variable to which calling code becomes tightly coupled.


/ 521