Проблема ветвлений

Статус
В этой теме нельзя размещать новые ответы.

Perfilev

Новичок
Проблема ветвлений

Ни раз возникала проблема ветвлений и проблема длинных участков ветвлений. Может кто лучше меня решает данную задачу, прошу совета.
Например нужно разпарсить запрос и дать управление нужно ветке скрипта.
Сейчас использую switch. Получается что-то типа:
PHP:
switch($action)
{
	case 'news':
		switch($subj)
		{
			case 'tech':
			...
			много строк текста
			...
			break;
			case 'eco':
			...
			много строк текста
			...
			break;
		}
	break;
	case 'text':
		...
		много строк текста
		...
	break;
	case 'forum':
		...
		много строк текста
		...
	break;
	case 'admin':
		...
		много строк текста
		...
	break;
}
т.е. первоначальное ветвление растягивается порой на сотни строк.
Что посоветуете? Все-таки выносить тяжелые куски в функции или есть еще какие-нить варианты?
 

Румата

Новичок
Как минимум - вынести в функции то, где "много строк текста" и постараться сократить свитчи.

"Много строк текста" для разных веток условий не дублируются?
 

Perfilev

Новичок
Автор оригинала: hermit_refined
рефакторинг: в первом приближении - завести по классу на каждый action, далее разбивать на методы, etc.
На самом деле эти свитчи в методе класса уже:)
Класс - модуль системы
Метод - определенные действия модуля
А свитчи используются для последующего ветвления при обработке запроса.



Автор оригинала: dark-demon
Perfilev include тебе в помощь.
ИМХО, неправильно это как-то:)
Или я ошибаюсь?

"Много строк текста" для разных веток условий не дублируются?
Нет
 

jonjonson

Охренеть
На самом деле эти свитчи в методе класса уже
Ну и что из этого? Рефакторинг - это не только "завести по классу на каждый action". Не нравиться отписывать классы или по архитектуре не подходит, так добавь приватные методы вместо много строк текста в этот класс, которые будут выполнять необходимые действия.
 

Фанат

oncle terrible
Команда форума
Что-то не верится, что задача "разпарсить запрос" для разных веток условий не дублируется.
Давай-ка поконкретнее. Вот, скажем, в кейсе "форум" - какой код?
 

Gorynych

Посетитель PHP-Клуба
Re: Проблема ветвлений

Автор оригинала: Perfilev
проблема ветвлений и проблема длинных участков ветвлений
...
т.е. первоначальное ветвление растягивается порой на сотни строк.
Что посоветуете? Все-таки выносить тяжелые куски в функции или есть еще какие-нить варианты?
с некоторого момента лично я очень полюбил использовать конструкцию вида:
PHP:
do {
  код_который_нужно_выполнить

  if ( контрольное_условие_1 ) {
    break;
  }

  код_который_нужно_выполнить_если_контрольное_условие_1_пройдено
} while(false);
собственно, оператор do{..}while(false) здесь служит для задания блока кода, а условия - определяют выход (прерывание) из выполнения блока.
 

Perfilev

Новичок
На приведенный пример особо обращать внимания не стоит, т.к. это я просто так придумал
Вот кусок из реального проекта:
PHP:
switch ($call) {
	case 'newuser':
	...
	заводим нового пользователя
	...
		break;

	case 'login':
	...
	обрабатываем вход в панель управления
	...
		break;

	case 'main':
	...
	главная страница панели
	...
		break;

	case 'deletesection':
	...
	удаляем страницу
	...
		break;

	case 'addsection':
	...
	добавляем
	...
		break;
}
Вот пример из жизни, только в каждом кейсе ещё свитч может стоять, который по следующим параметрам ветвит
 

Фанат

oncle terrible
Команда форума
Perfilev
Значит так.

РАЗУМЕЕТСЯ, единственным решением твоей проблемы является осмысленная структура приложения.

Сделать её осмысленной можно только зная, что приложение делает.
Никаких теоретических ответов, разумеется, на вопрос "как мне из двух сотен строк сделать два десятка", НЕ СУЩЕСТВУЕТ.

поэтому заканчивай приводить здесь примеры из документации по лператору свитч, и приступай к описанию КОНКРЕТНЫХ кусков кода.

Либо ищи решение своих сугубо теоретических проблем в другом месте.
 

Perfilev

Новичок
Хорошо, вот реальный код, как избежать этой дурацкой "лесенки"?
ветка 'editsection':
 

Фанат

oncle terrible
Команда форума
молодец, спасибо.
Как избежать этой лесенки, тебе написали в самом начале.
Научиться писать программы.
Используя процедурный подход. ООП тебе ещё рано.
 

Perfilev

Новичок
Интересно, зачем использовать процедурный подход в системе с десятками модулей, когда есть ООП? ;)
Я спрашивал про то, нормально ли писать десятки методов по нескольку строк, вместо ветвлений по switch-у.
Подскажите, есть ли, по вашему, хорошо реализованные cms с использованием ООП? Можно со ссылками.:)
 

Фанат

oncle terrible
Команда форума
не надо рассказывать нам сказки про "систему с десятками модулей". Модуль у тебя один, в который и напихано все управление сайтом.
Если бы модулей было несколько, то как раз добавление юзеров и добавление страниц было бы в разных.
зачем использовать процедурный подход в системе с десятками модулей, когда есть ООП?
На этот вопрос легко ответить. Людям, которые не понимают смысл ООП, проще пользоваться процедурным подходом. Настоятельно тебе это рекомендую
 

