PHP включает по сравнению с ООП
Предполагая, что ваш массив отсортирован (например, тот, который вы опубликовали), вы можете просто перебирать массив и считать самый длинный сегмент элементов, это что-то вроде сообщения @ narek.gevorgyan, но без ужасно большого массива, и он использует тот же объем памяти независимо от размера массива:
private static int getMostPopularElement(int[] a){
int counter = 0, curr, maxvalue, maxcounter = -1;
maxvalue = curr = a[0];
for (int e : a){
if (curr == e){
counter++;
} else {
if (counter > maxcounter){
maxcounter = counter;
maxvalue = curr;
}
counter = 0;
curr = e;
}
}
if (counter > maxcounter){
maxvalue = curr;
}
return maxvalue;
}
public static void main(String[] args) {
System.out.println(getMostPopularElement(new int[]{1,2,3,4,5,6,7,7,7,7}));
}
Если массив не отсортирован, сортируйте его с помощью Arrays.sort(a);
6 ответов
Это не действительно противоположный выбор. Необходимо будет включать код проверки так или иначе. Я считал Ваш вопрос как процедурное программирование по сравнению с программированием OO.
Запись нескольких строк кода или функции, и включая его в Вашем верхнем колонтитуле страницы состояла в том, как вещи были сделаны в PHP3 или PHP4. Это просто, это работает (это - то, как мы сделали это в osCommerce, например, приложении PHP электронной коммерции).
Но не легко поддержать и изменить, как многие разработчики могут подтвердить.
В PHP5 Вы записали бы пользовательский объект, который будет нести его собственные данные и методы для аутентификации. Ваш код будет более четким и легче поддержать, поскольку все имеющее отношение к пользователям и аутентификации будет сконцентрировано в единственном месте.
У меня нет большого опыта PHP, хотя я использую его в своем текущем задании. В целом я нахожу, что большие системы извлекают выгоду из удобочитаемости и понятности, которую обеспечивает OO. Но вещи как непротиворечивость (не смешивают OO и неOO) и Ваши персональные предпочтения (хотя только действительно на персональных проектах) также важны.
Я никогда не не учился использовать include в PHP кроме внутренней части оперативные библиотеки, которыми я пользуюсь и одно центральное include из этих библиотек (+ конфигурация) в приложении. Все остальное обрабатывается глобальным __autoload обработчик, который может быть настроен для распознавания различных необходимых классов. Это может быть сделано легко с помощью соответствующих соглашений о присвоении имен для классов.
Это не только гибко, но также и довольно эффективно и содержит архитектуру в чистоте.
Можно ли быть немного более конкретными? Для примера Вы даете Вам, должен использовать, включают обоими способами. В случае, если 1 Вы только включаете файл, в случае, если 2 необходимо включать файл класса (например, user.class.php) для разрешения инстанцирования Пользовательского класса.
Это зависит, как остальная часть приложения создается, это OO? Используйте OO.
В то время как вопрос затрагивает несколько очень спорных проблем (ООП, Аутентификация пользователя), я пропущу те и комментарий второго Konrad о __ автозагрузка. Любой, кто знает C/C++, знает, сколько из боли включая файлы может быть. С автозагрузкой, дополнением PHP5, если Вы принимаете решение использовать ООП (который я делаю почти исключительно) Вы только должны использовать некоторое стандартное соглашение о присвоении имен файла и (я рекомендовал бы), ограничение единого класса на файл и PHP сделает остальных для Вас. Очищает код, и Вы больше не должны волноваться о том, чтобы не забывать удалить, включает, которые больше не необходимы (одна из многих проблем с включает).
Делаете ли Вы это в классах или в более процедурном стиле, просто необходимо проверить, чтобы гарантировать что:
- Существует сессия;
- То, что сессия допустима; и,
- То, что у пользователя, владеющего сессией, есть надлежащие полномочия.
Можно инкапсулировать все три шага в одну функцию (или статический метод в классе Сессии мог бы работать). Попробуйте это:
class Session
{
const GUEST = 0;
const SUBSCRIBER = 1;
const ADMINISTRATOR = 2;
public static function Type()
{
session_start();
// Depending on how you use sessions on
// your site, you might just check for the
// existence of PHPSESSID. If you track
// every visitor with sessions, however, you
// might want to assign some separate unique
// number (that you can track in a DB) to
// authenticated sessions
if(!$_SESSION['uniqid'])
{
return Session::GUEST;
}
else
{
// For the best security, don't store the
// user's access permissions in the $_SESSION,
// but rather check against the DB. This will
// ensure that recently deleted or downgraded
// administrators will not be able to make use
// of a previous session.
return THE_ACCESS_LEVEL_ACCORDING_TO_THE_DB
}
}
}
// In your files that need to check for authentication (you
// could also do this in a controller if you're going MVC
if(!(Session::Type() == Session::ADMINISTRATOR))
{
// Redirect them to wherever you want them to go instead,
// like a log in page or something like that.
}