Форум PHP

Подскажите как обратится из скрипта к классу :

class CsvWriter {     private $file;     private $delimiter;     private $array;     private $handle;     public function __construct($file, $array, $delimiter=";")     {         $this->file = $file;          $this->array = $array;          $this->delimiter = $delimiter;         $this->FileOpen();     }     public function __destruct()     {         $this->FileClose();     }     public function GetCsv()     {         $this->SetCsv();     }          private function IsWritable()     {         if(is_writable($this->file))             return true;         else             return false;     }     private function SetCsv()      {        if($this->IsWritable())       {           $content = "";            foreach($this->array as $ar)            {               $content .= implode($this->delimiter, $ar);              $content .= "\r\n";            }            if (fwrite($this->handle, $content) === FALSE)                   exit;       }     }     private function FileOpen()     {         $this->handle=fopen($this->file, 'w+');     }     private function FileClose()     {         if($this->handle)           @fclose($this->handle);      }  } $array = array(array('1','1','1'), array('2','2','2'), array('3','3','3')); $dd = new CsvWriter('test.txt',$array); $dd->GetCsv(); ?>

1)
classname::function()
2)
$obj = new classname;
$obj->function();

Там же написано:
$array = array(array('1','1','1'), array('2','2','2'), array('3','3','3'));
$dd = new CsvWriter('test.txt',$array);
$dd->GetCsv();
1 строка - массив, который надо записать.
2 - создаем объект
3 - записываем.

public function GetCsv()     {          $this->SetCsv();       }

умер на 5 минут.


P.S. пример применения скрипта находится в последних четырех строках исходника.

вечная память тебе на пять минут :)

а что тут такого? Я всегда пишу реализацию в приватных методах, а вызываю их через публичные. Для того, если реализация изменится и придется еще что-то добавлять, тогда я сделаю два частных метода и вызову их через один паблик метод. В некоторых случаях необходимо реализовать очень ресурсоемкий код, нет смысла его вызывать через конструктор. Допустим, объект вызывается о дном файле, а метод, в которм выполняется тот код в другом. В общем, понятно. Более детально сейчас объяснить не могу - рабочий день только начался, а "работать ваще не прет"
В последних трех строках, но кто считает!

Trianon хочет сказать, что здесь лишь один вызов метода SetCsv() - поэтому метод избыточен. Само наличие метода позволяет как угодно изменять его реализацию без нарушения принципа инкапсуляции - дополнительный метод лишь усложняет восприятие и говорит о недопонимании задач ООП (справедливости ради следует сказать, что в PHP ООП ещё достаточно примитивен, без перегрузки операторов - теряется очень большой кусок его идеологической ценности). Цель ООП - не плодить методы и код, а наоборт снизить сложность задачи, свести многобразие мира к ортогональным методам и уменьшить объём кода.
Кроме того, реализация метода GetCsv(), через вызов метода SetCsv() вызывает небольшой ступор, так как ключевые слова являются антонимами... Такие стилистические штучки отнимают приличное время у сопровождающих код, особенно если класс раза в три больше.
Код правильный, но содержит ошибки проектирования, которые очень характерны для ООП, особенно когда ООП применяется для таких мелких задач, которые должны решаться одним методом, в данном случае конструктором или вообще отдельно стоящей функцией. Использовать класс повторно не представляется возможным, наследовать от него что-то бессмыслено, передавать объекты этого класса куда либо также не имеет смысла - в результате ООП здесь лишь увеличивает объём скрипта и мешает, не выполняя никакой полезной функции.

Но класс может и расширяться и измениться. И реализация может измениться. Просто я "немного" продумал действие на один шаг вперед. В принципе, можно как угодно реализовать подобную ситуацию. Лично я привык именно так делать.
Кстати, в других технологиях приставки get/set является обычной практикой для методов, которые позволяют обратиться к приватным данным. В этом же классе я тоже решил использовать данные приставки, но, в отличии от той же джава, эти приставки означают, что методы работают именно с записью csv. Может, и неудачное наименование методов, но ничего лучше придумать тогда не смог. еще раз скажу, что метод SetCsv можно сделать и паблик и использовать его, но лично я привык делать подобные обертки для методов.
Про примитивность ООП в РНР я умолчу, но в другом языке я бы именно так бы и сделал.

