Если регулярка - это не жесткое условие, то это все можно сделать так
1.1 простой strlen
1.2 первый символ не пробел $str[0] !== '<пробел>'
2. поиск по строке "<пробел><пробел>" == false
3. if(russian_exists() && english_exists()){ ERROR(); }
API для Яндекс.Перевод я настроил. Для гугла тоже есть свой граббер перевода. А вот для translate.ru нет. Просто тематический перевод у промпта получается лучше иногда чем у гугла.
Ясно, тогда попробуйте так (банальный способ)
1. включаем firebug
2. заходим на translate.ru
3. переводим firebug на просмотр запросов (Network в Google Chrome)
4. выбираем нужные языки, вводим что переводить
5. нажимаем на кнопку перевести и отлавливаем отправку запроса в панели firebug
6. эмитируем запрос у себя
7. всё
Сущность уже подразумевается самим автором, так что я предложил её сделать более "реальной". Никаких преград для этого на данном этапе не наблюдается + сложности лишней не вносит
предложения и замечания:
1. методы лучше назовите глаголами. С Save::save() все окей, но вот с Calculator::calculator() как-то не очень, лучше назвать calculate
2. В методе Save::save() ещё понятно почему возвращается true/false, но почему у метода Calculator::calculator возвращается true/false?
Вопросы по схеме:
1. Объясните назначение Save_Product, Save_Product_Insurer, Calculator_Product, Calculator_Product_Insurer, Contrac_ProductInsurer. Если это сделано "на будущее" - уберите сейчас же, это усложняет процесс проектирования и разработки, в дальнейшем с помощью тестов, рефакторинга и времени сможете изменить абстракции.
2. Посмотрел внимательнее на схему. Где вы ещё будете использовать интерфейсы Calculator, Save? Может стоит пока убрать их из схемы, чтобы не мешались? (Как и в п.1 все это можно будет вернуть)
AmsTaFF
А вы пробовали запускать это? (Добавление) geni_student
Не страдай фигней, а лучше почитай http://www.php.net/manual/ru/array.sorting.php
http://php.net/manual/ru/language.control-structures.php
ойй.... что это я ... прошу прощения, неправильно да и вообще удалю ка я...
Если взять связку П1 + CК1 то получим договор по Продукту 1 у Страховой компании 1 или П1 + СК2.
Связка может быть любая, главная чтоб были 2 сущности П и СК.
Почему бы вам не внести ещё одну сущность Договор Д1? он как раз будет связывать две сущности П1+СК2
я бы посоветовал отдать ответственность за сохранение договора какой-нибудь одной сущности.
Это относилось к
Djos пишет:
Сохранение может быть как у Продукта, так и у Страховой Компании
И означало что пускай кто-нибудь один класс будет заниматься этим делом, а не оба. Т.к. это повлечет копирование кода и прочие прелести
Djos пишет:
Расчет( Calculator ) - считает стоимость договора. Расчет может полностью на нашей стороне или на стороне СК.
Сохранение( Save ) - сохраняет договор. Сохранение происходит на нашей стороне, и на стороне СК.
Составьте интерфейс этих двух классов, какие у них будут методы, что они будут принимать, что возвращать.
AmsTaFF пишет:
P.S. что продукт может сохранять договор...
Сам не помню почему такой текст получился
Djos пишет:
2. Учусь.
Тогда напишите пожалуйста с методами (открытых будет достаточно)
я конечно не большой знаток mysqli, PDO. Но PDO использовал бы уже за тем, что он поуниверсальнее, нету привязки к конкретным методам. + Он используется очень многими "сильными" пакетами, как Doctrine2. Так же он используется в PHPUnit (если не ошибаюсь, где-то в части тестов БД).
Не говорю что это его явные плюсы, но как я и сказал, уже за эти пункты я бы выбрал PDO
Если лень разбираться в апачах, нгинксах, и прочем а надо просто взять и поставить сайт или два - то стоит выбрать хостинг, там все управляется через панель и работы мало.
Если же хотите "полазать" в нгинксах и прочем, и вы хотите "тонко" все сами настраивать - берите VPS.
P.S.
Мощности хостингов обычно ограничены чем-то. "Мощности VPS - нет" (просто повышая мощность вам уже будет выгодно брать полноценную машину, но при этом взаимодействие с машиной никак не изменится)
P.P.S.
Ну и конечно решайте сами, почитайте статьи в интернете