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

 
1 2 3 4
+
-
edit
 

Balancer

администратор
★★★★★
Mishka> Ну и сделай мне выход из рекурсии любой глубины на 10 уровней ровно всегда.

9 NRDROP EXIT :)
 

yacc

старожил
★★☆
ИМХО classFactory нужны не всегда. Особливо для элементарных объектов. И зачем мне classFactory как объект?
что мне мешает сделать так
class ISomeIface
{
....
}

class SomeObject1 : ISomeIface
{
static ISomeIface* Create ( some parameters ) { ... };
}

зачем мне
class SomeFactory
{
ISomeIface* CreateObject1 ....
...
ISomeIface* CreateObjectN ....
}

Только быстрее запутаюсь. Слишком большое абстрагирование - пагубно. Есть принцип - "разделяй и влавствуй" :)
Часть сущностей действительно можно реализовать прокси-объектом. А часть объектов использовать как чисто функциональные - с ссылками или смарт-указателями на внешние данные - чтобы просто описать набор операций на связки данных - их то зачем через classFactory создавать? :)

P.S. Насчет брейков. Частенько пользуюсь таким, чтобы не запутаться в if-ах и не раздувать код в ширину:
int rc= err;
for(;;)
{
rc = SomeAction();
if ( Ok != rc )
break;

rc = SomeAction2();
if ( Ok != rc )
break;
....
rc = SomeAction_N();
break;
}

if ( Ok != rc )
{ .... /// bla-bla }
/// etc.

... если код состоит из достаточно примитивных действий, чтобы не тянуть за ними абстракции.
Абстрагировать надо тоже разумно... а то тот же С++ кучу вариантов для извращений позволяет :) Багов у меня, обычно, бывает мало. Да и юнит-тесты я обычно сам делаю.
 
US Naturalist #11.12.2007 01:44
+
-
edit
 

Naturalist

аксакал

Присоединяюсь к предыдущему оратору.

«Не следует множить сущее без необходимости» У. Оккам
 
US Сергей-4030 #11.12.2007 02:23  @yacc#11.12.2007 01:32
+
-
edit
 

Сергей-4030

исключающий третье
★★

yacc> ИМХО classFactory нужны не всегда. Особливо для элементарных объектов. И зачем мне classFactory как объект?

Никто не предлагал обязательно в отдельный объект. Разумеется, static метод вполне подойдет.

Собственно, резюмируя свои постинги, хочу сказать следующее. Очень умный принцип: "скрывай все, кроме того, что должно быть открыто". В этом смысле фактори объект - еще один уровень доступа, в дополнение с прайват и т.п. Паблик методы и данные - бывают. Но как правило непаблик методов больше. Паблик конструкторы тоже иногда нужны. Но чаще полезно скрыть механизм создания нового instance.
 
RU yacc #11.12.2007 18:30  @Сергей-4030#11.12.2007 02:23
+
-
edit
 

yacc

старожил
★★☆
Сергей-4030> Собственно, резюмируя свои постинги, хочу сказать следующее. Очень умный принцип: "скрывай все, кроме того, что должно быть открыто". В этом смысле фактори объект - еще один уровень доступа, в дополнение с прайват и т.п. Паблик методы и данные - бывают. Но как правило непаблик методов больше. Паблик конструкторы тоже иногда нужны. Но чаще полезно скрыть механизм создания нового instance.
Я ток вот чего не понял - а к чему все это? :) Синтаксис языка и его поведение менять вроде как не предлагается... :) Что-то вроде Best Practice или Coding Rules? :) Тык я еще могу добавить... :) Ну например - вытащите это в DLL/SO/SL(HPUX)/COM и разделите использование интерфейсами на модули. И нечего в другой модуль лазить - хай это будет сферой действия другого разработчика, а для тебя - "черный ящик" с интерфейсом :) Да и править легче если на модули разбито...
 
US Mishka #13.12.2007 22:28  @Naturalist#11.12.2007 01:07
+
-
edit
 

Mishka

модератор
★★★
Naturalist> Это должен знать только тот, кто живет на 10 этаже стека, остальным должно быть все равно. Это нарушает концепцию структурного программирования. Поэтому таких чудес в структурном программировании нет. Даже в Ц.

Нарушает не более, чем несколько операторов return в процедуре. И отматывает стек по полной, а не просто туда прыгает. И структурно эквивалентно:

code text
  1.  
  2. int f( int* result )
  3. {
  4.   ...
  5.   int depth = f( result );
  6.   if ( depth > 0 ) return depth - 1;
  7.   ...
  8. }
 
US Mishka #15.12.2007 00:38  @Naturalist#11.12.2007 01:07
+
-
edit
 

Mishka

модератор
★★★
Naturalist> Не-а. Остановка была на каждом выходе из каждого скопа с вызовом всех деструкторов и проч.

Ты сказал то, что и я. Даже меньше. Раскрутка стека происходит всегда. Но в конце каждой раскрутки проверяется есть ли эксепшн. Если он есть, то происходит поиск ближайшего try блока по стеку. Если он не найден, то стек раскручивается в обратную сторону, уничтожаются все объекты, которые вылезают за пределы scope, и далее снова проверяется есть ли try блок на стеке...

Naturalist> Можно кинуть класс с счетчиком. В любом случае, эксцепшин не для этого сделан. Этот разговор похож на спор на тему, кто победит, кит или слон. ;)

А причём тут эксепш? Это ты сказал, что он есть для этого дела.

Naturalist> Делаем итератор обхода дерева и все становится попроще...

Чем? Ктстати, изобрази итератор без рекурсии для обхода односвязанного дерева. :P У нас это был стандартный тест на проверку знаний по структурам данных.

Naturalist> Это должен знать только тот, кто живет на 10 этаже стека, остальным должно быть все равно. Это нарушает концепцию структурного программирования. Поэтому таких чудес в структурном программировании нет. Даже в Ц.

Ты чего? Нифига это не нарушает.
 
US Mishka #15.12.2007 00:39  @Naturalist#11.12.2007 01:14
+
-
edit
 

Mishka

модератор
★★★
Naturalist> Кстати, почему не сделать переменную bool hurray_we_found_it=false;?
Чего нашли-то?
 
+
-
edit
 

Mishka

модератор
★★★
Mishka>> Ну и сделай мне выход из рекурсии любой глубины на 10 уровней ровно всегда.
Balancer> 9 NRDROP EXIT :)
А стек кто будет расскручивать взад?
 
+
-
edit
 

Mishka

модератор
★★★
Для любителей С++ и function try блоков — великолепная статья на вражьем языке. Очень здорово и живо написана — GotW #66: Constructor Failures
 
+
-
edit
 

Balancer

администратор
★★★★★
Mishka> А стек кто будет расскручивать взад?

Пардон, пропустил, что из рекурсии. Тогда перед этим ещё XX NDROP, где XX - 9*число аргументов слова :)

Вообще, определяем что-то типа:

: UP ( argc level — ) 1+ TUCK * NDROP RNDROP ;

И пишем где надо - 9 UP :)
 
1 2 3 4

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