| |
|
|
| | Начал писать класс управелния пользователем, и вот что думаю:
- Нужно ли делить его на 2 или более классов?
По умолчанию, в классе у меня реализовано несколько методов:
- Методы чтения данных из БД (9 шт).
- Методы записи данных в БД (9 шт).
- Методы проверки данных (9 шт).
Т.е. у меня даные ползователей в БД храняться в 9 таблицах:
- users
- address
- tel
- ... и т.д. всякие разные параметры.
И вот в чем вопрос. Есть две части сайта Общая, и Админ.
В общей части всегда будет создаваться объект класса который будет читать данные из БД. Т.е. 18 методов (методы проверки и методы записи) исползоваться не будут.
А в админ. части все методы будут исползоваться, каждый в своем скрипте.
Меня смущает наличие не используемых лишних 18 методов в общей части сайта. И я думаю может сделать вместо одного класса 3. Т.е. класс чтения данных, класс проверки данных, и класс записи данных. Или все это не критично? | |
| |
|
|
| |
|
|
| |
для: tAleks
(20.07.2007 в 19:53)
| | | Хм... а почему такая большая нормализация? Почему имя пользователя, адрес и телефон не хранятся в одной таблице - это и быстрее и удобнее? Или каждый пользователь имеет несколько адресов и телефонов?
PS Если всё таки решите оставить 9 таблиц, то и классов лучше для них 9 штук сделать и объединить их в едином классе user, т.е. мне кажется тут должно быть 10 классов минимум, хотя я сам бы сделал из 9 таблиц одну, а классов для представления пользователя вообще не использовал - таблица MySQL неплохо и без классов эту сущность представит. | |
| |
|
|
| |
|
|
| |
для: cheops
(20.07.2007 в 20:11)
| | | >Хм... а почему такая большая нормализация? Почему имя пользователя, адрес и телефон не хранятся в одной таблице - это и быстрее и удобнее? Или каждый пользователь имеет несколько адресов и телефонов?
Да, именно так. Пользователи могут иметь не по одному адресу и телефону.
>
>PS Если всё таки решите оставить 9 таблиц, то и классов лучше для них 9 штук сделать и объединить их в едином классе user,
Это как? Т.е. каждый класс работает только со своей таблицей? А как их объединить в один класс? Ведь наследовать класс можно только один раз? Или я че-то не догоняю? | |
| |
|
|
| |
|
|
| |
для: tAleks
(20.07.2007 в 20:17)
| | | 1 от 2, 2 от 3, 3 от 4 <...> | |
| |
|
|
| |
|
|
| |
для: bronenos
(20.07.2007 в 20:38)
| | | Ну тогда я вообще ниче не понимаю.
Как я раньше думал, множественное наследование в PHP не катит.
Сейчас сделал такой тест:
<?php
class c1 {
var $a = 1;
}
class c2 extends c1 {
var $b = 2;
}
class c3 extends c2 {
var $c = 3;
}
class c4 extends c3 {
var $d = 4;
}
$obj = new c4;
echo '<pre>';
var_dump($obj);
?>
|
И это вроде как прокатило! Но ведь множественное наслелование не работает в PHP. Или это не множественное наследование? Если это не множественное наследование, тогда что такое множественное наследование?
Чем дальше в лес, тем все темнее... :(
Кто может - поясните. Буду сильно благодарен! | |
| |
|
|
| |
|
|
| |
для: tAleks
(20.07.2007 в 21:04)
| | | по очереди наследовать или делать свойства объектами | |
| |
|
|
| |
|
|
| |
для: bronenos
(20.07.2007 в 21:18)
| | | >или делать свойства объектами
Как? Можно пример, хотя бы маленький. | |
| |
|
|
| |
|
|
| |
для: bronenos
(20.07.2007 в 21:18)
| | | можно порождать и наследовать интерфейсы - в неограниченном количестве | |
| |
|
|
| |
|
|
| |
для: Trianon
(20.07.2007 в 21:50)
| | | Интерфейсы, честно говоря, я вообще не догоняю зачем они нужны. Ведь они не несут никакой полезной "тяжести", а только говорят о том, какие методы должны быть реализованы. | |
| |
|
|
| |
|
|
| |
для: tAleks
(20.07.2007 в 22:21)
| | | Это для проектирования. | |
| |
|
|
| |
|
|
| |
для: tAleks
(20.07.2007 в 21:04)
| | | Множественное это когда:
class c1 {
var $a = 1;
}
class c2 {
var $b = 2;
}
class c3 extends c1, c2 {
var $c = 3;
}
|
Это запрещено в ПХП.
А то что у Вас, то не множественное. | |
| |
|
|
| |
|
|
| |
для: tAleks
(20.07.2007 в 20:17)
| | | Наследования следует использовать там, где имеется иерархия, здесь иерархии нет. Конечный класс у вас просто должен содержать объекты классов адреса, телефона и т.д. или массивы таких объектов и оперировать ими.
PS Зря мне кажется свзяываетесь с объектно-ориентированным программированием в данном случае - выгоды никакой нет - у вас хоть один класс повторно будет использоваться? Если нет, то добьётесь только трёхкратного увеличения и усложнения кода без всякой для себя выгоды. ООП работает только тогда, когда у вас большая иерархия классов, каждый из которых используется многократно как для наследования, так и внешним кодом. Если каждый класс используется только по одному разу - дешевле, быстрее и надёжнее классы вообще не использовать. | |
| |
|
|
| |
|
|
| |
для: cheops
(21.07.2007 в 11:49)
| | | >
>PS Зря мне кажется свзяываетесь с объектно-ориентированным программированием в данном случае - выгоды никакой нет - у вас хоть один класс повторно будет использоваться? Если нет, то добьётесь только трёхкратного увеличения и усложнения кода без всякой для себя выгоды. ООП работает только тогда, когда у вас большая иерархия классов, каждый из которых используется многократно как для наследования, так и внешним кодом. Если каждый класс используется только по одному разу - дешевле, быстрее и надёжнее классы вообще не использовать.
Да, cheops, вы как всегда правы! Сижу второй день, и вместо упрощения все только усложняется. Оставлю я лучше эту затею, до лучших времен... :)
Спасибо! | |
| |
|
|
| |
|
|
| |
для: cheops
(20.07.2007 в 20:11)
| | | >
>PS Если всё таки решите оставить 9 таблиц, то и классов лучше для них 9 штук сделать и объединить их в едином классе user,
Это как? Т.е. каждый класс работает только со своей таблицей?
Объединять так?
<?php
class userUser {
// ИЗ ТАБЛИЦЫ users
function select($id)
{
}
// В ТАБЛИЦУ users
function save($data)
{
}
// ПРОВЕРКА User
function check($data, $full = NULL)
{
}
}
class userAddress {
// ИЗ ТАБЛИЦЫ users_address
function select($id)
{
}
// В ТАБЛИЦУ users_address
function save($data)
{
}
// ПРОВЕРКА Address
function check($data, $full = NULL)
{
}
}
class userTel {
// ИЗ ТАБЛИЦЫ users_tel
function select($id)
{
}
// В ТАБЛИЦУ users_tel
function save($data)
{
}
// ПРОВЕРКА Tel
function check($data)
{
}
}
// Здесь делаем класс, который будет работать с юзером в Админ части
class userAdmin {
public $user, $address, $tel;
//// КОНСТРУКТОР
function __construct($id_user = NULL)
{
$this->user = new userUser($id_user);
$this->address = new userAddress($id_user);
$this->tel = new userTel($id_user);
}
}
$user = new userAdmin(1);
foreach($user->tel as $k=>$v)
echo $k.'->'.$v.'<br>';
?>
|
| |
| |
|
|
| |
|
|
| |
для: tAleks
(21.07.2007 в 09:56)
| | | да. | |
| |
|
|
| |
|
|
| |
для: cheops
(21.07.2007 в 11:52)
| | | Попутный вопрос. Класс userAdmin здесь вышел на манер фабрики классов. Верно? | |
| |
|
|
| |
|
|
| |
для: TXC
(21.07.2007 в 14:52)
| | | В общем да, однако фабрика предполагает обычно, что в обход её объект класса объявить нельзя, а фабричный метод выдаёт объект во внешний код. В общем, я бы поостерёгся трактовать код, как фабричный - поборники паттернов скорее всего заклюют :))) | |
| |
|
|
| |
|
|
| |
для: cheops
(22.07.2007 в 11:33)
| | | Благодарю. | |
| |
|
|
| |
|
|
| |
для: cheops
(22.07.2007 в 11:33)
| | | >В общем да, однако фабрика предполагает обычно, что в обход её объект класса объявить нельзя, а фабричный метод выдаёт объект во внешний код.
Как это сделать?
У меня в книжке есть пример фабрики классов, но тот, что-то я не вижу запрета на создание класса в обход фабрики.
Меня интетсует именно, как запретить создание объектов без фабрики.
Входной параметр $type, в зависимости от него фабрика должена создать один объект соответствующего типа $type.
Приведите пожалуйста пример. | |
| |
|
|
| |
|
|
| |
для: tAleks
(26.07.2007 в 16:54)
| | | Объявите конструктор закрытым - тогда вы сможете вызывать его в фабричном методе (его удобно сделать статичным) и не сможете вызывать из вне. | |
| |
|
|
| |
|
|
| |
для: cheops
(27.07.2007 в 10:45)
| | | > Объявите конструктор закрытым
В смысле final, private, protected? | |
| |
|
|
| |
|
|
| |
для: TXC
(27.07.2007 в 11:25)
| | | private | |
| |
|
|
| |
|
|
| |
для: tAleks
(20.07.2007 в 19:53)
| | | Юзай Transfer Object и DAO. | |
| |
|
|