-
yacc: Все сообщения за 11 Декабря 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 |
ИМХО 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.
... если код состоит из достаточно примитивных действий, чтобы не тянуть за ними абстракции.
Абстрагировать надо тоже разумно... а то тот же С++ кучу вариантов для извращений позволяет Багов у меня, обычно, бывает мало. Да и юнит-тесты я обычно сам делаю.
что мне мешает сделать так
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.
... если код состоит из достаточно примитивных действий, чтобы не тянуть за ними абстракции.
Абстрагировать надо тоже разумно... а то тот же С++ кучу вариантов для извращений позволяет
Багов у меня, обычно, бывает мало. Да и юнит-тесты я обычно сам делаю.
инфо
инструменты
Сергей-4030> Собственно, резюмируя свои постинги, хочу сказать следующее. Очень умный принцип: "скрывай все, кроме того, что должно быть открыто". В этом смысле фактори объект - еще один уровень доступа, в дополнение с прайват и т.п. Паблик методы и данные - бывают. Но как правило непаблик методов больше. Паблик конструкторы тоже иногда нужны. Но чаще полезно скрыть механизм создания нового instance.
Я ток вот чего не понял - а к чему все это? Синтаксис языка и его поведение менять вроде как не предлагается... Что-то вроде Best Practice или Coding Rules? Тык я еще могу добавить... Ну например - вытащите это в DLL/SO/SL(HPUX)/COM и разделите использование интерфейсами на модули. И нечего в другой модуль лазить - хай это будет сферой действия другого разработчика, а для тебя - "черный ящик" с интерфейсом Да и править легче если на модули разбито...
Я ток вот чего не понял - а к чему все это?
Синтаксис языка и его поведение менять вроде как не предлагается... Что-то вроде Best Practice или Coding Rules? Тык я еще могу добавить... Ну например - вытащите это в DLL/SO/SL(HPUX)/COM и разделите использование интерфейсами на модули. И нечего в другой модуль лазить - хай это будет сферой действия другого разработчика, а для тебя - "черный ящик" с интерфейсом Да и править легче если на модули разбито...
Автобоксинг в Джава вчера и сегодня (только для джавистов). #11.12.2007 20:24 @tarasv#11.12.2007 19:23 
tarasv> Вобщем прелестная штука эта перезагрузка операторов (но полноценная а не как в C++) -
полноценная - это как? что переопределять надо?
tarasv>нужен новый язык, сели подумали и готово.
Спроси Мишку про Алгол-68...
tarasv>ИМХО именно по этому в жабе перезагрузки и нет - это не язык для написания своих языков, а значит нефиг ерундой заниматься.
Угу. Именно так. А Балансера можешь про Форт спросить...
tarasv> А насчет плюсов, как по мне, использование перезагрузки операторов в C++ его авторами годится только как пример для учебника что в языке это свойство есть - << и >> так и не заменили полностью printf и scanf а значит изначальный дизайн просто никуда не годится.
printf и scanf ( wprintf и wscanf если с юникодом работаешь ) иногда полезно чтобы обработать явно, а не через ловлю исключений и/или чтобы работать с форматированным вводом/выводом ( особенно на основе шаблонов ). Как правило это обертывается классом и в явном виде не используется - кроме как дергание методов этого класса. << и >> - более широкого класса оператор, а не только для работы с консольным вводом/выводом.
tarasv> Может мне не везло но мне практически не попадались примеры хорошего дизайна на С++ с использованием перезагрузки операторов - все больше головоломку напоминает написанную чтобы автора не уволили, потому что найдти героев чтобы сопровождать такой код будет очень сложно.
Смотря кто писал. Мне попадался очень красивый код. Но такое скорее в библиотеках требуется для описания набора базисных сущностей. Бизнес-код писать через постоянное переопределение операторов ИМХО - извращение. Вот действительно хрен потом разберешься
Вот это, надеюсь, все уже видели ( вообще-то старая штука ) http://sunsite.nus.edu.sg/pub/humour/prog-evolve.html ?
полноценная - это как? что переопределять надо?
tarasv>нужен новый язык, сели подумали и готово.
Спроси Мишку про Алгол-68...
tarasv>ИМХО именно по этому в жабе перезагрузки и нет - это не язык для написания своих языков, а значит нефиг ерундой заниматься.
Угу. Именно так. А Балансера можешь про Форт спросить...
tarasv> А насчет плюсов, как по мне, использование перезагрузки операторов в C++ его авторами годится только как пример для учебника что в языке это свойство есть - << и >> так и не заменили полностью printf и scanf а значит изначальный дизайн просто никуда не годится.
printf и scanf ( wprintf и wscanf если с юникодом работаешь ) иногда полезно чтобы обработать явно, а не через ловлю исключений и/или чтобы работать с форматированным вводом/выводом ( особенно на основе шаблонов ). Как правило это обертывается классом и в явном виде не используется - кроме как дергание методов этого класса. << и >> - более широкого класса оператор, а не только для работы с консольным вводом/выводом.
tarasv> Может мне не везло но мне практически не попадались примеры хорошего дизайна на С++ с использованием перезагрузки операторов - все больше головоломку напоминает написанную чтобы автора не уволили, потому что найдти героев чтобы сопровождать такой код будет очень сложно.
Смотря кто писал.
Мне попадался очень красивый код. Но такое скорее в библиотеках требуется для описания набора базисных сущностей. Бизнес-код писать через постоянное переопределение операторов ИМХО - извращение. Вот действительно хрен потом разберешься Вот это, надеюсь, все уже видели ( вообще-то старая штука ) http://sunsite.nus.edu.sg/pub/humour/prog-evolve.html ?
Aaz> Вот тут ты не вполне прав. Грубо говоря (поскольку аэродинамике меня не учили ), при помпаже одного движка вперед идет "волна возмущений", которая может перехлестывать через "перегородку" между в/з и провоцировать помпаж второго движка. Причем схемы с вертикальным клином считаются более "опасными" - там длину клина произвольно не увеличишь, в отличие от "простой" перегородки между в/з с гор. клиньями.
Тогда вопрос - а если мы делаем ровное набегание ( без углов атаки ) и длина клина одна и та же при вертикальном и горизонтальном расположении. Считаются ли эти схемы эквивалентными с т.зрения волновой акустики ( волны же продольные, а не поперечные как элекромагнитные )? Я так понимаю Владимир именно это имеет ввиду. Конструктивные ограничения - это уже второй вопрос.
), при помпаже одного движка вперед идет "волна возмущений", которая может перехлестывать через "перегородку" между в/з и провоцировать помпаж второго движка. Причем схемы с вертикальным клином считаются более "опасными" - там длину клина произвольно не увеличишь, в отличие от "простой" перегородки между в/з с гор. клиньями.Тогда вопрос - а если мы делаем ровное набегание ( без углов атаки ) и длина клина одна и та же при вертикальном и горизонтальном расположении. Считаются ли эти схемы эквивалентными с т.зрения волновой акустики ( волны же продольные, а не поперечные как элекромагнитные )?
Я так понимаю Владимир именно это имеет ввиду. Конструктивные ограничения - это уже второй вопрос.
paralay> Допустим в один из моторов попала птица, произошел помпаж двигателя. ...
Допустим, ты изысканный гурман ( большой извращенец ) в экспериментальных делах. И ... захотелось тебе сделать вертикальное расположение двигателей рядом. Ты взял тот же Миг-19 и повернул фюзеляж у него на 90 градусов оносительно крыла. Т.е. все то же самое, только разделитель у воздухозаборника теперь горизонтальный. Что изменится в поставленной тобой задаче с попаданием птицы в один из каналов к двигателю? Да ничего! Важна форма воздухозаборника по отношению к разделителю ( скошенный в сторону ( Ту-160 ) или параллельно скошенные ( Миг 1.44 ) или прямой нескошенный ( Миг-19 ) ), а не факт вертикальности-горизонтальности - это уже к оптимизации компоновки
Допустим, ты изысканный гурман ( большой извращенец
) в экспериментальных делах. И ... захотелось тебе сделать вертикальное расположение двигателей рядом. Ты взял тот же Миг-19 и повернул фюзеляж у него на 90 градусов оносительно крыла. Т.е. все то же самое, только разделитель у воздухозаборника теперь горизонтальный. Что изменится в поставленной тобой задаче с попаданием птицы в один из каналов к двигателю? Да ничего! Важна форма воздухозаборника по отношению к разделителю ( скошенный в сторону ( Ту-160 ) или параллельно скошенные ( Миг 1.44 ) или прямой нескошенный ( Миг-19 ) ), а не факт вертикальности-горизонтальности - это уже к оптимизации компоновки
chetbor> ИКВ крутилась одинако что у вас что у нас, потому что ИКВ одна и таже была
chetbor> 5 мин - радиальная
chetbor> 15 мин на все полеты
chetbor> 30 мин - на НБ
chetbor> Вова, мы тута , на фейс контроле...
А можно я свои пять копеек добавлю? Вот та ветка о которой Ламм говорит - Вопрос: Возможности НК Су-17/Миг-27/Су-24/Миг-29
Я об энтом спрашивал.
Коль вы тут самолями меряетесь... добавлю свои пять копеек Ни ИБА-шник я ни в коей мере, зато знаю авиацию ПВО.
Су-15 - мой любимый. Красивый,сцуко, просто великолепный. Резкий, стремительный, ничего лишнего. Летал на нем на тренажере на перехват учебной цели. Осиповича помню ( я тогда в школу ходил ), клевый был мужик. Все правильно сделал.
Миг-31 - самолет не для лейтенантов, и не для старлеев. Сложный. Дофига чего позволяят. Но пользоваться им надо с умением. Любить его надо. На моей памяти знал три экипажа, которые с полета не вернулись в отличии от Су-15 - даже с отсосанным фонарем на взлете его сажали.
Миг-23. Птеродактиль. Но... почему-то привлекает своей непонятностью ( как в фантастических фильмах - чем больше наворотов, тем привлекательнее ). Практически незнаком с ним - видел тройку взлетающих строевых!, которые после взлета разошлись веером. Красиво блин!
Су-27 - тоже птеродактиль. Тоже привлекает своей непонятностью. Но... летает сцуко на малых высотах медленно ( опять же строевые летчики ) и красиво - завораживает. Взлетает... ну с его тяговооруженностью это вообще нечто. Обзор из кабины просто великолепный ( сидел в ней, вообще не для летчика сидеть в кабине самолета на ДЗ... выставка с ее бутафорией потом в сравнение не идет, когда у тебя под крылом боевые ракеты... )
В общем.... ну низзя так самоли сравнивать. Они как женщины... другой такой не бывает - каждая по своему
chetbor> 5 мин - радиальная
chetbor> 15 мин на все полеты
chetbor> 30 мин - на НБ
chetbor> Вова, мы тута , на фейс контроле...
А можно я свои пять копеек добавлю?
Вот та ветка о которой Ламм говорит - Вопрос: Возможности НК Су-17/Миг-27/Су-24/Миг-29 Я об энтом спрашивал.
Коль вы тут самолями меряетесь... добавлю свои пять копеек
Ни ИБА-шник я ни в коей мере, зато знаю авиацию ПВО.Су-15 - мой любимый. Красивый,сцуко, просто великолепный. Резкий, стремительный, ничего лишнего. Летал на нем на тренажере на перехват учебной цели. Осиповича помню ( я тогда в школу ходил ), клевый был мужик. Все правильно сделал.
Миг-31 - самолет не для лейтенантов, и не для старлеев. Сложный. Дофига чего позволяят. Но пользоваться им надо с умением. Любить его надо. На моей памяти знал три экипажа, которые с полета не вернулись в отличии от Су-15 - даже с отсосанным фонарем на взлете его сажали.
Миг-23. Птеродактиль. Но... почему-то привлекает своей непонятностью ( как в фантастических фильмах - чем больше наворотов, тем привлекательнее ). Практически незнаком с ним - видел тройку взлетающих строевых!, которые после взлета разошлись веером. Красиво блин!
Су-27 - тоже птеродактиль. Тоже привлекает своей непонятностью. Но... летает сцуко на малых высотах медленно ( опять же строевые летчики ) и красиво - завораживает. Взлетает... ну с его тяговооруженностью это вообще нечто. Обзор из кабины просто великолепный ( сидел в ней, вообще не для летчика сидеть в кабине самолета на ДЗ... выставка с ее бутафорией потом в сравнение не идет, когда у тебя под крылом боевые ракеты... )
В общем.... ну низзя так самоли сравнивать. Они как женщины... другой такой не бывает - каждая по своему
Copyright © Balancer 1997..2024
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
