Есть ли будущее у DELPHI?
 |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [216.73.216.218] |
|
|
Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
| Страницы: (245) « Первая ... 223 224 [225] 226 227 ... 244 245 ( Перейти к последнему сообщению ) |
Есть ли будущее у DELPHI?
|
Сообщ.
#3361
,
|
|
  |
Цитата --Ins-- @ Нет, по моей логике я просто выбрал для них более простую реализацию с меньшим количеством ограничений для конечного пользоваеля моего класса. Откуда выбрал? Тебе в делфи выбора не предоставляют судя по всему, тебе навязывают одну идеологию со своими ограничениями, и уже исходя из этого ты извращаешься. Цитата --Ins-- @ Он будет как и раньше вызывать конструктор, не зная что под капотом там работает полиморфизм  А почему в случае с С++ ты думаешь что придется городить фабрику? У себя ты сделал так, потому что по другому будет проблемно. В С++ можно и фабрикой сделать, а можно просто завести шаблонный сеттер, который будет устанавливать значение переменной в наследниках, можно вообще его сделать статическим и в отрыве от класса пользоваться этим. Так что кажущееся под капотом на делфи, на самом деле навязаное насильно. |
|
Сообщ.
#3362
,
|
|
 |
Цитата Wound @ Откуда выбрал? Тебе в делфи выбора не предоставляют судя по всему, тебе навязывают одну идеологию со своими ограничениями, и уже исходя из этого ты извращаешься. Киля, выбор у меня то как раз есть, это у тебя нет  Фабрика классическая в Delphi делается так же как и в плюсах, если даже не легче с учетом наличия классовых ссылок |
|
Сообщ.
#3363
,
|
|
|
|
Цитата --Ins-- @ Киля, выбор у меня то как раз есть, это у тебя нет Ну а обосновать то можно, почему у меня выбора нет? Цитата --Ins-- @ Фабрика классическая в Delphi делается так же как и в плюсах, если даже не легче с учетом наличия классовых ссылок Так причем тут фабрика? А без фабрики? |
|
Сообщ.
#3364
,
|
|
|
|
Цитата --Ins-- @ Можно. У базового класса есть какое-либо поле, оно нужно в именно этом классе, т.к. его методы к нему обращаются. Значение этого поля у разных потомков должно быть различным, т.е. создать его в конструкторе нашего базового - нельзя, это нужно делегировать потомкам. Более того, его может быть придется не только создать, но и проинициализировать тоже по-разному, например если это контейнер - заполнить его значениями и т.д. Используя полиморфное конструирование я сделаю в конструкторе вызов MyField := CreateMySuperPuperField(); - где последний - виртуальный абстрактный метод. Без этого тебе придется городить фабрику и обязать клиентов создавать экземпляры только с помощью фабрик. А у меня сам конструктор - это фабрика А можно что-то менее абстрактное, а то не очень понятно, что мешает передавать значение поля в конструктор базового класса. |
|
Сообщ.
#3365
,
|
 |
Цитата --Ins-- @ Можно. У базового класса есть какое-либо поле, оно нужно в именно этом классе, т.к. его методы к нему обращаются. Значение этого поля у разных потомков должно быть различным, т.е. создать его в конструкторе нашего базового - нельзя, это нужно делегировать потомкам. Более того, его может быть придется не только создать, но и проинициализировать тоже по-разному, например если это контейнер - заполнить его значениями и т.д. Используя полиморфное конструирование я сделаю в конструкторе вызов MyField := CreateMySuperPuperField(); - где последний - виртуальный абстрактный метод. Без этого тебе придется городить фабрику и обязать клиентов создавать экземпляры только с помощью фабрик. А у меня сам конструктор - это фабрика И зачем тут фабрика? |
|
Сообщ.
#3366
,
|
|
|
|
Цитата D_KEY @ А можно что-то менее абстрактное, а то не очень понятно, что мешает передавать значение поля в конструктор базового класса. Хм, в принципе ты наверное прав. Но впрочем я об этом тоже говорил: Цитата --Ins-- @ И там, где ты начнешь плодить фабрики или приватные конструкторы с кучей параметров, я запилю один виртуальный метод |
|
Сообщ.
#3368
,
|
|
|
|
Цитата --Ins-- @ Хм, в принципе ты наверное прав. Но впрочем я об этом тоже говорил: Что мешает сделать тоже в С++(я имею ввиду обойтись одним методом, а не фабрикой) ? Непонятна твоя логика просто. Толи ты считаешь что в С++ твой пример только на фабриках можно написать и никак иначе, толи ты не совсем знаешь С++, но тогда зачем так уверено заявлять то, в чем не разбираешься? |
|
|
Сообщ.
#3369
,
|
|
|
Цитата --Ins-- @ Но впрочем я об этом тоже говорил: И чем этот один метод отличается от того одного протектед-конструктора? |
|
Сообщ.
#3370
,
|
 |
Цитата --Ins-- @ У базового класса есть какое-либо поле, оно нужно в именно этом классе, т.к. его методы к нему обращаются. Значение этого поля у разных потомков должно быть различным, т.е. создать его в конструкторе нашего базового - нельзя, это нужно делегировать потомкам. Более того, его может быть придется не только создать, но и проинициализировать тоже по-разному, например если это контейнер - заполнить его значениями и т.д. Раз должны его инициализировать потомки, то пускай они это и делают. В чем проблема? |
|
Сообщ.
#3371
,
|
|
|
|
Цитата korvin @ И чем этот один метод отличается от того одного протектед-конструктора? В принципе согласен, пример не самый удачный. Но в delphi таки отличается - там конструкторы наследуются (что удобно), а иметь в потомке такой конструктор - излишне. Поэтому для реалий Delphi такой подход с виртуальным методом более приемлим. Добавлено Цитата OpenGL @ то пускай они это и делают. В чем проблема? Не, ты может еще поле неприватным ради этого сделаешь? Потомок не должен заниматься инициализацией полей своих предков. Но в принципе меня убедили, это действительно можно решать параметризированным конструктором, они же не наследуются у вас, так что страшного мало |
|
|
Сообщ.
#3372
,
|
|
|
Цитата --Ins-- @ Потомок не должен заниматься инициализацией полей своих предков. Так по-факту он у тебя этим и занимается. |
|
Сообщ.
#3373
,
|
|
|
|
Цитата --Ins-- @ Но в принципе меня убедили, это действительно можно решать параметризированным конструктором, они же не наследуются у вас, так что страшного мало Хотя... Если это поле - это не число. Если это List, который потомок должен не только создать, но и положить туда пару элементов. Как это сделать, не делая поле publiс/protected или геттеров к нему только лишь специально ради этого? Добавлено Цитата OpenGL @ Так по-факту он у тебя этим и занимается. Нет, он просто его создает и возвращает предку |
|
Сообщ.
#3374
,
|
|
 |
Цитата --Ins-- @ Если это List, который потомок должен не только создать, но и положить туда пару элементов. Как это сделать, не делая поле publiс/protected или не геттеров к нему только лишь специально ради этого? Смотри мой пример. |
|
Сообщ.
#3375
,
|
|
|
|
Цитата --Ins-- @ Цитата OpenGL @ Так по-факту он у тебя этим и занимается. Нет, он просто его создает и возвращает предку Цитата --Ins-- @ Более того, его может быть придется не только создать, но и проинициализировать тоже по-разному |
0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
0 пользователей:
[ Script execution time: 0,1938 ] [ 15 queries used ] [ Generated: 20.07.25, 13:52 GMT ]