Comments 13
Умоляю, вычитывайте текст перед тем, как постить. Было больно, начиная с первого абзаца. "и как в следствии", "отвественности"...
Разбудите меня через 100 лет, и спросите, чем занимаются разработчики на ООП-языках - я отвечу, что обсуждают принципы SOLID :)
Вот представьте что в будущем к вам придёт администратор и скажет я хочу изменить его, чтоб он сохранял в Word файл (.doc), и вы измените его, но не заметите что этим же методом ещё и пользовался другой актор (Продукт менеджер).
Что-то не то, это же интерфейс, и его надо выделить отдельно для метода Save, а реализацию можете разную для разных акторов. Ексель для менеджера, и Ворд для администратора
Не надо делать два одинаковых метода в разных интерфейса, которые по сути предназначены для одного и того же. Тем более, что совсем не очевидно иметь метод SaveToFile в интерфейсе IGetPlane.
В общем сделали не совсем правильно.
В том и суть, что эти методы не одинаковые, у них в целом возможна разная сигнатура, т.к. разное, ни как не пересекающееся назначение. Если сделать один метод, то это уже прямое нарушение dry (ну или ssot, что то же самое).
Если разная сигнатура, то и делайте разные методы с разными именами и отдельный интерфейс, в данном примере, это методы с одинаковой сигнатурой и предназначен для одной задачи - сохранить файл.
У вас не метод один, а вот интерфейс должен быть один, при этом реализация разная может быть для разных акторов. Причём тут dry не понял.
Самое забавное тут то, что сам Мартин в своей же книге, ближе к концу, приводит несколько .. альтернативных примеров организации кода, и даже к простой программе указывает что-то типа ".. ну, такую простую фигню мы конечно напишем единым куском .. " в моем вольном переводе "по памяти".. не, не заходит. Ещё неплохо отыскать на Лурке описание принципов Solid .. очень наглядно, кмк. ;)
Всех, с Наступившим Новым Годом!
С некоторым трепетом прочитал вашу статью. Скажите пожалуйста, в вашей организации есть открытые или архивные вакансии Flutter на HH.ру или подобных ресурсах? Если да, то не могли бы вы поделиться ссылкой? Можно в личку. Мне бы это сильно помогло откалибровать самооценку собственных умений и опыта работы, есть ощущение что я несколько оторвался от реальности. Спасибо
В общем, я делаю вывод что кандидат не читал книгу "Чистая архитектура", либо это делал очень невнимательно...
Я бы такого даже кандидатом не назвал. Чисто проходимец. И ведь не постеснялся с такими знаниями прийти на собеседование, ещё и на джуна
Теперь глядя на класс Plane , совершенно не понятно что с ним делать. Он превратился в data class, а его использование придется искать по всему проекту. Тут напрашивается все же какая-то аггрегация в итоге, возможно некий класс медиатор, который имплементирует все интерфейсы и содержит их делегаты.
Казалось бы, причем тут Dart/Flutter (кроме того, что на нем примеры кода приведены), когда речь про SOLID и SRP в частности... Суть текста применима ко многим ЯП. Странная статья.
Теперь код разбросан по разным модулям. Если для разных акторов нужны схожие функции, код придется копи-пастить. Кода будет больше и он будет непонятнее. Это точно самый экономически целесообразный способ?
Правильное понимание Single Responsibility Principle (SRP) в Dart/Flutter