Я так понимаю, что Melkij отвечал мне.
В очереди действительно лучше держать адрес файла и требуемое действие. Просто изначально я подумал, что серверы М — это фронтенд, на котором нежелательно держать такие объемы информации. После вашего ответа перечитал постановку задачи, дошло, что М — это медиа серверы для хранения больших файлов.
Вы, наверное, хотели сказать «с кириллицей». Я как-то не пробовал вводить туда адрес руками (например, если вы скопируете ссылку, содержащую кириллицу, из адресной строки, то она уже будет закодирована в номальный урл)
Конечно. Иначе вы не могли бы получить объект из HashMap. Object value = map.get(«key»), здесь «key» — это новая строка, и если бы её хэш код отличался бы, то вы бы не смогли получить значение value.
Ну во-первых, это не совсем SaaS, это просто услуга. Вот если бы вам за абонентскую плату давали пользоваться каким-либо софтом — тогда это был бы SaaS.
Во-вторых, я вам карму не снижал (и не повышал), я минусую карму только за хамство. Причем необоснованно обвинять меня в том, что я поступаю не по мужски — это хамство, но на первый раз минусовать вам карму не буду, раз уж вы за неё так переживаете.
Да, возможность есть, но только у админа, а хочется, чтоб у каждого пользователя была своя админка, где он управляет только своими товарами. Конечно, можно регистрировать продавцов, как админов с ограниченными правами, но это костыль.
Код в принципе нормальный, но есть несколько замечаний:
Нет модификаторов доступа у полей класса. Принято все поля класса делать private
Нежелательно все поля класса начинать с символа 'm' (это наверное сокращение от member), т.к. это затрудняет чтение. IDE всегда подсвечивает поля класса, поэтому данную традицию именования можно считать устаревшей
Нет модификаторов доступа у некоторых методов (может у вас это так и задумывано, но обычно область видимости ограничивают явно)
Методы слишком длинные. При этом непонятно, что они делают. Возьмем например метод onReceive(). Гораздо правильнее было бы не превращать его в простыню кода, а сделать так, чтоб он состоял из нескольких вызовов private методов с очень понятными именами, а эта простыня была бы разбита на части и спрятана в этих методах, которые в свою очередь тоже можно разбить на методы с понятными именами. Сейчас читать метод onReceive() довольно тяжело
Принято вверху класса располагать public методы, потом protected, а в самом низу private. Так легче понять, за что отвечает класс
К публичным методам очень желательно иметь javadoc. Если он написан в интерфейсе или родительском классе, то в javadoc'e просто укажите {@inheritedDoc}
Public метод dump не использует 2 из 3 аргументов. Так нельзя. Каждый лишний аргумент в паблик методе — это головная боль для программера, который будет его вызывать
Наверняка это не весь список, но уже есть чем заняться :) Многие советуют читать «Совершенный код» МакКоннела и «Clean code» Мартина. Мой вам совет — прочитайте первые 30 страниц Clean code, и вы сами будете видеть, хороший это код, или в нем есть что исправить.
Удачи!
Я не совсем понял, почему вы противопоставляете эти 2 перпендикулярных понятия? Вы спокойно можете создавать Singleton и передавать его через инверсию зависимостей (aka Inversion of Control, Dependency Injection).
Если вы знакомы с таким джавским фреймворком как Spring, то там как раз все создаваемые объекты, которые вы потом будете инжектить в другие объекты, являются синглтонами по умолчанию.
