Чтобы понять видимость свойств класса нужно почитать про инкапсуляцию.

---

Спустя 1 минута, 27 секунд Winston написал(а):

---

Если в родителе свойства объявлены как public или protected то в дочернем классе можно получить доступ к ним, если private то - нет

Харашо. Если в родительском классе конструктор создает много обектов каждый из которых имеет одноименное свойство то к какому тогда обращается дочерний класс например через
$this->config->get('something'); если этот config в каждом обьекте свой и все обьекты в одном родительском классе.

Ок. Какими методами лучьше изучать архитектуру?

Принципы проектирования классов.(SOLID)

Дочерний класс наследует только методы и поля родительского класса и никогда их значения созданные в родителе уже после запуска скрипта. Это надо запомнить раз и на всегда.

thank you linker

Ну а как тогда на счет доступа до обьектов созданных другими обьектами во время запуска скрипта.

Ты имеешь ввиду после инициализаии экземпляра объекта класса? А какой там доступ...

Родство существует только между классами, но не объектами. Два объекта пускай и родственных классов, друг для друга являются чужими.

class Parent
{
    public $a = 0;
    protected $b = 0;

    public function __construct()
    {
        $this->a = 1;
        $this->b = 2;
    }
}

class Child extends Parent
{
    public function __construct($parent)
    {
        echo $this->a; // Выведет 0, т.к. мы унаследовали свойство, а не значение
        echo $parent->a;
        echo $parent->b; // тут будет ошибка, ибо свойство b защищено от доступа извне
    }
}

$p = new Parent();
$c = new Child($p);

linker
У меня не выдает ошибку в твоем примере. В чем причина?
Выдает ошибку только в случае

private $b = 0;

SoMeOnE
Потому что private поля и методы не наследуются.

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

Ещё раз возвращаю Вас к вашему посту про родство объектов.
Оно есть как на проектном уровне так и на уровне объектов, и этому ничего не помешает, ни "блаж" caballero, ни взрыв на Фукусиме.
По поводу композиции, проксирование или не проксирование это не важно, важно что в дальнейшем родитель передаёт право на реализацию (делегирует права) дочерним объектам, то же самое происходит в классическом наследовании (передаётся право на реализацию только в статическом формате ну и ясное дело право на пользование родительскими методами), подчёркиваю на уровне Zend машины.
C ув. Greg1978

Да и не проксирование использовано а делегирование.
Прокси паттерн это другое.

Ну чтоб ты въехал наконец

class Parent
{
    public $a = 'Parent';

    public function show()
    {
        echo $this->a;
    }
}

class Child extends Parent
{
}

$child = new Child();
$child->a = 'Child';
$child->show();

Быстро, просто и делает свою задачу - классическое наследование. То, что хочет ТС, описано в моём посте выше, где конструктору дочернего класса передаётся объект родителя.

Ёпт, откройте хотябы википедию и почитайте, что такое наследование, делегация с наследованием не имеют ничего общего.

Ещё раз прочитайте по буквам!

Родство, это когда потомок через $this непосредственно обращается к полям или методам родителя (унаследованным, т.е. уже своим). Пример я не зря привёл, всё остальное не является наследование, а является проксированием. В твоём случае, "потомок" НИКОГДА не получит прямой/непосредственный доступ к protected полям и методам "родителя".

И ещё "прозрачней"

class Parrent
{
    private $child = null;

    protected $property = 'parent';

    public function __construct()
    {
        $this->child = new Child($this);
    }

    public function getChild()
    {
        return $this->child;
    }

    public function getProperty()
    {
        return $this->property;
    }
}

class Child
{
    private $parent = null;

    public function __construct(Parrent $parent)
    {
        $this->parent = $parent;
    }

    static function getChild()
    {
        $parent = new Parrent();
        return $parent->getChild();
    }

    public function showPropertyParent()
    {
        echo $this->parent->getProperty();
    }
}

$child = Child::getChild();
$child->showPropertyParent();

Именно, приходится реализовывать кучу левых методов. Чтобы получить protected методы и поля "родителя"/"потомка" придётся добавить ещё кучу методов, либо ходить через __set(), __get(), __call(). Прозрачность нулевая, во время разработки хрен построишь схему классов. Я не против таких подходов, я против называть сие чудо наследованием и уж тем более классическим в своём поведении. Повторюсь, что сие чудо называется проксированием.

Потому,что испанского точно незнаю,и знать скорее всего небуду

В проксировании опрерируются как минимум три объекта, при чём третий объект не подчинённый а оперируемый!

Кстати эту цитату

class Animal
{
    private $cat;
    public function __construct()
    {
        $cat = new Cat($this);
    }
}

class Cat
{
    private $animal;
    public function __construct(Animal $animal)
    {
        $this->animal = $animal;
    }
}

Монстры ООП