>Кстати, в других технологиях приставки get/set является обычной практикой для методов,
>которые позволяют обратиться к приватным данным
Аксепторы (get/set) не только являются нормой, но и усленно интегрируются в объектно-ориентированные языки программирования, такие как C#, да и PHP для их реализации предусмотрены специальные перегружаемые методы ( __set() и __get()) (с перегрузкой в PHP вообще плохо, но тут разработчики оказались на шаг впереди).

Дело не в этом, обычно не вызывают метод set(), как в методе get().

Как я уже сказал те методы являются ошибкой их наименования. :)

__set() и __get(), имхо, может и оказались на шаг впереди я не спорю. Но РНР не поддерживает перегрузку методов, и если данных будет много, то как тогда использовать эти методы? Данные превращать в один массив? Имхо, это не удобно, хотя...

С перегрузкой методов, а тем паче операторов в PHP действительно полный швах - до полноценных объектно-ориентированных моделей нужно ещё работать и работать. Какой смысл в объектах, если их нельзя сложить как обычные переменные

obj1 + obj2

и приходится использовать неуклюжие конструкции

obj1->add(obj2);

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

Это понятно, зато тема про сравнение объектов мне понравилась. http://www.php.net/manual/ru/language.oop5.object-comparison.php

В принципе, я с утра и даже с вечера пятницы задался вопросом о том, нужно ли ООП в РНР вообще и в частности. Да, получили некоторые возможности ООП, но и получили нагрузку на сервер. Получили возможность, но мало ей кто пользуется. Даже комбинируют 4 и 5 версии, пишут переменные с ключевым словом var и объявляют конструктор как в пятой версии. Про паттерны промолчу. Вот и возник вопрос: а оно надо? Кроме пантов на форумах и пускания пыли в глаза начальству это ООП и не нужно никому. В общем, пойду обедать.

Парочка задач удобно решать даже при помощи такого ООП, но основной мейнстрим проходит мимо него.

Согласен. Но все-таки ооп есть. Наверное, надо создать консорциум по пременению ООП в РНР. Шутка, навеянная идентичной темой на другом форуме и задержкой зарплаты :)
Наверное, надо писать статью о применении ООП в РНР :)

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

Ну, правда, что для покупателя продать, то для продавца - купить. Но чтоб так вот непринужденно сигать через прилавок - бьет влёт.
Хотя, возможно, единственное, что не хватает той строке, это пару слов комментария, распутывающего курьез...

Да, комментов нет и их явно нехватает, не люблю их писать, а надо.

ну, остальное, пожалуй, достаточно прозрачно.

Из замечаний по существу - Методу SetCsv явно не хватает гибкости при работе со строковыми значениями массива. Он просто обязан брать в кавычки строки, содержащие кавыычки и точки-с-запятой и удваивать кавычки. Благо это не столь сложно.

Можно сделать. Когда я писал этот класс, то подобной необходимости не было. Будет свободное время - сделаю. Но лучше сделать возможность удалять те символы, которые необходимы пользователю класса, т.е. ввести массив этих символов, а затем или удалять, или заменять/добавлять кавычки и т.д. Займусь на днях...

Кстати, на phpforum`e есть идентичная тема - http://www.phpforum.ru/index.php?showtopic=2583
Забавные там ответы на сабж.

Учу ООП, значит, пыхтю..... а оно оказыватся и не надо... (заплакал навзрыд!!!!)

ООП полезно, но его в данном языке следует применять с осторожностью. Если вас не заботит производительность (лично меня нет, т.к. я работаю в основном, в интранет, а серверы у нас достаточно мощные), то можете смело применять ООП. К тому же знание ООП будет полезно для освоения других языков.
Учите, ООП, учите.

Уф... спасибо (вытер слёзки... давлю лыбу)))) )