- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
@Override
public ResponseBag[] send(SmsBag[] smsBag) {
ArrayList<ResponseBag> responseList = new ArrayList<ResponseBag>();
for(SmsBag bag : smsBag) {
responseList.add(super.send(bag));
}
ResponseBag[] responseBag = new ResponseBag[responseList.size()];
return responseList.toArray(responseBag);
}
Follow us!
return responseList.toArray();
только толку от этого немного, одну строчку сыкономили.
Только почему super.send(bag), а не просто send(bag)?
П. С. В объявлениях переменной лучше использовать интерфейсы, т. е.
List<ResponseBag> responseList = new ArrayList<ResponseBag>();
Ну и можно было сразу размер списка задать через конструктор new ArrayList<ResponseBag>(smsBag.length).
Можно было так:
public ResponseBag[] send(SmsBag[] smsBag) {
ResponseBag[] responseBag = new ResponseBag[smsBag.length];
for (int i = 0; i < smsBag.length; i++) {
responseBag[i] = super.send(smsBag[i]);
}
return responseBag;
}
А ещё лучше было бы совсем избавиться от массивов и использовать только списки. Если, конечно, есть такая возможность.
Короче, довольно изысканное говнецо.
Но я не на столько хорошо знаю Java, чтобы понять зачем столько раз нужно было создавать разные коллекции.
очевидно (есть @Override), у super должен быть ещё и метод, отправляющий массив SmsBag
Он либо не реализован, либо делает не то, что нужно. Возможно ещё, что этот метод определён в некотором другом интерфейсе, не реализованным суперклассом, но мне кажется это маловероятным.
Подтвердить или опровергнуть догадки может только @manyrus.
> зачем столько раз нужно было создавать разные коллекции
Чтобы правильно перевести кошерные коллекции в некошерные массивы.
Namespace: components.
ISendSingLesms:
ISendingSms:
Так же тут есть 2 класса - ResponseBag и SmsBag - обычные классы со своими геттерами/сеттерами.
------------------------------
Namespace: components.epochta.
BaseSmsSender:
SendingSms:
SendingSingleSms:
Только вот это архитектура мне совсем не нравиться, за 2 мин. её придумал. Надо ещё посидеть :).
Странно разделять один и тот же фасадный функционал по разным интерфейсам. Я бы сделал так:
Ещё мне не совсем понятен суффикс "Bag". Почему бы не использовать имена Sms и Response?
И, кстати, аннотация @Override над реализацией метода, определённого в интерфейсе, работает только в java 1.6. Если не хотите проблем с обратной совместимостью, лучше ставить её только при переопределении метода базового класса.
Интерфейсы - добро и ядро IoC, наследование от обычных классов нужно довольно редко и должно наводить на размышления (очень часто его можно заместить композицией). Именно в этом конкретном случае лучше создать интерфейс и его реализацию, чем строить невнятные иерархии классов.
наследование эллипса от круга так же бессмысленно, как и создание двух интерфейсов, один из которых посылает одно сообщение, а второй - коллекцию.
Разве недостаточно одного эллипса? Круг ведь - просто эллипс, у которого совпадают фокусы.
Что до интерфейсов - то это типичное мировозрение любителей Java. Мне интерфейс, как часть языка, престваляется объектом очень сомнительной полезности. И потому, что не решает полностью возложенных на него задач (способ определения типа по этикетке не описывает все возможные определения типа и, что еще хуже, плохо расширяется и дополняется). В данном случае я не вижу необходимости в создании более одного класса, который посылает сообщения, и не вижу никакой необходимости в интерфейсах, наследовании и т.д.
Видимо, вы не большой любитель юнит-тестирования.
А если серьезно, вы вообще не поняли о чем речь. То есть на столько не поняли, что я затрудняюсь как-то иначе ответить.
Что-то в последнее время вы часто остаётесь недопонятым.
http://govnokod.ru/7422#comment100869
> Мне интерфейс, как часть языка, престваляется объектом очень сомнительной полезности
Думаю, тут комментарии излишни.
Проблему примера с Warrior я не понял, ибо draw(Sword) и draw(Picture) имеют разные сигнатуры и могут быть в разных интерфейсах. Выглядит, конечно, не ахти, но явных проблем я не вижу. Если вы не можете ясно выразить свои мысли, лучше дайте ссылку на литературу.
Слышали о теории множеств? Наивная теория множеств приводит к парадоксам. Но именно теория множеств стала основой современной математики.
> Эту проблему нельзя решить никак - это как корень квадратный из -1
i ^ 2 = -1
Я так понял, что вы намекаете на динамическую типизацию, т.к. она, возможно, позволит избежать описанных вами проблем.
Например...
Корень из минус единицы потому и называется иррациональным, что иррациональный...
мнимый. Иррациональное число не представимо в виде отношения целых.
И, кстати, как раз типы чисел укладываются в строгую иерархию.
Уж поверьте, в математике я кое-что смыслю.
Кстати, я так и не понял, причём здесь интерфейсы. Проблема возникает не из-за интерфейсов как таковых, а из-за того, что мир не укладывается в единственно правильную таксономию (что и ежу понятно). Вы призываете избегать интерфейсов как инструмента абстракции и объявлять всё обычными классами. Что никак не исправит описанной вами проблемы.
- ненужный код (интерфейс призван решать определенные проблемы, которые в приведенной задаче не наблюдаются).
- интерфейс плохо справляется с проблемами, которые он призван решать (в принципе).
- класс выполняющий более узко-специфичную функцию является прототипом класса с менее специфичной функцией (отправить одно сообщение - это частный случай отправки множества сообщений).
Последняя проблема может быть воспринята двояко (о чем и говорилось в сравнении с проблемой круг - эллипс). И, возможно, в каком-то свете и не проблема вовсе, но было это сказано с иронией по поводу того, как автор восхвалял прелести ОО в Java по сравнению с PHP, хотя, если по-честному, они не так уж и различаются... (и в этом конкретном случае ведут себя одинаково).
как тестировать зависимой код, если нельзя подложить в тесте реализацию-заглушку? Отсылать кому-то реальные СМС? Отнаследоваться и полностью переопределить методы суперкласса? бред.
> интерфейс плохо справляется с проблемами, которые он призван решать
он отлично справляется с проблемами, которые призван решать, а именно гарантировать, что программист предоставил реализации для методов, определённых в интерфейсе, и скрывать конкретную реализацию. Остальное на совести программиста.
> класс выполняющий более узко-специфичную функцию является прототипом класса с менее специфичной функцией
Вгляните на интерфейс Collection. У него есть методы add и addAll. Потому что создавать ещё один класс только чтобы предоставить add, вызывающий addAll - маразм.
Итак, я вообще никаких проблем не вижу.
> автор восхвалял прелести ОО в Java по сравнению с PHP
не помню такого. в php даже все ключевые слова для ООП с java слизаны. php просто поощряет использование не-ООП практик. Причём не самых лучших. Поэтому новичок в java, пересевший с php, пишет далеко не самый лучший код.
У меня складывается впечатление, что вы не особо глубоко вникали в ООП.
P.S. Мне больше по душе функциональный стиль, но для каждой задачи нужен свой инструмент.
Извиняюсь, я понял, о чём вы. По глупости принял на свой счёт.
Проблема померять эту диагональ... если продолжать в таком же шуточном духе - вы можете попробовать сделать линейку для того, чтобы эту диагональ измерять
Вы что, правда ТАК делаете? Не хотел бы я поддерживать ваш код. Вы используете наследование явно не по назначению.
> Проблема померять эту диагональ
Зачем вам её мерить? она в точности равна корню из двух.
Думаю, дискуссия себя исчерпала.
Учите матчасть, у меня нет больше ни малейшего желания объяснять такие вещи.
Может вы еще и правильный семиугольник построите заодно, ну, чтобы человечество освободить от еще одной, казалось бы неразрешимой проблемы? :D
Отметить можно только приблизительно - в этом и заключается проблема. Т.е. если у нас линейка будет в сантиметрах, дюймах или еще чем, то корень из двух сантиметров на ней никак не отметить. Обратное тоже справедливо - если у вас будет линейка, на которой вы бы отмечали только значения кратные корню из двух сантиметров, то целые или дробные значения в сантиметрах вы бы не могли точно отметить на той же линейке. Конечно, для каждой ситуации можно [попытаться] добиться результата с приемлимой точностью, но абсолютно точно - не получится.
Попробуйте представить 2 сантиметра точно дюймовой линейкой.
И я сомневаюсь, что вы держали в руках линейку, точность делений которых меньше 1e-17 (для сантиметровой это много меньше размера ядра атома).
Это невозможно потому, что что бы вы ни отметили на линейке будет целым числом каких-то минимальных ее составляющих. Иррациональные числа, по определению не могут быть представлены таким способом. Т.о. если у вас будет идеальная линейка, то, если вам нужно будет измерять что-то, что являестя рациональным числом по отношению к делению этой линейки, то, потери точности не будет. Но та же самая линейка не будет точно измерять то, что по отношению к делению этой линейки ялвяется иррациональным числом.
точность, однако, является также числом конечным, а для представления иррационального числа нужна бесконечная точность - таким образом, на линейке будет представлено рациональное число, с точностью до некоторого числа цифр после запятой совпадающее с нужным иррациональным.
ни один физический измерительный прибор не может быть бесконечно точен.
даже эталон килограмма и тот допускает минимальное отклонение веса.
Вы можете точно сказать, деления логарифмической линейки рациональны или иррациональны?
Если линейка идеальная, то любое число, хоть целое, хоть иррациональное, хоть трансцендентное, на ней отложить можно (и «отложить число» — значит отложить отрезок, в определённое число раз отличающийся от единичного, а длина этого единичного может быть иррациональной относительно другого). Если же линейка реальная, физическая, то любая отметка нанесена на ней с определённой точностью, и единица не точнее корня с двух.
Магистро велемуро штангенциркуль членомеро
Я надеюсь, вам хоть платят достойно за проделанную работу :) Иначе - себя пожалейте :)