Perfilev

Новичок
это все лежит в модуле admin
каждому модулю сопоставлен класс, а вызовам, которые этот модуль обрабатывает, соответственно, методы этого класса
также есть модули

text
guestbook
catalog
menu
и другие

Не стоит, не поняв всей ситуации и архитектуры системы, кидаться словами про некомпетентность, пытаясь задавить авторитетом на данном форуме, а сказки будете своим детям рассказывать.
Повторю свой вопрос: есть ли, по вашему, правильно написанные cms с использованием ООП?

ps кусок кода, который я выкладывал, был написан полтора года назад для курсовой работы, так что о уровне моего профессионализма по нему прошу не судить
 

Фанат

oncle terrible
Команда форума
ссылки подают в гугле.
а как решить твою проблему, тебе ответили первым же комментарием.
Распечатай и повесь на стенку.
прием окончен

-~{}~ 23.03.07 11:00:

Короче.
Извини за резкость.
Но лучше бы тебе было не говорить про то, что эта вот колбаса с винегретом у тебя в методе класса.

И про то, что никто твою архитектуру со структурой не понимает - тоже не надо было. Нет у тебя потому что никакой архитектуры.
В общем, я испытываю некоторые угрызения совести, и это меня побудило открыть тему обратно. Всё-таки, человек в первый раз пришёл на форум, за консультацией, а я так нехорошо обошёлся.
Поэтому тему я открываю, и можно попробовать начать сначала.
Но только в том случае, если ты правильно будешь оценивать свой уровень. который у тебя вообще никакой.
И вместо "у меня всё есть" будешь отвечать "А подскажите, как это сделать лучше?"

Для начала откажись от поисков CMS, поскольку проблемы у тебя не в организации CMS, а в организации одного модуля, отдельной программы.
Тебе бы гостевую книгу сначала научиться писать продвинутую, а потом уже за CMS браться.

Если ты сочтёшь мои слова не констатацией факта а "попыткой задавить авторитетом", то можешь даже не трудиться что-то писать.
 

Perfilev

Новичок
Вот, теперь другой разговор и общаться можно продуктивно :)
Я как раз совета и спрашивал, хотелось бы знать, как оформить всю кашу по-аккуратнее.
Архитектура моей cms вполне вменяемая, но не про это топик (в ПМ попозже отпишусь).
Сформулирую вопрос так:
как кашу оформить в удобоваримый код?
 

Gorynych

Посетитель PHP-Клуба
Perfilev дично мне через некоторое время всегда становится неудобно читать большую "лесенку". Посему попробую высказать несколько советов, не рассматривая конкретный код.

во-первых, когда лесенка if-ов разростается, где-то в ней есть ветки, которые выполняются только в случае выполнения всех вышестоящих условий.

поэтому я действительно стараюсь обрамлять блок кода циклом do{...} ehile(false), помещая "редко" выполнимый (а по сути - требующий выполнения максимум условий" код в конец блока, и как только какое-то условие невыполняется (не нужно больше ничего делать, потому что такое-то условие не выполнилось) вываливаюсь из цикла, прерывая его выполнение.

во-вторых, switch хороший и довольно правильный оператор множественного ветвления (для того и придуман, собственно), но писание внутри case'а большого количества кода делает эту конструкцию плохо читаемой. Для того чтобы повысить читаемость стоит превращать большие, логически законченные (обработка ситуации "А" или обработака ситуации "Б") под-блоки кода в функции / методы. Функции и методы не обязательно образуются повторяющимися кусками кода. Их еще стоит использовать для повышения читаемости кода, иногда, заключая в функцию блок кода вызываемый даже всего один раз в теле скрипта.
 

Фанат

oncle terrible
Команда форума
ну я ж говорю - первый же ответ:
завести по классу на каждый action, далее разбивать на методы, etc.
то, что у тебя вся эта каша в методе - это не плюс, а минус.
классы надо начинать строить не от глобальных кусков приложения, а наоборот - снизу, от небольших логических структур.
класс подразумевает многократное использование. К примеру, класс работы с БД используется сто раз за приложение.
а класс "каталог" - вещь весьма и весьма спорная.
класс предоставляет другим элементам программы интерфейс для выполнения каких-то действий.
Какой интерфейс предоставляет программе класс "каталог"? вывести каталог? А зачем программе такая радость? Не проще передать управление МОДУЛЮ "каталог" и тот уже пусть сам выврдит, что хочет.

В общем, начинай структурировать свой код как раз снизу.
Лучше всего, повторюсь - пиши гостевую книгу. Не надо лезть в цмс. тебе рано ещё.

-~{}~ 23.03.07 11:24:

Gorynych
Дима. Ну вот опять ты рассматриваешь сферического коня в вакууме, которого тебе привел очередной чайник.
Необходимость длинных кейсов тобой даже не рассматривается.
Отвечаем на вопрос строго, как поставлено. Есть задача сократить кейс - решаем.

А, МОЖЕТ, НЕ ДОВОДИТЬ ПРОГРАММУ ДО ТАКОГО СОСТОЯНИЯ, когда ей потребуются такие хирургические меры?
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху