я сам пользователь андроида, первый месяц мучался жабой, а потом откопал у мегафона опцию «оптимальный интернет» (см ответ выше) и сейчас не заморачиваюсь
Путь правильный, только чуть-чуть не додумали. Кроме двух неочевидно необходимых интерфейсов, попали еще и на дополнительные циклические связи: если энум в одном джаре, веб в другом, а шедулер — в третьем, то ничего путного так не соберется.
Визитор (в разных видах) имхо самый элегантный способ решения проблемы декаплинга с одной стороны и компайл тайм гарантий что ничего не забыто с другой. В данном случае, к примеру, можно было бы сделать так: энум реализует интерфейс (возможность джавы, о которой незаслужено забывают) с одним методом accept(DocumentStatusVisitor). DocumentStatusVisitor — это интерфейс, объявленный в том же модуле, что и энум и в нем мы переходим от энума (конструкции процедурной) к методам (конструкции ООП) — для каждого элемента энума создаем именной метод, к примеру visitNew(), visitDraft(),… Ну что написать в имлементациях метода accept в энуме я думаю понятно.
Таким образом мы избавляемся от лишних депенденсий (энум больше не должен знать кто там и как его использует), получаем возможность держать моули раздельно, уменьшаем кол-во интерфейсов и связей.
у мегафона как раз таки инет вроде достаточно ничего так — рубль за мегабайт с округлением по 100кб, да еще и в роуминге по России вроде как не дорожает (во всяком случае, не больше дефолтных 7р)
это проблема не джавы, а конкретного подхода к разработке: эмуляция кода при помощи более высокоуровневых средств (xml, к примеру). Это не всегда зло, но фанатизм в любом виде приводит к проблемам.
Вопрос: а в чем выражается «при поддержке компании Google»? А то я читал-читал и так и не понял, сложилось впечатление, что гугл тут только постольку, поскольку гугловые инструменты предлагается использовать.
имхо еще google listen очень удобная софтинка — интегрируется с google reader и выкачивает на телефончик подкасты
я так подкасты с japanesepod101.com слушаю
Вы немного путаете, как устроено ассиметричное шифрование.
Если исходить из того, что Вы сделали ключ, зашифровали публичным и куда-то отправили, а с той стороны нужно расшифровать, то то, что Вы говорите — имеет смысл.
Однако, обычно все происходит сосем иначе =)
Ваш корреспондент передает вам СВОЙ публичный ключ, Вы шифруете этим публичным ключем свое письмо и отправяете. Ваш корреспондент использует СВОЙ закрытый ключ для прочтения, который он никому никак не передавал =)
>> модульность кода может достигаться за счёт использования указателей на объект
не понял мысль
>> а вот класс не всегда знает свои зависимости, допустим если один и тот же класс работает с разными базами данных
>> тогда только 2 решения — или прокси на нужную базу или указатель на синглет работы с БД
решение в духе ООП для такой ситуации — это интерфейс
синглтон для этого не нужен. Интерфейсов в пхп для БД много — PEAR::DB, adodb…
Когда количество синглтонов в проекте расте пропорционально сложности и размеру, стоит пересмотреть подход к архитектуре, т.к. подобный способ ломает модульность кода и сильно мешает юнит тестированию.
По-хорошему, класс должен сам знать все свои депенденси, так что особой нужды в жутких количествах синглтонов нет.
>> как это повлияет на политику Google относительно Google Answers.
а как это может повлиять? Google Answers уже 3 года как закрыт. Навряд ли сервис откроют.
Странно, что они сначала свой такой сервис убили, а теперь чужой — купили…
бтв, я ошибся, там как раз округление до 1кб
Визитор (в разных видах) имхо самый элегантный способ решения проблемы декаплинга с одной стороны и компайл тайм гарантий что ничего не забыто с другой. В данном случае, к примеру, можно было бы сделать так: энум реализует интерфейс (возможность джавы, о которой незаслужено забывают) с одним методом accept(DocumentStatusVisitor). DocumentStatusVisitor — это интерфейс, объявленный в том же модуле, что и энум и в нем мы переходим от энума (конструкции процедурной) к методам (конструкции ООП) — для каждого элемента энума создаем именной метод, к примеру visitNew(), visitDraft(),… Ну что написать в имлементациях метода accept в энуме я думаю понятно.
Таким образом мы избавляемся от лишних депенденсий (энум больше не должен знать кто там и как его использует), получаем возможность держать моули раздельно, уменьшаем кол-во интерфейсов и связей.
я так подкасты с japanesepod101.com слушаю
Если исходить из того, что Вы сделали ключ, зашифровали публичным и куда-то отправили, а с той стороны нужно расшифровать, то то, что Вы говорите — имеет смысл.
Однако, обычно все происходит сосем иначе =)
Ваш корреспондент передает вам СВОЙ публичный ключ, Вы шифруете этим публичным ключем свое письмо и отправяете. Ваш корреспондент использует СВОЙ закрытый ключ для прочтения, который он никому никак не передавал =)
не понял мысль
>> а вот класс не всегда знает свои зависимости, допустим если один и тот же класс работает с разными базами данных
>> тогда только 2 решения — или прокси на нужную базу или указатель на синглет работы с БД
решение в духе ООП для такой ситуации — это интерфейс
синглтон для этого не нужен. Интерфейсов в пхп для БД много — PEAR::DB, adodb…
По-хорошему, класс должен сам знать все свои депенденси, так что особой нужды в жутких количествах синглтонов нет.
а как это может повлиять? Google Answers уже 3 года как закрыт. Навряд ли сервис откроют.
Странно, что они сначала свой такой сервис убили, а теперь чужой — купили…