Зто называется кто-то у кого-то позаимствовал если 80% «правил» буква-в-букву совпадают. Те правила были введены раньше 2004 года, вот мне интересно откуда взял их ТС.
А откуда вы взяли эти правила? Дело в том, что в предыдущей компании где я работал были зафиксированы примерно подобные принципы, причем часть пунктов точно в такой же формулировке.
Если будет 100500 вариантов поиска, то будет и отдельный контроллер который будет искать, но не коллекция. Внутри API, out-of-scope of API — дело десятое на самом деле.
>чем делать так чтобы в ней «всё было» и тащить весь ненужный функционал.
Тащить «все» не нужно. Нужно сделать минимальное API, дать пользователям и прислушиваться к тому что они хотят.
Для мобильных приложений все равно впринципе. Если код не вызывается, то максимум что он потребляет — это память под codebase в RAM и на диске. На крайняк можно resource-consuming фичи делать отключаемыми (если пользователю они прям щас не нужны, он может их отключить).
Простите, а что здесь хлам? Пользователи просят, значит им это нужно. Более того, могут запросто поменяться требования и вы вынуждены будете добавлять свойства к коллекции.
Насчет внешних навесов — в случае с поиском, например, коллекцию нужно будет _заново_ проиндексировать, хотя это совершенно не нужно если использовать внутри hashmap и дать наружу метод searchByTitle.
Кстати, раз вы уж прицепились к коллекциям. Custom коллекции часто нужны потому что коллекция уже сама является Business level Entity. Например представим что у вас есть две сущности: Playlist и AudioUploadQueue. В обоих случаях можно представить в виде Collection<Audio>. Но! При этом из кода совершенно нельзя будет сказать что это за сущность, если не видеть как она используется. Более того, никто не запретит использовать upload queue вместо Playlist и наоборот. CustomCollection лишает пользователей API такой возможности.
Все становится гораздо более печально если начинают использовать List<String>, Map<String, String>, Map<String, List<String>> и ему подобные. Нет лучше метода обфуцировать код.
А потом вас пользователи попросят добавить возможность искать Audio по Title-у например. И что вы будете делать? В предложеном мною интерфейсе достаточно добавить метод (ну или за-extend-ить) и поправить реализацию (перейти с ArrayList на Hashmap например).
Ох, где ж вы раньше были :) У меня точно такая же магическая проблема с Athlon 5000+ возникла. Решил ее покупкой Phenom-а :) Благо мать позволила поставить его.
Ну так оценивайте свое дело и свое умение в реальных USD и часах. Но мне бы, чесслово, было бы странно выставлять клиенту счет баксов на 10.
Но тут еще второй момент. «Или все таки за результат?». А что считать результатом? Формально соблюденные пункты ТЗ? Не смешите мои тапочки. Если клиент неудовлетворен — он вам может и заплатит, но в следующий раз точно не придет.
Это как с хирургом. Операцию сделали — сделали. Аппендицит удалили — удалили. А то что шов ужасный получился — ну извините. Идите к пластическому хирургу. Или еще раз денежку мне заплатите — мое королевское величество может вам что и поправит.
ЗЫ как и любая аналогия, аналогия с хирургом — хромает. Ибо к программистам обращаются регулярно и делают что-то для бизнеса. А к хирургу — в экстренной ситуации и единожны.
Скажу банальность, но не стоит быть таким жадным и работать с неадекватными заказчиками :)
Это во-первых. А во-вторых — воспитывайте заказчиков в том русле что за работу нужно платить.
>уговоры\напоминания о том, что «в прошлый раз же помогли»
Ну дайте раскладку по часам. В первом случае — пять минут и ноль рублей. Во втором случае день/два/неделя и X рублей. Раскладка ессно должна быть реальной и соответствовать тому как и за сколько вы сделаете.
Ну в вашем случае все очень просто. Первую работу можно сделать и бесплатно. А на вторую выставить счет. Опять же, во втором случае человек узнает сколько это стоит и еще пять раз подумает, а надо ли.
Если уж на то пошло — дачный домик — не пять минут рисовать.
А насчет таксиста — другой пример. Как-то я ехал и у меня было всего 150 рублей при цене поездки в 170. Еще была тысяча в кармане. Таксист вместо того, чтобы отправить меня менять тысячу просто взял меньше. Да, имел право не брать. Да, это моя обязанность оплатить проезд полностью. Но помимо всего этого есть и человеческие отношения. Которые долго выстраиваются и дорого стоят. Надо ли говорить, что с этим такси я езжу уже года три и свою двадцадку они уже давно отбили.
По поводу десяти минут работы: даже при рейте в 100$/час это 17 долларов. При этом за эту сумму вы можете приобрести лояльность и благосклонность клиента. По-моему оно того стоит.
Гм. А почему бы не поправить? Если это отнимет минут пять-десять, а человеку будет приятно. В конце концов он потом лучше пойдет к вам а не к Васе, который делает конечно дешевле, но за каждую мелочь потом дерет.
Это бизнес. И в бизнесе приходится работать не с абстрактными компаниями а с конкретными людьми. Так почему бы этим людям не делать приятно, закладывая базу плодотворного сотрудничества?
Ох, т.е. все эти паникеры которые орут «ааа, приватность! вконтакте нильзя удалить страничку» — им влом если что дойти до нотариуса? Не смешите мои тапочки. Значит так оно им надо.
>чем делать так чтобы в ней «всё было» и тащить весь ненужный функционал.
Тащить «все» не нужно. Нужно сделать минимальное API, дать пользователям и прислушиваться к тому что они хотят.
Для мобильных приложений все равно впринципе. Если код не вызывается, то максимум что он потребляет — это память под codebase в RAM и на диске. На крайняк можно resource-consuming фичи делать отключаемыми (если пользователю они прям щас не нужны, он может их отключить).
Насчет внешних навесов — в случае с поиском, например, коллекцию нужно будет _заново_ проиндексировать, хотя это совершенно не нужно если использовать внутри hashmap и дать наружу метод searchByTitle.
Кстати, раз вы уж прицепились к коллекциям. Custom коллекции часто нужны потому что коллекция уже сама является Business level Entity. Например представим что у вас есть две сущности: Playlist и AudioUploadQueue. В обоих случаях можно представить в виде Collection<Audio>. Но! При этом из кода совершенно нельзя будет сказать что это за сущность, если не видеть как она используется. Более того, никто не запретит использовать upload queue вместо Playlist и наоборот. CustomCollection лишает пользователей API такой возможности.
Все становится гораздо более печально если начинают использовать List<String>, Map<String, String>, Map<String, List<String>> и ему подобные. Нет лучше метода обфуцировать код.
Что делать в случае с Collection?
public interface Audios {
Audio get(int i);
int count();
}
А то попортят коллекцию. Можно конечно Iterable наружу выставить, но с условием что Iterator обернут и не дает вызвать remove();
Но тут еще второй момент. «Или все таки за результат?». А что считать результатом? Формально соблюденные пункты ТЗ? Не смешите мои тапочки. Если клиент неудовлетворен — он вам может и заплатит, но в следующий раз точно не придет.
Это как с хирургом. Операцию сделали — сделали. Аппендицит удалили — удалили. А то что шов ужасный получился — ну извините. Идите к пластическому хирургу. Или еще раз денежку мне заплатите — мое королевское величество может вам что и поправит.
ЗЫ как и любая аналогия, аналогия с хирургом — хромает. Ибо к программистам обращаются регулярно и делают что-то для бизнеса. А к хирургу — в экстренной ситуации и единожны.
Это во-первых. А во-вторых — воспитывайте заказчиков в том русле что за работу нужно платить.
>уговоры\напоминания о том, что «в прошлый раз же помогли»
Ну дайте раскладку по часам. В первом случае — пять минут и ноль рублей. Во втором случае день/два/неделя и X рублей. Раскладка ессно должна быть реальной и соответствовать тому как и за сколько вы сделаете.
А насчет таксиста — другой пример. Как-то я ехал и у меня было всего 150 рублей при цене поездки в 170. Еще была тысяча в кармане. Таксист вместо того, чтобы отправить меня менять тысячу просто взял меньше. Да, имел право не брать. Да, это моя обязанность оплатить проезд полностью. Но помимо всего этого есть и человеческие отношения. Которые долго выстраиваются и дорого стоят. Надо ли говорить, что с этим такси я езжу уже года три и свою двадцадку они уже давно отбили.
По поводу десяти минут работы: даже при рейте в 100$/час это 17 долларов. При этом за эту сумму вы можете приобрести лояльность и благосклонность клиента. По-моему оно того стоит.
Это бизнес. И в бизнесе приходится работать не с абстрактными компаниями а с конкретными людьми. Так почему бы этим людям не делать приятно, закладывая базу плодотворного сотрудничества?