[image]

Нужны ли public конструкторы?

 
1 2 3 4
RU Kernel3 #10.12.2007 18:50  @Сергей-4030#10.12.2007 18:47
+
-
edit
 

Kernel3

аксакал

Сергей-4030> Да-да. ;) А еще мы, серьезные люди, боимся гоуту и вообще - программирования спагетти. По своей ограниченности. ;) Гоуту - в массы, долой предрассудки!
Разумеется. А вы знаете способ проще, выйти из вложенных циклов? (Только не говорите, что вы их не пишете)
   
US Сергей-4030 #10.12.2007 18:51  @Kernel3#10.12.2007 18:47
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Я не пытаюсь вас обидеть, мне просто непонятно, как из наличия factories можно сделать такие глобальные выводы про бессмысленность ООП. Вы бы расшифровали, в чем именно проблема. Я на самом деле не понимаю.
Kernel3> Надеюсь, станет понятнее после примера кода. Грубо говоря, если вместо 5 строчек кода придётся каждый раз писать 20, то непонятно, а на хрена, собственно, нужно всё это абстрагирование. Бо на голых Сях получится примерно то же самое.

Как это вам придется такие ужасы писать? :) Вызов фактори - та же одна строчка. И все-таки, что именно подрывает сами устои ООП? Вы писали, что "явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным" - разъясните этот фрагмент. Какое именно явное создание и почему оно делает ООП бессмысленным?
   
RU Kernel3 #10.12.2007 18:52  @Сергей-4030#10.12.2007 18:51
+
-
edit
 

Kernel3

аксакал

Сергей-4030> Как это вам придется такие ужасы писать? :) Вызов фактори - та же одна строчка. И все-таки, что именно подрывает сами устои ООП? Вы писали, что "явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным" - разъясните этот фрагмент. Какое именно явное создание и почему оно делает ООП бессмысленным?
Вызов фактори - это одна строчка для каждого временного объекта. Что непонятно? :)
   
US Сергей-4030 #10.12.2007 18:54  @Kernel3#10.12.2007 18:50
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Да-да. ;) А еще мы, серьезные люди, боимся гоуту и вообще - программирования спагетти. По своей ограниченности. ;) Гоуту - в массы, долой предрассудки!
Kernel3> Разумеется. А вы знаете способ проще, выйти из вложенных циклов? (Только не говорите, что вы их не пишете)

Естественно, знаю. :) А вы не знаете? Я вам подскажу: есть такие ключевые слова break и continue. Иногда очень удобно использовать также return. А кое-где есть еще break с меткой.
   
RU Kernel3 #10.12.2007 18:58  @Сергей-4030#10.12.2007 18:54
+
-
edit
 

Kernel3

аксакал

Сергей-4030> Естественно, знаю. :) А вы не знаете? Я вам подскажу: есть такие ключевые слова break и continue.
Если бы у break и continue можно было указать количество циклов, которые нужно продолжить/прекратить, тогда да.
Сергей-4030> Иногда очень удобно использовать также return.
Ага. Но отрицая гоуту очень легко прийти к концепции единственного выхода у функции. ПМСМ, из той же серии заморочки :)
Сергей-4030> А кое-где есть еще break с меткой.
А вот с этого места поподробнее, пожалуйста :)
   
US Сергей-4030 #10.12.2007 18:59  @Kernel3#10.12.2007 18:52
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Как это вам придется такие ужасы писать? :) Вызов фактори - та же одна строчка. И все-таки, что именно подрывает сами устои ООП? Вы писали, что "явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным" - разъясните этот фрагмент. Какое именно явное создание и почему оно делает ООП бессмысленным?
Kernel3> Вызов фактори - это одна строчка для каждого временного объекта. Что непонятно? :)

Я, по-моему, явно указал, что в очень некоторых случаях фактори использовать не надо. Когда создание объекта очень дешево а оверхед получается большой. Это в основном всякие временные переменные базовых типов, вроде int temp=5; Во всех остальных случаях фактори ничего не добавит к "сложности объявления", но сильно добавит к ясности кода и "поддерживаемости".
   
US Сергей-4030 #10.12.2007 19:03  @Kernel3#10.12.2007 18:58
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Естественно, знаю. :) А вы не знаете? Я вам подскажу: есть такие ключевые слова break и continue.
Kernel3> Если бы у break и continue можно было указать количество циклов, которые нужно продолжить/прекратить, тогда да.
Сергей-4030>> Иногда очень удобно использовать также return.
Kernel3> Ага. Но отрицая гоуту очень легко прийти к концепции единственного выхода у функции. ПМСМ, из той же серии заморочки :)

