Deerenaros: необязательно торговать валютой, то что вы говорите, это торговля в лоб, даже мне, ею не занимающемуся, понятно что все "лобовые" способы, исчерпывают себя первыми. Моя задача была написать анализатор для биржи ценных бумаг, название сейчас уже не вспомню, а так как программа работала с запланированными махинациями, новости на них слабо влияли.
Deerenaros: Туралъ:
все не так плохо.... сам лично таким не занимался, но слышал давно объяснения пари людей что занимались, говорили примерно следующее.
В каким то там университете, сделали мега крутую финансовую модель, она учитывала кучу всего и предсказывала все что только можно и абсолютно неверно. Модель исходила с того что все участники рынка разумны, а это совсем не так.
В общем есть два вида ботов, первый вид это когда вы делаете пачку ботов с разными алгоритмами, даете каждому денег и смотрите кто справляется лучше, причем периодически фавориты меняются - это слышал, но не разу не видел.
Второй способ, пару лет назад разрабатывал такую штуку для одного заказчика, там суть в том что компании мухлюют со своими активами, особенно крупные, но люди ленивы и мухлюют всегда одинаково, как оказалось, часто даже по расписанию. Суть сводилась в том, что бот искал таких ленивцев по некоторым признакам и указывал на них оператору, а тот зная как было в прошлом, играл на том что в будущем все сделают также.
Дмитрий: это невозможно понять работая одному, над один проектом. Вы уж явно читали о том зачем нужен ооп, но не придали значения указанным фактам, и то что весь мир работает на ооп вас не расшевелило.
Вам нужна команда, или проект к которому вы вернетесь только через месяца два работы над другим проектом. Иначе никак, нового вам ничего, кроме того что уже читали, о ооп я вам не скажу.
Дмитрий: тогда должны понимать что любой ваш код будет факапом, за переменные и функции в глобале ,даже новичкам руки отрывают, ни одна нормальная контора даже до собеседование не допустит.
Дмитрий: вы говорите о пхп, он изначально ущерблен в плане производительности =)
ООП не для того, он для читабельности и удобства рефакторинга.
А паттерны, это стандартное решение стандартной ситуации, он не для конекта к бд, он для решения определенной ситуации в коде.
Синглтон в частности нужен когда надо получить однообъектный класс, с единой точкой входа.
Если вы не используете паттерн, значит он вам ненужен или вы о нем не знаете.
Скажите, вот эти все функции что вы описываете, function connect() например, вы понимаете что они в глобальной области видимости? Вы используете классы?
HoHsi: В большинстве проектов что видел, разбивали на несколько приложений и сообщали их через фронт, но это как понимаете не то. Сокеты позволят вам наладить нормальную двух стороннюю связь, в конце концов, все эти протоколы просто надстройки над сокетом, потому используйте просто то что вам удобно для текущей задачи.
function connect(){
$db = mysqli_connect('localhost','aa','bb','cc');
return $db;
}
где тут проверка?
> то после окончания её работы соединение перестанет существовать и в другой мне всё равно придётся подключатся
А в синглетоне соединение продолжает существовать, и когда вызову функцию второй раз, она вернет уже существующее соединение, а не создаст новое..
Дмитрий: ну окей, вы вызвали функцию\не вызвали, понятно.
А вот у вас две функции, обе использую бд, и о могут сработать обе, а может быть запущено только одна из них, причем вы не знаете в какой последовательности.
Если вы используете функцию второй раз, то установите второе соединение к бд, а потом вам еще эту переменную надо передавать кудато, а я напишу так
DB::obj()->`и тут любые функции работы с бд`
и это будет синглетон, потому что:
я могу хоть 10 раз вызвать DB::obj(), хот в пределах одной функции, хоть в пределах 100 разных функций,в каждой по 10 раз - это всегда будет то самое соеденение, что было создано, когда я первый раз написал DB::obj(). И даже если я в этой переменной что-то поменяю, то это поменяется во всех вызовах DB::obj().
Это будет точка входа, потому что:
Я всегда пишу DB::obj(), и оно всегда работает как надо, и мне никогда не надо писать что либо другое или какие либо дополнительные проверки(установлен уже коннект или нет), все эт опроверяеться где-то там внутри точки входа и я не вспоминаю даже об этом.
Это не будет глобальной переменной, так как:
DB::obj() это обращение к свойству класса, а не к глобальной переменной
Я не могу поломать случайно коннект к бд, так как:
DB::obj() функция возвращающая объект, перезаписать который я не могу, могу только использовать.
1.3 любая переменная иди функция, написанная не в классе, попадет в глобальную область видимости.
Про спл автолоад я имел ввиду что не подключаю классы руками, только задаю где их искать.
Дмитрий: кстати еще один момент, вот вы передаете переменную по коду, а если одна из функций поменяет что-то в коннекте к бд(что вы сами разрешили менять), как вы передадите измененную $db, в другой модуль.
1. Данный паттерн без этого не реализовать(причины уже указивал в посте). Что до остального, объект это понятие из ооп программирования и подразумевает под собой весьма конкретную вещь. Да конект к бд у вас установлен, а если это статическая страница, и бд ненужна, как вы предотвратите ненужное соединение с бд?
1.1 Точка входа обычно подразумевает некую стандартизированную возможность доступа, как вы сами написали, вам для доступа эту переменную надо передавать, точка входа не передается по коду, она всегда доступна к вызову с одной функции, а сделать это для обычной переменной или функции, можно только через глобальную область видимости, что само по себе недопустимо в нормальном проекте.
1.3 я использую спл автолоадер, в каждом файле у меня класс, и все переменные заключены в свои классы, со своими областями видимости, ни одной переменной или функции в глобале нет. Единственное что доступно мне с любой точки кода это классы и их неймспейсы, что есть нормальной практикой для ооп.
