-
Kernel3: Все сообщения за 10 Декабря 2007 года
| Пн | Вт | Ср | Чт | Пт | Сб | Вс |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |
Дык, проблема не в наличии коммуникатора (лично держал такой в руках, находясь в Москве), а в отсутсвии соответствующего сервиса, предоставляемого операторами сотовой связи. А его как не было, так в ближайшем будущем и не предвидится 
В отличии от той же Украины.
Хотя, раз ввозят МТС и "Вымпелком" - значит, таки собираются делать...
В отличии от той же Украины.Хотя, раз ввозят МТС и "Вымпелком" - значит, таки собираются делать...
Broken Windows® cures my ills and makes me feel alright... ©
инфо
инструменты
Сергей-4030> А где отличие от C++? Единственный минус фабрик, который я вижу: один лишний вызов функции. Это может быть проблемой иногда, как в С++ так и в Джаве, но обычно это не проблема. Конечно, и лишнее создание объекта часто не проблема. Но контролировать создание объекта как минимум не хуже, а в случаях, когда создание объекта - процесс очень затратный, так просто много лучше.
Отличие С++ в количестве временных объектов, возникающих в реальных приложениях.
Отличие С++ в количестве временных объектов, возникающих в реальных приложениях.
Broken Windows® cures my ills and makes me feel alright... ©
Kernel3>> Отличие С++ в количестве временных объектов, возникающих в реальных приложениях.
Сергей-4030> И в чем же именно это отличие?
Цифры? 
Какие цыфры? Количество объектов? Вечером дам пример кода со своей предыдущей работы - сами прикинете. Пока же просто напишу своё ХО, что явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным.
Сергей-4030> И в чем же именно это отличие?
Цифры? Какие цыфры? Количество объектов? Вечером дам пример кода со своей предыдущей работы - сами прикинете. Пока же просто напишу своё ХО, что явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным.
Broken Windows® cures my ills and makes me feel alright... ©
Kernel3>> Какие цыфры? Количество объектов? Вечером дам пример кода со своей предыдущей работы - сами прикинете. Пока же просто напишу своё ХО, что явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным.
Сергей-4030> Чего?!
Вы точно поняли, про что топик?
Да нет, конечно, я случайно зашёл. Куда уж нам до сурьёзных людей с сурьёзными мыслями, боящихся перегрузки операторов и публичных конструкторов.
Сергей-4030> Чего?!
Вы точно поняли, про что топик? Да нет, конечно, я случайно зашёл. Куда уж нам до сурьёзных людей с сурьёзными мыслями, боящихся перегрузки операторов и публичных конструкторов.
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Я не пытаюсь вас обидеть, мне просто непонятно, как из наличия factories можно сделать такие глобальные выводы про бессмысленность ООП. Вы бы расшифровали, в чем именно проблема. Я на самом деле не понимаю.
Надеюсь, станет понятнее после примера кода. Грубо говоря, если вместо 5 строчек кода придётся каждый раз писать 20, то непонятно, а на хрена, собственно, нужно всё это абстрагирование. Бо на голых Сях получится примерно то же самое.
Надеюсь, станет понятнее после примера кода. Грубо говоря, если вместо 5 строчек кода придётся каждый раз писать 20, то непонятно, а на хрена, собственно, нужно всё это абстрагирование. Бо на голых Сях получится примерно то же самое.
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Да-да. А еще мы, серьезные люди, боимся гоуту и вообще - программирования спагетти. По своей ограниченности. Гоуту - в массы, долой предрассудки!
Разумеется. А вы знаете способ проще, выйти из вложенных циклов? (Только не говорите, что вы их не пишете)
А еще мы, серьезные люди, боимся гоуту и вообще - программирования спагетти. По своей ограниченности. Гоуту - в массы, долой предрассудки!Разумеется. А вы знаете способ проще, выйти из вложенных циклов? (Только не говорите, что вы их не пишете)
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Как это вам придется такие ужасы писать? Вызов фактори - та же одна строчка. И все-таки, что именно подрывает сами устои ООП? Вы писали, что "явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным" - разъясните этот фрагмент. Какое именно явное создание и почему оно делает ООП бессмысленным?
Вызов фактори - это одна строчка для каждого временного объекта. Что непонятно?
Вызов фактори - та же одна строчка. И все-таки, что именно подрывает сами устои ООП? Вы писали, что "явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным" - разъясните этот фрагмент. Какое именно явное создание и почему оно делает ООП бессмысленным?Вызов фактори - это одна строчка для каждого временного объекта. Что непонятно?
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Естественно, знаю. А вы не знаете? Я вам подскажу: есть такие ключевые слова break и continue.
Если бы у break и continue можно было указать количество циклов, которые нужно продолжить/прекратить, тогда да.
Сергей-4030> Иногда очень удобно использовать также return.
Ага. Но отрицая гоуту очень легко прийти к концепции единственного выхода у функции. ПМСМ, из той же серии заморочки
Сергей-4030> А кое-где есть еще break с меткой.
А вот с этого места поподробнее, пожалуйста
А вы не знаете? Я вам подскажу: есть такие ключевые слова break и continue.Если бы у break и continue можно было указать количество циклов, которые нужно продолжить/прекратить, тогда да.
Сергей-4030> Иногда очень удобно использовать также return.
Ага. Но отрицая гоуту очень легко прийти к концепции единственного выхода у функции. ПМСМ, из той же серии заморочки
Сергей-4030> А кое-где есть еще break с меткой.
А вот с этого места поподробнее, пожалуйста
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Я, по-моему, явно указал, что в очень некоторых случаях фактори использовать не надо. Когда создание объекта очень дешево а оверхед получается большой. Это в основном всякие временные переменные базовых типов, вроде int temp=5;
Я бы сказал, что временные переменные любых типов, если их создание дёшево.
Сергей-4030> Во всех остальных случаях фактори ничего не добавит к "сложности объявления", но сильно добавит к ясности кода и "поддерживаемости".
Ой... Давайте таки подождём примера кода?
Я бы сказал, что временные переменные любых типов, если их создание дёшево.
Сергей-4030> Во всех остальных случаях фактори ничего не добавит к "сложности объявления", но сильно добавит к ясности кода и "поддерживаемости".
Ой... Давайте таки подождём примера кода?
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Пожалуйста, никаких проблем. Вот здесь поподробнее.
О. И на каком году существования Java до создателей дошла необходимость наличия такой штуки?
О. И на каком году существования Java до создателей дошла необходимость наличия такой штуки?
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Нет. Собственно контроль создания экземпляра не единственное преимущество. Есть еще преимущество гибкости. Если у вас по всей программе указано что-то вроде Object o = new ConcreteObject(); (тысячи участков кода), то что вы будете делать, если вам когда-либо понадобится, чтобы эти Object работали с другой имплементацией?
Я, наверное, изначально напишу wrapper. И вы таки не поверите - именно с публичным конструктором для удобства использования
Я, наверное, изначально напишу wrapper. И вы таки не поверите - именно с публичным конструктором для удобства использования
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> wrapper чего? Что именно у вас будет вместо
Сергей-4030> Object o = new ConcreteObject();
Для ConcreteObject(). Вы же упомянули имплементацию? Значит, есть и интерфейс? Следовательно, будет либо использование виртуальных методов, либо прокси-объект в том или ином виде. Например, wrapper.
Сергей-4030> Да вроде как на первом. Уж точно, лет десять как уже. Для вас и это новость?
Ага. Потому как в первой точно не было
Сергей-4030> Object o = new ConcreteObject();
Для ConcreteObject(). Вы же упомянули имплементацию? Значит, есть и интерфейс?
Следовательно, будет либо использование виртуальных методов, либо прокси-объект в том или ином виде. Например, wrapper.Сергей-4030> Да вроде как на первом. Уж точно, лет десять как уже. Для вас и это новость?
Ага. Потому как в первой точно не было
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Ну вы укажите, что будет вместо Object o = new ConcreteObject(); Напишите уже код, который у вас будет в этом месте, не говорите загадками.
Не понял. Тогда уточните, что такое ConcreteObject, и что чего у вас имплементирует.
Сергей-4030> А какую именно вы почитаете "первой"? В 1.1 как раз "точно было". Не знали?
Неа, не знал. Или забыл. Приду домой - перечитаю мануал.
Не понял. Тогда уточните, что такое ConcreteObject, и что чего у вас имплементирует.
Сергей-4030> А какую именно вы почитаете "первой"? В 1.1 как раз "точно было". Не знали?
Неа, не знал. Или забыл. Приду домой - перечитаю мануал.
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Пофиг, что. Пускай будет ConcreteObject o = new ConcreteObject(); , если это проблема. Итак, что будет делать ваш wrapper с этим куском кода?
ConcreteObjectWrapper o = new ConcreteObjectWrapper(new ConcreteObject());
При изменении имплементации:
ConcreteObjectWrapper o = new ConcreteObjectWrapper(new AnotherConcreteObject());
Не самый красивый вариант, но тем не менее А чем вам здесь помогут фабрики?
ConcreteObjectWrapper o = new ConcreteObjectWrapper(new ConcreteObject());
При изменении имплементации:
ConcreteObjectWrapper o = new ConcreteObjectWrapper(new AnotherConcreteObject());
Не самый красивый вариант, но тем не менее
А чем вам здесь помогут фабрики?
Broken Windows® cures my ills and makes me feel alright... ©
Обещанный пример (выдернуто из контекста, поэтому с глупыми комментариями ) :
AutoRef<TypedRegValue> UpperFiltersEx(interface_cast<RegValue>(UpperFilters));
// Здесь будет 2 временных объекта: при вызове interface_cast ("обёртка" вокруг UpperFilters) и
// UpperFiltersEx() (типа TypedRegValue c RegValue в качестве параметра)
if (UpperFiltersEx)
{
result = UpperFiltersEx->SetValue(UpperFiltersEx->GetType(), UpperFiltersEx->GetValue() + NewUpper);
// И здесь 2: результат сложения и "обёртка" вокруг этого результата,
// приводящая его к типу второго аргумента SetValue()
}
Итого к коду из 3-х значащих строчек, по-вашему, надо добавить ещё 4. Соотношение хоть и не 5:20, но лично меня впечатляет.
Кстати, "обёртка" вокруг UpperFiltersEx->GetValue() + NewUpper называется Variant и имеет 5 конструкторов с различными типами аргумента. Что позволяет использовать его в т.ч. в качестве возвращаемого значения. Как вы собираетесь заменить эту функциональность фабриками?
) :AutoRef<TypedRegValue> UpperFiltersEx(interface_cast<RegValue>(UpperFilters));
// Здесь будет 2 временных объекта: при вызове interface_cast ("обёртка" вокруг UpperFilters) и
// UpperFiltersEx() (типа TypedRegValue c RegValue в качестве параметра)
if (UpperFiltersEx)
{
result = UpperFiltersEx->SetValue(UpperFiltersEx->GetType(), UpperFiltersEx->GetValue() + NewUpper);
// И здесь 2: результат сложения и "обёртка" вокруг этого результата,
// приводящая его к типу второго аргумента SetValue()
}
Итого к коду из 3-х значащих строчек, по-вашему, надо добавить ещё 4. Соотношение хоть и не 5:20, но лично меня впечатляет.
Кстати, "обёртка" вокруг UpperFiltersEx->GetValue() + NewUpper называется Variant и имеет 5 конструкторов с различными типами аргумента. Что позволяет использовать его в т.ч. в качестве возвращаемого значения. Как вы собираетесь заменить эту функциональность фабриками?
Broken Windows® cures my ills and makes me feel alright... ©
Это сообщение редактировалось 10.12.2007 в 21:45
Сергей-4030> В смысле, чем? У меня будет так:
Сергей-4030> Object o = ObjectFactory.createAppropriateObject();
Сергей-4030> Если мне понадобится, чтоб создаваемые таким образом объекты были немножко другие, я изменяю 1 (один) метод: createAppropriateObject();
А чем это лучше варианта с имплементацией, наследующей интерфейс:
ObjectInterface o = new ObjectImplementation(); - до
ObjectInterface o = new AnotherObjectImplementation(); - после
Сергей-4030> Object o = ObjectFactory.createAppropriateObject();
Сергей-4030> Если мне понадобится, чтоб создаваемые таким образом объекты были немножко другие, я изменяю 1 (один) метод: createAppropriateObject();
А чем это лучше варианта с имплементацией, наследующей интерфейс:
ObjectInterface o = new ObjectImplementation(); - до
ObjectInterface o = new AnotherObjectImplementation(); - после
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Это будет офигительно лучше. Представьте, у вас система в сто тыщ строк, таких вызовов ( ObjectInterface o = new ObjectImplementation() ) тридцать тысяч. Вы пойдете весь код шерстить?
Нет. Убью архитектора Наверное, всё-таки, такие вызовы должны быть в одном месте. Собственно, именно это место вы можете называть фабрикой, если вам так больше нравится. Только причём здесь запрет публичных конструкторов?
Представьте, у вас система в сто тыщ строк, таких вызовов ( ObjectInterface o = new ObjectImplementation() ) тридцать тысяч. Вы пойдете весь код шерстить? Нет. Убью архитектора
Наверное, всё-таки, такие вызовы должны быть в одном месте. Собственно, именно это место вы можете называть фабрикой, если вам так больше нравится. Только причём здесь запрет публичных конструкторов?
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Ну, то есть, глобальных противоречий у нас нет.
Если вы согласны оставить публичные конструкторы хотя бы только в С++, то нет
Сергей-4030> Для того, чтобы требование "не создавать объектов в обход "одного места" было енфорсано не только строгими глазами начальника, а тупыми ограничениями синтакса.
Всё ж таки это создаст дополнительные трудности с сомнительным положительным эффектом. По крайней мере, в одном отдельно взятом языке с отсутствующей автоматической сборкой мусора
Если вы согласны оставить публичные конструкторы хотя бы только в С++, то нет
Сергей-4030> Для того, чтобы требование "не создавать объектов в обход "одного места" было енфорсано не только строгими глазами начальника, а тупыми ограничениями синтакса.
Всё ж таки это создаст дополнительные трудности с сомнительным положительным эффектом. По крайней мере, в одном отдельно взятом языке с отсутствующей автоматической сборкой мусора
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Кстати, бросать в конструкторе исключения - в С++ это очень плохо, очень.
?? Это почему? В деструкторе - да, очень плохая идея. А в конструкторе-то с чего вдруг?
?? Это почему? В деструкторе - да, очень плохая идея. А в конструкторе-то с чего вдруг?
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> Вот почему:
И? Из первого абзаца следует скорее то, что нельзя даже пытаться использовать объект, кинувший исключение при конструировании. Во втором даётся совет, когда исключения использовать всё-таки надо (к слову, не помню, чтобы встречал другое их использование в конструкторе). Всё ж не использовать совсем - это слишком сильное утверждение
И?
Из первого абзаца следует скорее то, что нельзя даже пытаться использовать объект, кинувший исключение при конструировании. Во втором даётся совет, когда исключения использовать всё-таки надо (к слову, не помню, чтобы встречал другое их использование в конструкторе). Всё ж не использовать совсем - это слишком сильное утверждение
Broken Windows® cures my ills and makes me feel alright... ©
Сергей-4030> ЗЫ Кстати, да, отврат. После 6 лет С++ я очень его любил. Но когда я познакомился с Java, я понял, что любовь прошла. Последние полгода страдал с embedded systems под С++ - очень мне не нравилось. Сейчас вернулся к Java, слава богу.
Всё ж таки у С++ спектр решаемых задач пошире будет NTшный драйвер на Java написать слабо, к примеру? Или вот эти ваши embedded systems - С++ там же явно не просто так был?
Всё ж таки у С++ спектр решаемых задач пошире будет
NTшный драйвер на Java написать слабо, к примеру? Или вот эти ваши embedded systems - С++ там же явно не просто так был?
Broken Windows® cures my ills and makes me feel alright... ©
Copyright © Balancer 1997..2024
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