Нет, не из той же серии. Все return ведут к одной точке. гоуту ведет куда угодно.

Сергей-4030>> А кое-где есть еще break с меткой.
Kernel3> А вот с этого места поподробнее, пожалуйста :)

Пожалуйста, никаких проблем. Вот здесь поподробнее.
   
RU Kernel3 #10.12.2007 19:04  @Сергей-4030#10.12.2007 18:59
+
-
edit
 

Kernel3

аксакал

Сергей-4030> Я, по-моему, явно указал, что в очень некоторых случаях фактори использовать не надо. Когда создание объекта очень дешево а оверхед получается большой. Это в основном всякие временные переменные базовых типов, вроде int temp=5;
Я бы сказал, что временные переменные любых типов, если их создание дёшево.
Сергей-4030> Во всех остальных случаях фактори ничего не добавит к "сложности объявления", но сильно добавит к ясности кода и "поддерживаемости".
Ой... Давайте таки подождём примера кода? :)
   
RU Kernel3 #10.12.2007 19:07  @Сергей-4030#10.12.2007 19:03
+
-
edit
 

Kernel3

аксакал

Сергей-4030> Пожалуйста, никаких проблем. Вот здесь поподробнее.
О. И на каком году существования Java до создателей дошла необходимость наличия такой штуки? :F
   
US Сергей-4030 #10.12.2007 19:10  @Kernel3#10.12.2007 19:04
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Я, по-моему, явно указал, что в очень некоторых случаях фактори использовать не надо. Когда создание объекта очень дешево а оверхед получается большой. Это в основном всякие временные переменные базовых типов, вроде int temp=5;
Kernel3> Я бы сказал, что временные переменные любых типов, если их создание дёшево.

Нет. Собственно контроль создания экземпляра не единственное преимущество. Есть еще преимущество гибкости. Если у вас по всей программе указано что-то вроде Object o = new ConcreteObject(); (тысячи участков кода), то что вы будете делать, если вам когда-либо понадобится, чтобы эти Object работали с другой имплементацией?
   
RU Kernel3 #10.12.2007 19:12  @Сергей-4030#10.12.2007 19:10
+
-
edit
 

Kernel3

аксакал

Сергей-4030> Нет. Собственно контроль создания экземпляра не единственное преимущество. Есть еще преимущество гибкости. Если у вас по всей программе указано что-то вроде Object o = new ConcreteObject(); (тысячи участков кода), то что вы будете делать, если вам когда-либо понадобится, чтобы эти Object работали с другой имплементацией?
Я, наверное, изначально напишу wrapper. И вы таки не поверите - именно с публичным конструктором для удобства использования :)
   
US Сергей-4030 #10.12.2007 19:16  @Kernel3#10.12.2007 19:12
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Нет. Собственно контроль создания экземпляра не единственное преимущество. Есть еще преимущество гибкости. Если у вас по всей программе указано что-то вроде Object o = new ConcreteObject(); (тысячи участков кода), то что вы будете делать, если вам когда-либо понадобится, чтобы эти Object работали с другой имплементацией?
Kernel3> Я, наверное, изначально напишу wrapper. И вы таки не поверите - именно с публичным конструктором для удобства использования :)

wrapper чего? Что именно у вас будет вместо

Object o = new ConcreteObject();

Kernel3> О. И на каком году существования Java до создателей дошла необходимость наличия такой штуки?

Да вроде как на первом. Уж точно, лет десять как уже. Для вас и это новость? ;)
   
RU Kernel3 #10.12.2007 19:20  @Сергей-4030#10.12.2007 19:16
+
-
edit
 

Kernel3

аксакал

Сергей-4030> wrapper чего? Что именно у вас будет вместо
Сергей-4030> Object o = new ConcreteObject();
Для ConcreteObject(). Вы же упомянули имплементацию? Значит, есть и интерфейс? ;) Следовательно, будет либо использование виртуальных методов, либо прокси-объект в том или ином виде. Например, wrapper.
Сергей-4030> Да вроде как на первом. Уж точно, лет десять как уже. Для вас и это новость? ;)
Ага. Потому как в первой точно не было ;)
   
US Сергей-4030 #10.12.2007 19:25  @Kernel3#10.12.2007 19:20
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> wrapper чего? Что именно у вас будет вместо
Сергей-4030>> Object o = new ConcreteObject();
Kernel3> Для ConcreteObject(). Вы же упомянули имплементацию? Значит, есть и интерфейс? ;) Следовательно, будет либо использование виртуальных методов, либо прокси-объект в том или ином виде. Например, wrapper.

