контролеры - объекты - реализации

[tf]

контролеры - объекты - реализации

пересобрал почти один фрамеворк и хочется услышать мнение о качестве получившегося или что не так или как сделать лучше - ваше теоретическое имхо
обсновая идея в том что существует контролер который в себе содержит объект
котролер отвечает за взаимодействие wеb с внутренним представлением данных в объекте (вызывает необходимые функции объекта, организовавает взаимодейтсвие с ajax, отдает данные пользователю)
объект только чем и занимается как обновляет данные и отдает эти данные котролеру

конечная реализация контролера наследует все свойства базового абстрактного класса
объект тоже наследуется от базового и только переопределяют функции под свою контректую работу

для тестов открыл пока полный доступ на http://tf82.spb.ru/_/test/test.html
там только сейчас какие-то проблемы с stripslashes - не хотят работать а так все функционирует
ну тормазит соотвественно )

 

[whirlwind]

Честно говоря, выглядит не очень понятно.

 

[tf]

whirlwind, угу ((
сейчас обновляю код и потом опишу все подробно что хотел сказать
идея была написать обстрактные, достаточно универсальные классы на страницы админки с использованием ajax (пока что список и страница редактирования) - в примерах классы для отдельной страницы
хотел узнать чужой взгляд на реализацию
там в примере нужно было достаточно много потыкать на кнопки чтобы понять какие запросы выполняются на сервере и при каких условиях
я думал что все легко и понятно чужому взгляду...

 

[whirlwind]

> хотел узнать чужой взгляд на реализацию

Насколько я понял что ты хочешь сделать, лично мне такой подход не нравится

1. "Дыра" может возникнуть с двух сторон
2. Нельзя разделить на два программиста
3. Стороны зависят друг от друга

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

 

[hermit_refined]

sorry, на первый взгляд это всё очень страшно, особенно - "объект":

начиная с имени класса (object__test__test_edit - в кошмарном сне не приснится, правда?), global $sql, и непонятками, почему у нас ровно две "формы" - form и _form, а следовательно - разбросанные всюду кейсы по этим значениям, и -- заканчивая соседством в так называемом объекте - выборки из бд, создания форм, обработки запросов ajax'a, зависимости поведения от $_GET, иным словом - чего там только нет...

как минимум - стоит, например, разбить этот класс на n-классов с более целостным и понятным поведением, где n > 3.

 

[tf]

whirlwind, впринципе вводом выводом у меня занимается отдельный класс форм или ты имел ввиду про html_start_form и им подобные?

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

хотелось бы попробовать

И еще не совсем ясна роль объекта.

я ему отвел роль оператора с данными - сохранить, загрузить, отдать данные

заканчивая соседством в так называемом объекте - выборки из бд, создания форм, обработки запросов ajax'a, зависимости поведения от $_GET, иным словом - чего там только нет...

hermit_refined, вначале там был вообще один класс, но потом посмотрев на него понял что самому уже трудно в куче кода разбиратся
whirlwind, вот собственно почему и два класса - так был разделен функционал

hermit_refined, название длинное исключительно для моего удобства размешения набора классов по разным директориям - класс загружается по своему имени, я их сокращал, но было не удобно - imho
$_GETы пожалуй лучше заменю на $this->uri в контроле, до этого он совершенно другие данные хранил (не $this->uri = $_GET

почему у нас ровно две "формы" - form и _form

этот тот задуманный минимум:
форма _form отвечает за одинаковые данные на разных языках (id, дата размещения новости...)
form - конкретная локализация языка (анонсы, сам текст... к примеру)
в принципе сделано чтобы работало только с одним языком
- если нет таблицы $this->table['form'] в объекте то с формой никаких операций не производится

как минимум - стоит, например, разбить этот класс на n-классов с более целостным и понятным поведением, где n > 3.

к примеру как? что еще вынести?

 

[whirlwind]

перед всем: дроби больше на классы - не прогадаешь. слить в один проще, чем разбить на несколько. Во-втором случае остается много мусора после рефакторинга и появляются некоторые антипаттерны.

> название длинное исключительно для моего удобства размешения набора классов по разным директориям

название должно полно отражать заложенный смысл. Представь что у тебя проект на мегабайт кода состоящий из классов с такими именами. Всего ты просто не в состоянии запомнить, тем более этого и не нужно. Тем более, если ты хочешь получить оценку со стороны или дать комуто еще попользоваться своими классами.


По поводу двух форм - см. паттерн стратегия. Здесь два класса, а не один.

> вводом выводом у меня занимается отдельный класс форм
избавься от $_GET-ов и $_POST-ов и тому подобных. Сделай Request либо InDriver, который можно будет эмулировать длля тестирования.

В объекте у тебя тот же самый пост-гет. Если это аналог эктиврекорд - убери это оттуда. В этом случае кто-то _снаружи_ должен через set/get устанавливать атрибуты.

Разбор экшенов убери и сделай отдельные методы - delete, update, etc. Вызывать эти методы должен кто-то _снаружи_ класса. Если объект - это способ доступа к данным, в нем не должно быть ничего, что не касается доступа к данным. А оно у тебя там в избытке или названия методов вводят в заблуждение. Рассматривая классы, мы прежде всего рассматриваем их интерфейсы, по этому правильно именовать важно!

Выкинь trigger_error и exit и поставь на их место эксепшены.

И вообще, я не согласен с некоторыми товарищами, которые ратуют за импрессивность. Как правило, импрессивность достигается более простым кодом, но в базовом классе из-за этого сильно перегружается интерфейс.

 

[tf]

избавься от $_GET-ов и $_POST-ов и тому подобных.

Разбор экшенов убери и сделай отдельные методы - delete, update, etc

http://phpclub.ru/paste/index.php?show=1588
сейчас сделал над класс обрабочик над модулями, который устанавливает данные $_POST и $_GET для конкретных модулей, а также позволяет реализовать нормальное существование нескольких модулей на одной странице (например блог и превьшки к нему - до этого был костыль ),
разбор экшенов ajax, а также iframe вынесены в него

$_POST & $_GET думаю не стоит сливать в один массив - данные $_GET у меня выступают как разнообразные фильтры что были на предыдуших страницах по которым ходил пользователь и при возврате на них должны сохранятся в исходном виде

И вообще, я не согласен с некоторыми товарищами, которые ратуют за импрессивность. Как правило, импрессивность достигается более простым кодом, но в базовом классе из-за этого сильно перегружается интерфейс.

ну а как инеаче?

-~{}~ 16.12.06 23:01:

whirlwind, можеш пояснить что ты имел ввиду под применением паттерна стратегия
что представляет сам паттерн я понял, но как применять его к моей системе никак не представлю в полной мере ...
как я это вижу:
создать еще два класса для сохранения и загрузки данных из базы
1. (к примеру) class_data
2. class_data_lang extends class_data

думаю, что после этого класс object__test__test_edit прекратит свое существование - разобъектся на эти два класса по формам
а связывающий эти формы функцонал уйдет в верхний уровень - модуль (test__test__modul_edit)
но одна единвенноя пока проблему я вижу - мне нужно чтобы у обоих этих объектов (class_data & class_data_lang) было одно общее свойство - id записи в базе (оно должно быть одинаковым и менятся тоже одинаково)
единственное что пока приходит в голову это создать его в модуле - modul->id и дать ссылки на него в объекты
но может быть существует какоенибуть еще решение?

 

[whirlwind]

> почему у нас ровно две "формы" - form и _form

Просто вынеси каждую из форм в отдельные классы.

PS. последний вариант получше, но лично мне действительно трудно ориентироваться среди названий типа object__test__test_edit. Ну не понимаю я что должен делать класс с таким названием

 

[tf]

трудно ориентироваться среди названий типа object__test__test_edit

а так test1__test2__object_edit ? - меньше просто не могу - надо их хоть как-то различать
test1 - раздел
test2 - подраздел
object_edit - то чем занимается, с короткими мне оч трудно иметь дело
(например blog__paste__object_edit)
две недели работал но потом бросил и все переписал - но это имхо

Просто вынеси каждую из форм в отдельные классы.

выношу, общее свойство для них думаю пока как завести...

 

[hermit_refined]

Полностью согласен по всем пунктам с whirlwind. От себя могу добавить, что вы пишите пока исключительно в процедурном духе, отталкиваетесь не от реальных сущностей, а от того, как бы вам распределить функциональность между различными методами, а последние распределить бы по классам. Поймите - ну не может объект модели называться раздел__подраздел__object_edit, хотя бы потому, что не может ему быть дела ни до раздела, ни до подраздела тем более. Хлеб является хлебом вне зависимости от того, храню я его в хлебнице, холодильнике, у себя в желудке, или режу на кусочки.

Ещё один критерий (более приземленный и, возможно, более понятный, чем возможность написания тестов), от которого стоит отталкиваться - вам должно быть относительно легко (пусть этого никогда и не случится) переписать вашу систему, например, на XML-RPC вариант, или в консольное приложение. Это не должно потребовать какого бы то ни было изменения классов модели.

 

[tf]

Поймите - ну не может объект модели называться раздел__подраздел__object_edit

вам название не нравится и все? какая разница в название объекта, оно никакой роли кроме понимания что это, не играет

-~{}~ 17.12.06 14:04:

От себя могу добавить, что вы пишите пока исключительно в процедурном духе, отталкиваетесь не от реальных сущностей, а от того, как бы вам распределить функциональность между различными методами, а последние распределить бы по классам.

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

 

[john.brown]

оно никакой роли кроме понимания что это, не играет

Вот и остается совершенно непонятно, что за раздел, какой такой подраздел, и что за объект он редактирует

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

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

 

[tf]

упорно хотите использовать get/post

перечитай внимательно http://ru.php.net/manual/en/language.variables.predefined.php
ps/ я тоже хорошо могу вытаскивать слова из контекста
прочти что whirlwind предлагает, с чем я собственно и согласен

 

[cDLEON]

$this->get=$_GET;
$this->post=$_POST;

Бред.
А давай ещё потом сделаем

$post=$this->post;
$get=$this->post;

Ты пишешь как 10-ти летний мальчик, которому дали в руки ручку и показали что ею можно писать.
Нафига делать дубли СУПЕРглобального массива ?

 

[tf]

cDLEON, отстань
иди просветления жди