Вынужден не согласится с автором по поводу решения проблемы. Заменив echo на return, Вы никак не изменили класс и не сделали его изменяемым только по 1 причине. Для того, чтобы реализовать этот метод, нужно создать отдельный класс и перенести туда метод render. Тогда Основной класс будет изменен лишь по причине необходимости заменить лишь методы получения информации, а второй класс будет изменен лишь при необходимости внести изменения в метод render, например потому, что помимо getDoctor, getPatient и getData, нужно так же отобразить еще и например время создания карточки, getDateCreate, который в свою очередь, может храниться в другом классе. Заменив echo на return Вы всего лишь отложили вывод информации с "сейчас", на "потом", когда будет вызван оператор echo. Я должен менять класс Report только потому например, что мне нужно добавить тот самый метод getDateCreate, но никак не потому, что мне нужно этот самый getDateCreate вывести в render или изменить render, чтобы он возвращал только данные 2 методов, а не 3, или изменить на что либо еще, или возвращать их в массиве - это уже 2 причина для изменения 1 класса. Правильной реализацией метода единственной ответственности, будет разделение 1 большого класса, на несколько маленьких, но отвечающих строго за конкретную часть: получение данных, сохранение данных, изменение данных, вывод данных и так далее.
Разделение на отдельные классы, получение, сохранение и изменение это уже слишком, на мой взгляд. 1. Потенциальное место для ошибок. Сохранение "переключили" на БД, чтение осталось из базы.... 2. Так можно дойти до того, что все ООП будет сведено к процедурному стилю, где каждая "процедура" обернута в свой класс. и все это раскидано по фалам... т.е. на каждом хите читается куча файлов и порождается куча объектов... :) Про retrun согласен, по сути там реализован view. Логично было render работал с объектом...
Внимание, была допущена фатальная ошибка в начале урока. И метод Render в указаном примере совсем не работает, так как не отобразилось H1 выделение и переходы . Ведь туда пришли 3 пустые строки. Документ формируется обычными echo внутри методов Get.... И конечно, Евгений Перервенко прав, класс по прежнему нарушает Single Responsive Principle, поскольку содержит шаблон дизайна отчета (View), а методы получения данных это (Model)
Принцип единственной обязанности / ответственности (single responsibility principle) обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс. Все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.
Вот это крутой материал)
Спасибо :)
Вынужден не согласится с автором по поводу решения проблемы. Заменив echo на return, Вы никак не изменили класс и не сделали его изменяемым только по 1 причине.
Для того, чтобы реализовать этот метод, нужно создать отдельный класс и перенести туда метод render. Тогда Основной класс будет изменен лишь по причине необходимости заменить лишь методы получения информации, а второй класс будет изменен лишь при необходимости внести изменения в метод render, например потому, что помимо getDoctor, getPatient и getData, нужно так же отобразить еще и например время создания карточки, getDateCreate, который в свою очередь, может храниться в другом классе.
Заменив echo на return Вы всего лишь отложили вывод информации с "сейчас", на "потом", когда будет вызван оператор echo. Я должен менять класс Report только потому например, что мне нужно добавить тот самый метод getDateCreate, но никак не потому, что мне нужно этот самый getDateCreate вывести в render или изменить render, чтобы он возвращал только данные 2 методов, а не 3, или изменить на что либо еще, или возвращать их в массиве - это уже 2 причина для изменения 1 класса.
Правильной реализацией метода единственной ответственности, будет разделение 1 большого класса, на несколько маленьких, но отвечающих строго за конкретную часть: получение данных, сохранение данных, изменение данных, вывод данных и так далее.
Методы getDoctor и addDoctor делаем в одном классе?
Разделение на отдельные классы, получение, сохранение и изменение это уже слишком, на мой взгляд.
1. Потенциальное место для ошибок. Сохранение "переключили" на БД, чтение осталось из базы....
2. Так можно дойти до того, что все ООП будет сведено к процедурному стилю, где каждая "процедура" обернута в свой класс. и все это раскидано по фалам... т.е. на каждом хите читается куча файлов и порождается куча объектов... :)
Про retrun согласен, по сути там реализован view. Логично было render работал с объектом...
@@VorobyevAlexander Дальше будет изучаться инъекция зависимостей. Этот принцип решает эту проблему.
Внимание, была допущена фатальная ошибка в начале урока. И метод Render в указаном примере совсем не работает, так как не отобразилось H1 выделение и переходы . Ведь туда пришли 3 пустые строки. Документ формируется обычными echo внутри методов Get.... И конечно, Евгений Перервенко прав, класс по прежнему нарушает Single Responsive Principle, поскольку содержит шаблон дизайна отчета (View), а методы получения данных это (Model)
Спасибо, за контент. Ждем второй принцип.
Пожалуйста!
Спасибо, очень актуально!!!
Пожалуйста.
Благодарю!👍🏻
Супер подача материала! Огромнейшее спасибо!
Да как раз в нужное время )
Покажите пожалуйста по детальнее 😊👏👍
Спасибо за урок! Вопрос не по уроку :) каким сочетанием кнопок вы вызвали доп.меню "Add method stubs" (20:17)?
ALT+Enter
Выделите в плейлист все пять уроков.
Принцип единственной обязанности / ответственности (single responsibility principle)
обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс. Все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.
Не "обязанность", а причину для изменения. Именно так, со слов автора принципа, был задуман этот принцип!