Ну вы укажите, что будет вместо Object o = new ConcreteObject(); Напишите уже код, который у вас будет в этом месте, не говорите загадками.

Сергей-4030>> Да вроде как на первом. Уж точно, лет десять как уже. Для вас и это новость? ;)
Kernel3> Ага. Потому как в первой точно не было ;)

А какую именно вы почитаете "первой"? В 1.1 как раз "точно было". Не знали? :lol:
   
RU Kernel3 #10.12.2007 19:30  @Сергей-4030#10.12.2007 19:25
+
-
edit
 

Kernel3

аксакал

Сергей-4030> Ну вы укажите, что будет вместо Object o = new ConcreteObject(); Напишите уже код, который у вас будет в этом месте, не говорите загадками.
Не понял. Тогда уточните, что такое ConcreteObject, и что чего у вас имплементирует.
Сергей-4030> А какую именно вы почитаете "первой"? В 1.1 как раз "точно было". Не знали? :lol:
Неа, не знал. Или забыл. Приду домой - перечитаю мануал.
   
US Сергей-4030 #10.12.2007 19:33  @Kernel3#10.12.2007 19:30
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Ну вы укажите, что будет вместо Object o = new ConcreteObject(); Напишите уже код, который у вас будет в этом месте, не говорите загадками.
Kernel3> Не понял. Тогда уточните, что такое ConcreteObject, и что чего у вас имплементирует.

Пофиг, что. Пускай будет ConcreteObject o = new ConcreteObject(); , если это проблема. Итак, что будет делать ваш wrapper с этим куском кода?

Kernel3> Неа, не знал. Или забыл. Приду домой - перечитаю мануал.

Бывает. Перечитайте, конечно.
   
US Mishka #10.12.2007 20:43  @Сергей-4030#10.12.2007 17:57
+
-
edit
 

Mishka

модератор
★★★
Mishka>> Я так понимаю, что вопрос навеян Джавой. :) Отстутствие локальных переменных не встроенных простых типов-классов иногда позволяет так говорить. ИМХО, фабриками всё не решить.
Сергей-4030> А где отличие от C++? Единственный минус фабрик, который я вижу: один лишний вызов функции. Это может быть проблемой иногда, как в С++ так и в Джаве, но обычно это не проблема. Конечно, и лишнее создание объекта часто не проблема. Но контролировать создание объекта как минимум не хуже, а в случаях, когда создание объекта - процесс очень затратный, так просто много лучше.
В локальных переменых — те, которые автоматически создаются и уничтожаются.

code text
  1. void foo( void )
  2. {
  3.   Trace tr( "foo" );
  4.   // blah-blah-blah
  5. }


Объект создастья на входе, автоматически уничтожится на выходе — причём в любой точке выхода. Издержки фабрики:
1. Лишний вызов.
2. Часто необходимость адаптировать возвращаемый объект или метод, чтобы возвращал объект нужного типа в иерархии наследования.
3. Полностью нельзя создавать локальные объекты. Скажем, как создать простой int в Java? :P
4. Проблемы создания временных переменных. Хотя в Джаве это не актуально, т.к. их там, вообщем-то, и нет. Хотя могут возникать при вычислениях. А не при вызовах.
   
RU Kernel3 #10.12.2007 21:03  @Сергей-4030#10.12.2007 19:33
+
-
edit
 

Kernel3

аксакал

Сергей-4030> Пофиг, что. Пускай будет ConcreteObject o = new ConcreteObject(); , если это проблема. Итак, что будет делать ваш wrapper с этим куском кода?
ConcreteObjectWrapper o = new ConcreteObjectWrapper(new ConcreteObject());
При изменении имплементации:
ConcreteObjectWrapper o = new ConcreteObjectWrapper(new AnotherConcreteObject());
Не самый красивый вариант, но тем не менее :) А чем вам здесь помогут фабрики?
   
RU riven-mage #10.12.2007 21:18
+
-
edit
 

riven-mage

опытный

А разве фабрики не появились от ущербности конструкторов? Т.е. если в языке "подкачать" конструкторы, то чем запись:

o = new SomeObject();

будет отличаться от:

o = SomeObject->factory();
   
US Сергей-4030 #10.12.2007 21:18  @Kernel3#10.12.2007 21:03
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Пофиг, что. Пускай будет ConcreteObject o = new ConcreteObject(); , если это проблема. Итак, что будет делать ваш wrapper с этим куском кода?
Kernel3> ConcreteObjectWrapper o = new ConcreteObjectWrapper(new ConcreteObject());
Kernel3> При изменении имплементации:
Kernel3> ConcreteObjectWrapper o = new ConcreteObjectWrapper(new AnotherConcreteObject());
Kernel3> Не самый красивый вариант, но тем не менее :) А чем вам здесь помогут фабрики?

