вопросы о статье, представляющей интерфейс C++
Я читал статью об интерфейсах C++ (http://accu.org/index.php/journals/233), и я полностью потерян в части, где она говорит, что все виртуальные функции членства должны быть сделаны частными (раздел, названный, "Усилив Разделение"). Это просто не имеет смысла мне вообще.
По словам автора, код похож на это:
class shape {
public:
virtual ~shape();
virtual void move_x(distance x) = 0;
virtual void move_y(distance y) = 0;
virtual void rotate(angle rotation) = 0;
//...
};
class line : public shape {
public:
line(point end_point_1, point end_point_2);
//...
private:
virtual ~line();
virtual void move_x(distance x);
virtual void move_y(distance y);
virtual void rotate(angle rotation);
//...
};
Таким образом, у нас есть чистая виртуальная функция, которая общедоступна, и ее реализация (в классе строки), который является частным.
Кто-либо мог объяснить, как функция move_x может быть вызвана? Его спецификатор доступа является частным, он приведет к ошибке, если я попытаюсь сделать это:
line my_line(point(0,0), point(1,2));
my_line.move_x(-1); // does not compile
Так же это корректно, чтобы сказать что интерфейс рисунка (см. ранее в статье), не может получить доступ к этим функциям также?
Спасибо.
4 ответа
Идея в том, что вы D Используйте эти методы через ссылку или указатель на форму .
shape &s = my_line;
s.move_x(-1);
Это может быть оправдано на том основании «выявить только то, что вам нужно», или как форма самоподокументации. Это доказывает, что методы вызываются только по направлению.
Я думаю, что статья хорошо подчеркивает обоснование в этой цитате:
Теперь единственное, что пользователи могут сделать с линия создает экземпляры этого. Все Использование должно быть через его интерфейс - то есть. Форма, таким образом, соблюдая сильнее Разделение интерфейса / внедрения. Прежде чем выйти из этой темы, это важно получить что-то прямо: точка соблюдения Разделение интерфейса / внедрения Не говорить пользователям, что делать. Скорее, цель - лежать Логическое разделение - код сейчас объясняет, что ключ абстракции форма, и эта линия служит для обеспечения реализация формы.
То есть линия не сама по себе интересно. Это просто реализация формы , и могут быть другие реализации. Вы особенно заинтересованы в форме , интерфейс . Следовательно, вы должны получить доступ только к реализации через этот интерфейс, а не как автономный класс.
Если вы имеете в применении объекта объекта, вы можете быть соблазнены называть его методами. Но если единственный способ, которым вы можете получить на них, это спрашивая его интерфейс , то объект выглядит меньше, как объект и больше похоже на коллекцию интерфейсов.
Это имеет больше смысла, если вы представляете линию, реализующую более одного интерфейса.
Я думаю, что статья подчеркивает обоснование хорошо в этой цитате:
сейчас, единственное, что пользователи могут сделать с линия создает экземпляры этого. Все Использование должно быть через его интерфейс - то есть. Форма, таким образом, соблюдая сильнее Разделение интерфейса / внедрения. Прежде чем выйти из этой темы, это важно получить что-то прямо: точка соблюдения Разделение интерфейса / внедрения Не говорить пользователям, что делать. Скорее, цель - лежать Логическое разделение - код сейчас объясняет, что ключ абстракции форма, и эта линия служит для обеспечения реализация формы.
То есть линия не сама по себе интересно. Это просто реализация формы , и могут быть другие реализации. Вы особенно заинтересованы в интерфейсе в форме . Следовательно, вы должны получить доступ только к реализации через этот интерфейс, а не как автономный класс.
Одноядерный?
Сколько памяти?
Находится ли дисплей в буфере памяти и помещается ли он на устройство или является единственной копией пикселей в памяти экранов?
-121--1870611-Обязательный Гуава однолайнер:
boolean isAnagram(String s1, String s2) {
return ImmutableMultiset.copyOf(Chars.asList(s1.toCharArray())).equals(ImmutableMultiset.copyOf(Chars.asList(s2.toCharArray())));
}
(Просто для развлечения. Я не рекомендую отправлять это для вашего назначения.)
-121--2872811- Этот совет применим только к однородным иерархиям - т.е. иерархиям, в которых производные классы не вводят новых функций (за исключением конструкторов) и просто переопределяют функции базового класса. В этом случае вам, очевидно, не нужно работать с экземпляром line напрямую - только через указатель/ссылку на shape .
Когда у вас менее однородная иерархия, этот совет не имеет большого смысла: как бы кто-либо применил ее к случаям, когда производный класс вводит новые функции или наследует их от другого базового класса? В этом случае иногда требуется непосредственно работать с объектами производного класса, и этот совет может привести только к неудобствам.
Дальнейшее развитие этой идеи - менее радикальной и пригодной для использования в большем количестве контекстов - Невиртуальный интерфейс (NVI) Херба Саттера.