1. Видимо что то не так со структурой и логикой, раз нужен объект прослойка только для передачи параметров методу(хотя не стоит забывать про шаблоны проектирования Адаптер, Прокси и Декоратор). Либо мы можем использовать этот объект в других местах, либо у нас этот метод работает как не пришей собаки хвост. Вообще все преимущество объектов и их методов, в том что первые могут хранить состояние, а вторые с этим состоянием работать.
2. Производительность разговор отдельный поэтому я его и не затрагивал. А вот логику программы наличие объектов облегчает, при условие конечно грамотного проектирования, так как объект хранит состояние и этим состоянием можно управлять через него. Ведь можно сделать так:

а можно так:

На первый взгляд второй вариант будет проще но, только до тех пор пока программа будет рисовать только одину окружность и ничего больше. Как только нужно рисовать кроме нее ещё квадрат и треугольник, да так чтобы они могли менять наложение друг на друга и передвигаться по экрану, получаем головную боль и трудно расширяемый код, если нам вдруг потребуется. Если кто мне не верит может попробовать реализовать такую программку только через функции и без использования структур( к коим относится и массив ). Если у вас получится легко расширяемая программа я с удовольствием сниму перед вами шляпу.


Это сообщение отредактировал(а) krundetz - 28.3.2013, 16:53

ты так говоришь, как будто эти параметры не зависят ни от чего, просто с воздуха их взяли и на бум решили что здесь применим?

Параметры могут быть из разных классов, никак не связанных между собой. Какой смысл взять и сунуть все в структуру если так более понятно. Получается каждой Функции по Структуре. 

если они никак не связаны между собой но используются в одной функции или методе то это как минимум странно, возможно эта функция может быть спокойно разбита на две, так как похоже в ней выполняются одновременно два не связанных между собой действия. Если можно примерчик приведи, посмотрю что ты имеешь в виду.

Ситуации разные бывают, но если дополнительная структура действительно делает код понятнее то ее стоит использовать, даже больше если вдруг появляется желание где то использовать структуру так как это более понятно и логично, а раньше такой структуры у вас нигде не было, то у вас ошибка в проектирование.

Не стоит утрировать.

Это сообщение отредактировал(а) krundetz - 29.3.2013, 08:39

вот такой пример: класс доступа к веб сервису. для его инициализации требуется
1) параметры сервера
2) параметры для вывода в лог-файл
3) параметры, связанные с задачей

каждая группа параметров содержит несколько подпараметров (например, сервер: url, и информация о прокси - тип, адрес, порт, логин, пароль).

как делать в этом случае?

Понравилась статья. Мне кажется - по теме.
Особенно нравится примеры про собаку и счет в банке.

DI нам в помощь, но наблюдатель будет более предпочтительным.

сколько какие?


вот и получается, что здесь лучше использовать несколько структур, чем кучу разрозненных параметров, никак в струкутры не объединенные

на мой взгляд код вида:

более удобен, чем:

и удобнее такого:

самым оптимальным при функциональном подходе будет что то наподобие такого:

но даже в этом варианте, я вижу много минусов, так как не получиться скрыть работу с прокси, то есть если они будут не только HTTP, но и Socks, то нам придётся выносить работу с разными вариантами прокси в createConnection, вместо того чтобы подставлять разные классы прокси реализующие один интерфейс.

В общем приведенный тобой пример, говорит больше в пользу ООП или хотябы структурного подхода.


Ознакомлюсь, выскажу своё мнение.

Это сообщение отредактировал(а) krundetz - 29.3.2013, 10:45

это те же структуры, только сбоку

Добавлено через 2 минуты и 34 секунды

возможно...

но я не для тебя пример писал, хотелось бы мнение другой стороны услышать

Добавлено через 3 минуты и 12 секунд

хабр лежит уже который час

Бу-го-га, наш старый холивар теперь и на хабре  

Господи, чушь какая, если что - то изучаем, обычно вопросы задаем конкретные, что явно непонятно. А тут тупая болтовня   

Хороший пример привел baldina, можно еше что-то такое:

Например функция для добавления нового графического обьекта в конкретную сцену. Параметры:э
ссылка на соответствующую сцену
ссылка на хранилище данных  чтобы своевременно обновить графические елементы в зависимости от поступающих данных
ссылка на обьект трансформатор для перевода значении из хранилища в соответствующие значения для сцены
ссылка на параметры графического обьекта

получилось 4 параметра, если еще подумать, можно еще добавить. Да, программа должна быть обьектно ориентированной, но не могу понять какое отношение имеют структуры-обертки для параметров к ООП. 

P.S. если честно мне все равно )

видимо у нас с тобой расхождение в терминологии, да и диалог о структурах больше относиться к передаче параметров методу, а не к ООП. Выше я писал следующие:



а что тогда дискутируешь?


ты про что? это ж флейм!


сразу не понял


мне бы тоже, но видимо не судьба