В смысле, чем? У меня будет так:

Object o = ObjectFactory.createAppropriateObject();

Если мне понадобится, чтоб создаваемые таким образом объекты были немножко другие, я изменяю 1 (один) метод: createAppropriateObject();
   
US Сергей-4030 #10.12.2007 21:21  @riven-mage#10.12.2007 21:18
+
-
edit
 

Сергей-4030

исключающий третье
★★
riven-mage> А разве фабрики не появились от ущербности конструкторов? Т.е. если в языке "подкачать" конструкторы, то чем запись:
riven-mage> o = new SomeObject();
riven-mage> будет отличаться от:
riven-mage> o = SomeObject->factory();

Нет, совсем не поэтому. Они появились оттого, что надо контролировать создание объекта. Как "подкачать"? this инициализировать в конструкторе?
   
+
-
edit
 

Kernel3

аксакал

Обещанный пример (выдернуто из контекста, поэтому с глупыми комментариями :) ) :

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 конструкторов с различными типами аргумента. Что позволяет использовать его в т.ч. в качестве возвращаемого значения. Как вы собираетесь заменить эту функциональность фабриками? ;)
   
Это сообщение редактировалось 10.12.2007 в 21:45
RU Kernel3 #10.12.2007 21:32  @Сергей-4030#10.12.2007 21:18
+
-
edit
 

Kernel3

аксакал

Сергей-4030> В смысле, чем? У меня будет так:
Сергей-4030> Object o = ObjectFactory.createAppropriateObject();
Сергей-4030> Если мне понадобится, чтоб создаваемые таким образом объекты были немножко другие, я изменяю 1 (один) метод: createAppropriateObject();
А чем это лучше варианта с имплементацией, наследующей интерфейс:
ObjectInterface o = new ObjectImplementation(); - до
ObjectInterface o = new AnotherObjectImplementation(); - после
   
US Сергей-4030 #10.12.2007 21:40  @Mishka#10.12.2007 20:43
+
-
edit
 

Сергей-4030

исключающий третье
★★
Mishka> В локальных переменых — те, которые автоматически создаются и уничтожаются.

В случае локальных - да, но даже при этом иногда мы должны задумываться о том, не создают ли эти объекты каких-то третьих объектов. Когда создание объекта у нас централизованно, легче организовать такой контроль.

Mishka> Объект создастья на входе, автоматически уничтожится на выходе — причём в любой точке выхода.

Да, это правда, упустил. В Джава неактуально, в C++ - актуально. То есть, сильно актуально, сильно упрощает жизнь, если так не делать, то будем иметь ошибки оттого, что ресурсы не были освобождены явным образом. Но еще раз - это С++ и проблемы отсутсвия автоматической сборки мусора.

Mishka> 1. Лишний вызов.

Да.

Mishka> 2. Часто необходимость адаптировать возвращаемый объект или метод, чтобы возвращал объект нужного типа в иерархии наследования.

Не согласен. Кто мешает реализовать фабрику как захочешь?

Mishka> 3. Полностью нельзя создавать локальные объекты. Скажем, как создать простой int в Java? :P

Да, но об этом я говорил. Очень часто создаваемые объекты с малым оверхедом на создание - да, фабрика не нужна.
   
US Сергей-4030 #10.12.2007 21:43  @Kernel3#10.12.2007 21:32
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> В смысле, чем? У меня будет так:
Сергей-4030>> Object o = ObjectFactory.createAppropriateObject();
Сергей-4030>> Если мне понадобится, чтоб создаваемые таким образом объекты были немножко другие, я изменяю 1 (один) метод: createAppropriateObject();
Kernel3> А чем это лучше варианта с имплементацией, наследующей интерфейс:
Kernel3> ObjectInterface o = new ObjectImplementation(); - до
Kernel3> ObjectInterface o = new AnotherObjectImplementation(); - после

Это будет офигительно лучше. ;) Представьте, у вас система в сто тыщ строк, таких вызовов ( ObjectInterface o = new ObjectImplementation() ) тридцать тысяч. Вы пойдете весь код шерстить? При том заметьте, к какой-то части этого кода вы даже и исходников можете не иметь. Что делать? А если у вас фабрика, вы меняете ТОЛЬКО эту фабрику.
   
1 2 3 4

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru