Уверен, найдутся люди не согласные по поводу того, что ООП допускает DTO. Но не будем об этом. Именно, структура внутри класса, даже класс внутри класса, и это не обязательно будет нарушением SRP! Почему? Смотри, SRP нарушается тогда, когда у класса более 1 обязанности, так? Так. Приведу абстрактный пример с машиной. Программист декомпозировал машину и получил несколько классов: Машина Двигатель Колесо Можно Двигатель и Колесо вынести в отдельные классы, а можно сделать их внутренними! В итоге, что получается? Машина ответственна за то, что едет (т.е. координирует работу двигателя и поворачивает руль), Мотор ответственен за то что крутит коленвал, который крутит колеса. Каждый класс занят своим делом. Т.е. результат абсолютно такой же, если бы эти классы были вынесены в независимые. --- Добавлено --- P.S. я плохо разбираюсь в машинах, так что не пинайте за неправильное название деталей ))
Лучше приводить примеры на реальных задачах, а не из реальных предметов, в тексте красиво, а на деле знаний не прибавляет.
Да я об этом и толкую, причем тут изобрел?! Внутренние классы необязательно будут нарушать SRP! Вовсе необязательно. Для демонстрации SRP вполне достаточно предметной области. Да че я вообще оправдываюсь, рассказываю элементарные вещи. Раз нарушает SRP - докажи. Докажи почему внутренние классы/структуры это плохо! Во всех нормальных языках это есть и никто не жалуется, а тут оказывается это не SOLIDно и черт знает что еще.
Структуры в пхп в котором нестрогая типизация будут похожи на говно. Благорадя тайп хинтам они могут наконец-то появится и вообще сами напрашиваются.
А я не о том. Я о том, что если вам внутри класса для передачи информации между методами потребовалась структура - скорее всего проблема в консерватории. Сложный класс - первый кандидат на рефакторинг. Композиция нужна в том числе, что бы не нарушать SRP (не только, конечно). Когда соответствующие обязанности переносятся в инжектируемые объекты. Но это все еще отдельные _объекты_. Класс, внутри которого куча кода вложенных классов - воспринимается целостно со всеми своими "вложенными". Да, формально внутри отдельные классы, там создаются объекты и т.п. Формально. По факту - у вас простыня плохо читаемого кода и потрясающее сопротивление к юнит тестированию (ибо не представляю, как эти вложенные классы мокать). Т.е. по сути - не вижу вменяемых кейсов, когда вложенный класс удобнее, чем отдельный инжектируемый. Меньше файлов? Извините, я вижу в этом недостаток, скорее, чем достоинство Вопрос не в том - есть или нет. Вопрос в том - использует это кто-то активно или нет. Возможно, есть какие-то кейсы, когда это очень полезно, но наиболее вероятно, что это исключения подтверждающие правило.
Не, серьёзно, структуры - очень удобная хрень. Другой вопрос что без типизации структура будет аналогична PHP: $arr = array_merge( [ пустая структура ], $arr); и по большей части просто лишена смысла.
@MiksIr, согласен с тобой. Вложенные классы, действительно, могут принести больше вреда, чем пользы. Но структуры другое дело. Как правило это кучка данных, несколько переменных, логически связанных между собой. В структурах, обычно, и логики никакой нет. Геттеры/сеттеры для инкапсуляции + конструктор. Все, это все что нужно структурам. Так почему бы им не жить внутри классов? Приватные структуры тоже могут быть полезны. С точки зрения структурирования кода. Например, фигура может иметь приватное поле-структуру Координата{x, y, z}. Удобно? По моему да. И читабельность кода повысилась. Но все же приватные структуры не столь полезны, как публичные. Ты имеешь ввиду тип самой структуры? По аналогии с типом класса? Тайп хинты полей - вот что нам надо. А структура, де-факто, должна иметь тип, по аналогии с классом. Иначе, как ты и сказал, это будет похоже на говно... как анонимные классы.
по большому счёт структурам в чистом виде не нужны ващпе никакие методы, включая геттер и сеттеры. И конструктор можно заменить дефолтными значениями. --- Добавлено --- без этого вообще никак, да. Без кастомного типа структуры они будут слипаться.
Редкий случай рид онли структур, в пэхэпэшной реализации будет требовать геттеры+конструктор. А в общем случае, да, только публичные поля.
ну это уже удобства типа геттеров-сеттеров. По идее, структура это набор полей. То, чем структура становится, после того, как мы заканчиваем теребонькать её геттеры и сеттеры. И основной плюс структур - гарантия наличия полей. Это конечно можно реализовать через классы и интерфейсы, но радость структур в легковесности.
Так вроде пришли к выводу, что структура отличается от класса весьма условно. Внешне - так вообще ничем Неа, удобно DTO Point я о том и речь - случай, когда приватная структура удобнее, чем публичная - еще поискать нужно. --- Добавлено --- А что такое "легковесность"?
@MiksIr Внешне, в плане использования, ничем. Но все же есть отличающиеся механизмы: способ хранения структуры, невозможность наследования. Расскажи ка мне, чем структура отличается от DTO? Почему ты предпочитаешь реализовать DTO классом, нежели структурой?
Потому что я не вижу разницы? DTO у меня immutable, структуру я бы делал immutable тоже, скорее всего, так что проблема ссылочности тоже не стоит. Скорее не способ хранения, я способ передачи. Невозможность наследования - ну тоже обсуждали, да и не вижу я в этом какого-то плюса структур, скорее даже минус.
я с этим не спорю. Просто тупо больше памяти выделять например - уже нагрузка. Т.е. если у структуры есть заранее заданные поля, размер которых в байтах известен и не меняется - уже плюс. Если там нет кода априори - уже проще жить компилятору и мусорщику. В golang ващпе эта грань между структурами и классами отсутствует. количество памяти и число операций для достижения результата при прочих равных. Чего за странные вопросы? Если у тебя есть об этом мнение, то вываливай. Сишники так вообще свои структуры добивают мусором дабы они занимали кратное странице памяти место, чтобы при работе с ними не возникало по два обращения к разным страницам. это потому что ты мыслишь о структурах, как о недоклассах. А они не такие. Они - структуры. Кусок памяти, значения из этого куска можно читать через слова-поля. Это единственное предназначение структур. Так просто проще работать. Слепил два интегера в структуру - вот тебе координата. Дальше ты юзаешь ->x и ->y (или .x и .y) и живёшь счастливо, всегда зная, что там сидит и оно есть, и оно занимает ровно 2*(инт) байт памяти и всегда содержит инициализированные значения. А наследования и прочая муть тут просто не возникают даже в голове. Если у тебя структура такая сложная, что она может наследоваться и усложняться дальше - тут надо делать объект и не ебать себе мозг экономией байтиков.
Какой-то однобокий взгляд. Функционал "структуры" не имеет отношения к способам хранения в памяти и каким-то там байтикам. В статически явно типизированном языке и у объектов будут те самые байтики. Мы жы на ПХП форуме, да? Умничай по делу тогда.
Ну вот потому в пхп нет структур, т.к. в пхп нет байтиков, т.к. перемнные весьма универсальные структуры в себе содержат, которые таким правилам не подчиняются, тащат огромный оверхед и т.п. И пхп нужен не для экономии байтиков, и в этом его плюс. И при этом со всем этим дерьмом он супербыстро работает. Но структура удобна вот тем, что я написал: в пхп эту работу могут выполнять ассоциативные массивы. И отлично её выполняют, за тем исключением, что не гарантируют наличие полей. Но это опять-таки компенсируется сложением массивов, где один - присланные данные, а второй - дефолты. В js например я не знаю как это сделать одной строчкой без jquery. А в пхп получается, что всё раешается одной строкой и пофиг на то, что это не структура. Вполне удобный костылёк без привнесения дополнительных сущностей в язык.
Не в байтиках дело, а в структурировании данных. Если тебе не нужны структуры еще не значит, что всем они не нужны. Мне, например, не нужны анонимные классы, но ведь кому то они понадобились, раз 2/3 проголосовали за. Пусть себе будут, мне они не мешают. Вон в C# каждый релиз по 100 фич добавляют (образно говоря), половина из которых, а то и больше, никогда не понадобится, или понадобится 1-2 раза в жизни, ну ничего, живут как-то с этим грузом. А структуры будут использоваться чаще чем никогда, потому что они удобны для своей задачи - для структурирования данных. Структуры нельзя отнести к ООП, как, кстати и DTO, это просто, как побочный инструмент, которым люди пользуются, не потому что без него нельзя, а потому с ним удобно. Аналогия - генераторы. Без них можно использовать итераторы, но это не так удобно. Так же и со структурами. Можно классами, но структурами удобней.
Да нет же, еще раз, это не из-за наличия структур, это из-за того, что язык статической явной типизации. В таком языке и просто объекты свои свойства будут хранить точно так же, байтики и все прочее, как и структуры. Возьми тот же c#. Основно отличие, что класс - ссылочный тип, а структруа - значение. Т.е. передавая объект - передаем ссылку на него, а передавая переменную типа - передаем ее значение (копируем). --- Добавлено --- Я бы даже классы и объекты не стал бы относить к ООП, если вот так вот в отрыве упоминать ))
@MiksIr я вроде как нигде этому не противоречу, просто не считаю это основополагающей причиной отсутствия в пхп структур. В ПХП нет структур потому, что ни лишены большей части смысла своего существования. Но тайп хинты могут это изменить.
Смысл существования структур в ПХП ровно такой же, как смысл существования структур в C#. Возможность указания тайпхинтов с примитивными типами к этому смыслу отношения не имеет.
phpDoc )) до этого как-то жили. действительно, статическая типизация не является решающим фактором. но будем надеяться что примут RFC по typed properties.