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

Ты прав

A ни у кого, случаем, нет перевода david west "object thinking"?

а он вообще существует?

он же писал, что не будет электронную версию выкладывать, т.к. ее в тот же момент сопрут

Ну уже сперли, в любом случае. А русского перевода вроде как не существует

object thinking - стоящая вещь?

Я пока еще не осилил (

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

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

действительно. первым должен быть C

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

наркоманы что-ли

паскаль ?

David west в своей книге пишет, что мол современная софтовая индустрия совсем неправильно поняла суть ооп-проектирования.

И объект представляет метафорично как

"Разумный компьютер, обладающий поведением"

Типа того

Ну и мол, в этой книге можно почерпнуть философию правильного оопроектироания, всякие метафоры

Из наших чуваков есть сподвижник Уеста - Егор Бугаенко

Вот неплохое интервью

Йее

https://youtu.be/s-hdZZzMCac

лучше не думай об этом)

У меня в душе теплится надежда, что где то есть волшебная таблетка, после которой я смогу в тру-ооп)

тру ооп нахрен никому не нужно

это процедурщина на стероидах

не более

Существуют иные мнения)

У меня в душе теплится надежда, что где то есть волшебная таблетка, после которой я смогу в тру-ооп)

а смысл упираться в то, тру или не тру ооп?

Не совсем корректно выразился

это процедурщина на стероидах

и наследование тоже?

наследование не нужно

Под тру я имел ввиду "легкопроектируемый", легкорасшияемый и тд

редкие кейсы когда наследование > композиция

типа темплейт методы

David west в своей книге пишет, что мол современная софтовая индустрия совсем неправильно поняла суть ооп-проектирования.

а у тебя вся или первые 70 страниц?

вся вроде)

Ребят, помогайте) Как можно описать делегат простыми словами? Сложными до меня что-то не доходит

Ребят, помогайте) Как можно описать делегат простыми словами? Сложными до меня что-то не доходит

когда задачу перекладываешь на другого, а потом пользуешь результат)

Во

А где такую практику можно применить?

Ну, в смысле, зачем нужно задачу перекладывать вообще

например если там большое количество аргументов в функции

а тебе надо что то по проще

часть аргументов мождно проставлять один раз)

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

Вон как

так, а че, кто-нибудь таки читал Уеста?

не Канье

я странице на 20ой вроде)

полную отыскал? могу скниуть, если что

неа

не отыскал, так что лей)

Офигенная книжка!?

Еще вопросик, уже практический

В общем, делаю систему событий

https://gist.github.com/Folleah/f2efef2b91e0debbb845b315fe94f4d6

вот примерно так должно все выглядеть (наверное), я в верном направлении вообще?)

зачем-зачем-зачем

статические методы

ERROR: S client not available

А что в них плохого?

А, понял

типо, нафига я тогда создаю экземпляр класса?

Все, я проследил суть, оно должно все в контексте созданного объекта работать

А если кроме этого?

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

тебе ж показывали, что там можно строчку записать и вызывать

Да не, пыха это лишь язык

если метод не взаимодействует с внешним миром - статик это ок

если статик это именованный конструктор, то ок)

что касается эмитера, то почему он занимается всем подряд? И ивенты создает, и какие-то непонятные листенеры

Ну, эм

почему ивент знает о слушателях, а не наоборот?

Потому что я поэтому и спросил тут :D

зачем вообще тебе объект event, если везде ты со строчками работаешь

если статик это именованный конструктор, то ок)

не только. статики это ок

ну и аналогично с листенерами

зачем вообще тебе объект event, если везде ты со строчками работаешь

Я вот думаю, как лучше сделать просто

не только. статики это ок

так может тебе нужны просто функции?

Мб мне фабрику сделать? И через отдельный класс-интерфейс взаимодействовать

Мб мне фабрику сделать? И через отдельный класс-интерфейс взаимодействовать

https://gist.github.com/mkusher/981f28900f042d2ec7e19b59d9683269

Вот это поворот :D

Спасибо за помощь)

пожалуйста)

А если мне доступ к определенному эмиттеру нужен где-то в другом месте? Ну, в другом классе например

так может тебе нужны просто функции?

не, слишком просто. если у тебя он имеет отношение к классу или его кишкам, но не имеет отношения к конкретному инстансу. тогда статик норм

Нужно делать класс, в котором будут храниться объекты созданные? И создавать их через метод?

не, слишком просто. если у тебя он имеет отношение к классу или его кишкам, но не имеет отношения к конкретному инстансу. тогда статик норм

можешь пример накинуть?

Нужно делать класс, в котором будут храниться объекты созданные? И создавать их через метод?

не понял тебя

Не мудрено :D

можешь пример накинуть?

ну типа, для класса Address /** * @param AddressInterface $addressOne * @param AddressInterface $addressTwo * @return bool */ public static function isSame(AddressInterface $addressOne, AddressInterface $addressTwo) { if ($addressOne->getAddress1() !== $addressTwo->getAddress1()) { return false; } if ($addressOne->getAddress2() !== $addressTwo->getAddress2()) { return false; } if ($addressOne->getCity() !== $addressTwo->getCity()) { return false; } if ($addressOne->getZipcode() !== $addressTwo->getZipcode()) { return false; } return true; }