Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Переименуйте методы, очень тяжело читать всякие f,g,h
может стоит назвать protected_method, private_method, public_method или еще как.
может стоит назвать protected_method, private_method, public_method или еще как.
Вопрос знатокам, что есть единицей инкапсуляции в Delphi? Если бы не то свойство, что приватные свойства класса можно дергать не только из экземпляров этого класса, но и из любого места модуля, в котором он определен, то можно было бы предположить, что единцей инкапсуляции является класс, но похоже что все-таки модуль, что странно, поскольку свойства и методы инапсулируются именно в класс.
Delphi 7 спокойно компилирует этот код, и считает что в нем нет ошибок.
unit Unit2;
interface
type
TSomeClass = Class
private
x : integer;
end;
var
foo : TSomeClass;
implementation
initialization
foo := TSomeClass.Create;
foo.x := 10;
foo.free;
end.
Delphi 7 спокойно компилирует этот код, и считает что в нем нет ошибок.
до появления strict private — модуль. в тех версиях где есть strict private — аналогично плюсам
Говоря о том, что было до strict private, есть 2 нюанса, которые говорят о том, что все-таки не модуль является единицей инкапсуляции:
1. Приватный метод класса можно вызвать из другого модуля (например, посредством перегрузки (override) метода с другой областью видимости)
2. Синтаксически и семантически свойства и методы инкапсулируются в класс.
1. Приватный метод класса можно вызвать из другого модуля (например, посредством перегрузки (override) метода с другой областью видимости)
2. Синтаксически и семантически свойства и методы инкапсулируются в класс.
есть 2 нюанса, которые говорят о том, что все-таки не модуль является единицей инкапсуляции:
1. Приватный метод класса можно вызвать из другого модуля (например, посредством перегрузки (override) метода с другой областью видимости)
это говорит только о том, что класс не инкапсулирует свои private члены. Модуль же инкапсулирует все, что находится под implementation. Помести туда класс и никто извне модуля не сможет к нему доступ иметь.
2. Синтаксически и семантически свойства и методы инкапсулируются в класс.
а синтаксис — это не важно. Важно только то, какая сущность способна ограничить доступ к своим членам извне. для младших дельфей — это модуль.
1. Приватный метод класса можно вызвать из другого модуля (например, посредством перегрузки (override) метода с другой областью видимости)
это говорит только о том, что класс не инкапсулирует свои private члены. Модуль же инкапсулирует все, что находится под implementation. Помести туда класс и никто извне модуля не сможет к нему доступ иметь.
2. Синтаксически и семантически свойства и методы инкапсулируются в класс.
а синтаксис — это не важно. Важно только то, какая сущность способна ограничить доступ к своим членам извне. для младших дельфей — это модуль.
Как говорится… И чо?
Ваш вопрос «И чо?» задают новички C++ компилятору, когда последний пишет «Base::f() is protected» на строку (3), потому что новички думают о protected как о том, что написано в 15.3 у Строуструпа (см. пост)
Приведите пример, когда новичку в принципе может понадобиться так писать. Доступ к private/protected членам объекта того же типа дан был не для того.
Ну, например, я видел такой код, написанный опытным программистом на C, новичком C++:
Собственно, исправляя этот код я и написал пост.
Очевидно, что он просто ошибся в типе b: нужно было написать просто Derived* b = new Derived; (кстати,
такая ошибка произошла тоже по понятным причинам, но это уже за рамками поста)
Дальше он не понял, почему компилятор ругался на вызов b->Create() и попросту добавил Derived в друзья Base
class Base {
friend class Derived;
protected:
Base* Create();
};
class Derived : public Base {
public:
Base* CreateBase() {
Base* b = new Derived;
return b->Create();
}
};
Собственно, исправляя этот код я и написал пост.
Очевидно, что он просто ошибся в типе b: нужно было написать просто Derived* b = new Derived; (кстати,
такая ошибка произошла тоже по понятным причинам, но это уже за рамками поста)
Дальше он не понял, почему компилятор ругался на вызов b->Create() и попросту добавил Derived в друзья Base
Спагетти какое-то, ей-богу. Новичкам я бы вообще не разрешал использовать protected.
Пусть лучше дальше пишет на чистом Си. Вы его ещё спецификациями шаблонов напугайте и RTTI.
шаблоны и касты кроме C-style в этом проекте запрещены
А когда вы пишете на Си то вы заставляете разработчиков называть все переменные только идентификаторами с чётным числом символов? Откуда это необоснованное желание писать на каком-то вымышленном подмножестве языка?
я никого не заставляю ни в этом проекте, ни в других. о данных конкретных запретах не высказываю никакой своей точки зрения. но вообще-то code style и projects restrictions — это обычная практика и тоже, фактически, приводит к формированию подмножеств языков. например, запрет на использование вещественных чисел может быть вполне обоснован для некоторых проектов. так что само по себе программирование на подмножестве — это не плохо.
Я бы хотел уточнить. Пример кода не прямо скопирован из проекта, а воссоздан аналог, и в оригинале семантика не создания — Create(), а заполения класса Base из файла, при этом Derived — парсит файл, а Base — загружает в объект распарсеные значения. Так что если возникло ощущение, что очень сложно происходит создание, что код перенасыщен спагетти — то это уже моя вина: я написал первое пришедшее на ум имя функции Create(), потому что не думал об имени, а думал о том, какая функция какую вызывает. Здесь сразу несколько слоев ошибок. Самое главное, что между Base и Derived не должно быть наследования: должна быть композиция. Соответственно, нечего делать protected в классе Base. Но я хотел заострить внимание на проблемах более низкоуровневых, которые появляются если приведенную архитектуру считать данностью. Плохая архитектура — яма в которой человек сидит, у него три пути: выйти из ямы, остаться на месте и закопаться еще глубже. Первый путь не возможен по не зависящим от него причинам, скажем так, запрещен. Из двух оставшихся он выбирает последний, потому что по не знанию инструмента (языка), фактически делает движения вслепую. А если бы знал — мог бы остаться, не закапываясь глубже :)
Очередной теоретик программирования. Может уже программы будем писать эффективно, а не «правильно». Хотя топик создать — не мешки ворочать. Проще всего сослаться на некий авторитет после прочтения некой книги, куда проще чем создать годный продукт, который всем нужен.
одно другому не мешает. а иногда даже наоборот
Желание сделать всегда и везде код «правильно» гарантированно не помешает наваять архитектурного монстра, вместо того чтобы сделать всё просто и эффективно.
С опытом приходит понимание, что «эффективно» и «правильно» — это одно и то же.
Дело в том, что эффективно и правильно — это разные понятия, а «эффективно» и «правильно» — это по сути одинаково неэффективно и неправильно. Понимание правильного действительно приходит с опытом, и приводить в качестве аргумента книгу не есть хорошо, её даже понять прочитав можно сильно по-разному в зависимости от зрелости и понимания.
Данный топик поможет вам осознать, что класс — единица инкапсуляции. Замечательно. Где профит?
Данный топик поможет вам осознать, что класс — единица инкапсуляции. Замечательно. Где профит?
> Строка (4) демонстрирует, что вторая часть утверждения о единице инкапсуляции обходится проще, чем первая
Эта строка демонстрирует undefined behavior, а не то что вы написали.
Эта строка демонстрирует undefined behavior, а не то что вы написали.
> Строка (4) демонстрирует, что вторая часть утверждения о единице инкапсуляции обходится проще, чем первая
Эта строка демонстрирует что автору надо руки оторвать. Лучше бы запретил даункасты вместо шаблонов, а если и делаешь даункаст то делай правильно, посредством динамик каста.
Эта строка демонстрирует что автору надо руки оторвать. Лучше бы запретил даункасты вместо шаблонов, а если и делаешь даункаст то делай правильно, посредством динамик каста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В C++ единицей инкапсуляции является класс