Мда ...
UML не для того создан что бы по нему генерировать исходники (хотя это практикуется и я сам это не поддерживаю). Создан для лучше восприятия и понимания, а то что в Ваших конторах не могли подобрать нормальную методологию ведения проектов эти проблемы не стоит сваливать на UML.
Я знаю что сейчас мода на agile методики идёт особенно scrum, в них ясное дело нет место формализации и начальному этапу аналитики (конструирование архитектуры то же не заложено фактически в методологию), соответственно проекты хромают на весь правый и левый глаза. Новый человек приходя в команду начинает всех программистов и по всякому "иметь" вместо того что бы "иметь" документацию начиная с UML. На форуме русскоязычном YII есть диаграмма классов всего фрейма.
На паттерны мода и не пройдёт, потому что это не мода в принципе, а структуры и опыт построения систем в зависимости от большинства ряда однотипных задач. При этом они обеспечивают оптимальные условия для повторного и независимого использования функционала, это раз.
Два, это их "документированность". Говоря что в этой части системы использован паттерн построения мост или адаптер новый человек в команде больше понимает реализацию при этом не надо на пальцах объяснять что куда и к чему если сделан какой то свой "велосипед". Соответственно и сам программист должен хоть как то знать о паттерне. Хотя что далеко ходить. В функциональном программировании так же есть свои шаблон построения, которые себя зарекомендовали лучшим образом в ряде однотипных или родственных задач. А вот то что Ваши архитекторы не смогли применить правильно опыт структурирования архитектуры с использованием паттернов то это уже опять - не стоит валить с больной головы на здоровую.
И да, последнее, проектирование равно как и разработка ПО весч далеко не статическая и изменяться может довольно часто, особенно если нет этапа анализа и выработки требований, соответственно и архитектура даже может валиться наглухо от этого. понятное дело что и UML переделывается в зависимости от динамики изменений архитектуры и т.д. А как Вы хотели поддержка документации то же затратная часть разработки ПО, но она необходимо, чего не учитывают многие и многие. Практика специалистов по ведению проектов показывает, валяться проекты не от опыта и лени программистов, от недостатка и качества выработки требований и анализа. В этом помогает очень качественно диаграммы и документация. Я сказал диаграммы имея ввиду не только стандарт UML но BPMN и другие. Просто UML более поддерживаем и более применим в массах, да и инструменты под него хорошие. Это как Microsoft против Apple.

У меня, кстати, предложение к администрации форума появилось.
Создать тему форума по различным методологиям их использования, недостатки. Кто как ведёт проекты и справляется с разными этапами в разработке. Какие шаблоны документации используются, и в какой формализованности. Вопросов много можно порешать особенно если много у людей опыта в ведении проектов и балансировки между различными этапами разработки.

Ой обшибся не тему, раздел Аналитики и методологий.

Greg1978
Прокси, то когда я через один объект обращаюсь к другому. И не важно есть там третий объект или я делаю это напрямую обращаясь к прокси.

Родство - есть производная от наследования. Ещё раз прошу прочитать что такое наследование. Объекты ничего не наследуют, наследуют классы, объекты лишь получают поля и методы своего класса НИ БОЛЬШЕ И НЕ МЕНЬШЕ. Теперь я вижу насколько могут быть вредными паттерны, народ забывает суть.

Просто разбираясь в коде одного движка у меня возник такой галюн что класс прописан с использованием массива созданного другим классом никак не родственного. Может такое быть или это мираж?

От себя добавлю, что объект Папа никогда не назовёт свой Объект Дочку родственным. Конечно это всё смешно,если бы не было так плохо.
linker расшифруем анаграмму ООП = объектное ориентированное программирование. Вывод в классы это результат человеческой деятельности ума. Естественный путь проектирования предметной области это выделение ОБЪЕКТОВ в семейные (РОДСТВЕННЫЕ) качества, свойства и поведения!
Вся и фишка в том что узкомысление в проектных реализациях, то есть как оно реализовано непосредственно в инструменте (интерпретатор PHP (кстати его называют недоООП, как после этого можно говорить про наследование как про родственное)), затупляет моск в функционально - объектно - непонятно - процедурное программирование. У кого более разумно у кого менее разумно и более чем упаковка статических процедур в классы и после этого кричать что ООП это хрень и ни на что не годный продукт воспалённого человеческо - программистского моска.
Это так для развития
http://ru.wikipedia.org/wiki/%D0%9F%D1%80%...%D0%B8%D0%B9%29

http://dic.academic.ru/dic.nsf/enc_philosophy/4681/ПОДОБИЕ

Да, что бы не было что я говорил про наследование и всё такое (хотя это всё инструмент реализации передачи свойств и поведения либо автоматизированным (интерпретатор) либо ручным способами) привожу из за чего весь сыр бор.

Мнда...
В который раз удивляюсь мудрости Хьюза, который сказал, что ООП в веб сводится к тому, что вместо прямого решения задачи мы сначала придумываем кучу новых и только потом решаем основную.

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

twin
Хьюз справедлив для решения задачи с неизменными условиями на всём протяжении своей жизни. Для всего остального - решение в лоб наихудшее из зол.

Ну чтобы судить понимаем мы друг друга или себя, нужно хотя бы разбираться в вопросе, который тут обсуждается. Ты Гуру (честно), но без ООП поэтому уж извини, без обид.

Правильно ли я мыслю?
1. Обьекты не бывают что называется расшаренными они не дают доступа напрямую к своим переменным.
2. Если в конструкторе обьекта создается масив из других обьектов то доступ к ним будет происходить только с помощью обьекта-контейнера типа $pregnant->child->voice
3.Внутренний обьект $child не имеет доступа к переменным обьекта-контейнера $pregnant напрямую а только через конструкцию $pregnant->milk

twin
Я не знаю тысячи паттернов, я знаю с десяток, ну может 20 и то, 15-16 из них являются вариациями оставшихся. Каждый для чего-то нужен. Каждый имеет свои плюсы и минусы. Делать самому - это лепить велосипед, но я не имею ничего против этого, даже наоборот.

Даже авторы умных книжках по паттернам (не только PHP): "Ребята, паттерны добро, только в необходимых количествах, когда вы всё подменяете паттернами и программируете только в паттернах и думаете паттернами - это зло. Нельзя ими увлекаться."

Я не ошибся))