twin
Ну например для БД, если ты захотел намутить актив рекорд паттерн для БД, или архитектуры приложения. Там например удобно создавать динамически поля, а потом их перебирать и строить какую нибудь штукенцию. И вот когда вызывается этот магический метод, там можно фиксировать состояние приложения, например ты добавил поле "окно", и тут сеттер понимает, что твое окно принадлежит другому экземпляру классу, и надо что-то сделать с этим классом, может получить доп данные по классу, и присвоить какие то состояния.

Ну это не рационально. ИМХО. Начиная с этого места:

Спорить действительно не нужно))) Во-первых я написал ИМХО, а во вторых конструктор на боевом сайте... Какая же это рационализация. Конструктор хорош для конструирования. На то он и. А для работы лучше использовать обкатанную модель, где нет ничего лишнего.

За разъяснение большое спасибо. Только к сожалению я не этого хотел(((

Я имел ввиду вот что. Есть цикл do...while Он используется крайне редко, хотя Попов его умудрился засунуть в каждый свой сайт по нескольку раз. Однако есть такие моменты, где без этого цикла действительно сложно. Допустим преобразование целого числа в строковую запись. Там он на своем месте.

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

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

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

sharki
В том и дело... Вот столкнулся я в одном месте с такой штукой (упрощенно):

    public function __set($name, $value)  
    { 
        if(in_array($name, $this->properties)) 
            $this->$name = $value;
        else
            exit('property '. $name .' is not defined');   
    }  

Ну ясно, инкапсуляция. Не дать сунуть в объект лишнее свойство. Фильтр вроде как. Благое намерение, но только если не доверяешь разработчику. Это не рационально.

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

stepan

Если объект имеет динамическую структуру, то есть изменяемое число свойств , при чём в разных контекстах разное число (пример тому динамический массив, но объект требует в себе какие то валидации этих свойств, алгоритмы преобразований, тогда рационально и оправданно использовать объект, а не массив).
Пример тому может быть динамический объект транзакции или ещё лучше динамический объект трансфера данных (Data Transfer Object) между какими то "слоями" в программе. Например между слоем представления->слой бизнес логики->слой БД->шлюз БД (сама запись в БД). На каждом уровне добавляется свои свойства и в определённых условиях разный набор. Это конечно не особенно читаемо, но удобно когда нужен "сквозной" объект данных.
Но лучше всего это удобство видно в объекте передачи данных по сети, при чём стандартизируются обе стороны. Слой представления->слой бизнес логики->слой БД-> и передача в компонент по отправке данных на удалённый узел. Возможно Вы скажете что по сети лучше передавать строковые данные (это конечно спорный вопрос), но никто не мешает преобразовывать объект в строку
То есть в результате мы имеем перемещаемый контекст данных, при чём с динамической структурой. Писать bean методы для всех знаемых и не знаемых свойств нет нужды в этом.
Хорошо реализован в RUBY такой доступ.

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