Комментарии 20
Спасибо, наглядно. Один момент: поправьте, если я не прав, но 'Workable' и 'Eatable' не подойдут в качестве названий протоколов, т.к. Eatable означает, что эту сущность можно съесть, а не что она может есть. Workable, соответственно – что над ней можно работать (к примеру, workable item), ну или, в зависимости от контекста, "осуществимый", к примеру, workable plan, но суть та же – это план, по которому можно работать. План сам не работает.
Спасибо, в случае с 'Eatable' согласен - корректнее будет назвать 'Eater', а вот с 'Workable' не совсем пойму на сколько корректнее будет назвать 'Worker'?
Думаю, 'Worker' как раз подойдёт хорошо. Ведь основной атрибут рабочего – сто он выполняет работу. Вдруг мы нвнимаем рептилоидов, а они не едят :) ну или, что вероятнее, требуют свою реализацию eat.
Как в этой системе назвать человека-рабочего – зависит, на мой взгляд, от контекста. Например, у нас роботы, судя по номенклатуре Robot: Worker, всегда являются рабочими. Нет развлекательных роботов в нашем домене. Если с людьми так же (например, нет людей-директоров, которые не работают на производственной линии (мне представился завод)), то может быть просто Human: Worker. Если могут быть люди, не являющиеся рабочими – надо разбираться :)
У юных програмистов все еще в хайпе солид? Когда уже выпустят новую "серебряную пулю" для подрастающего поколения?
LSP все еще нарушается: класс наследник не должен менять поведение базового класса.
Принцип LSP гласит, что объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности этой программы.
Это означает, что класс-наследник может расширять или специализировать поведение базового класса, но не должен ему противоречить или изменять в такой степени, что нарушается ожидаемое поведение при использовании базового класса.
В моём примере нет нарушения ожидаемого поведения - оба объекта умеют перемещаться func move(), просто имеют различную реализацию, и могут быть взаимно заменены в вызывающем их коде.
Всё верно. Ибо если наследник не может менять поведение родителя, в чём тогда вообще суть наследования)
но не должен ему противоречить или изменять в такой степени
Это ты сам придумал: нет никакой степени. Плюс, ты также противоречишь сам себе: логика, которая ожидает, что птица будет лететь - поломается. Следовательно, нарушение LSP.
Какой смысл писать на Swift, когда нет кроссплатформенности?По моему C++ в связке с Objective-C решают эту проблему.
Это из какого года комментарий? И к чему он вообще здесь?
И что? Всё равно по быстродействию ваш Swift оказывается в жопе по сравнению с теми же С/C++ ))))
Swift достаточно быстр чтобы закрывать потребность в производительности для 99% задач с которыми сталкиваются iOS и Mac разработчики. И при необходимости из Swift можно вызывать Сишные библиотеки. Зато по скорости разработки Swift сильно опережает и С/С++ и Objective-C, что сейчас зачастую важнее быстродействия кода. И кстати, Swift в несколько раз быстрее Objective-C, который вы зачем-то рекомендовали ранее.
Всё в очередной раз повторяется... Очень поверхностно, а знаете почему? Потому что прежде чем писать о принципах SOLID нужно почитать книжку дядюшки Боба, и понять о чем он писал. Пожалуйста, просто прочитайте.
Кмк srp описан неверно. Цитата из книги «Модуль должен иметь одну и только одну причину для изменени» и это не про то что условный класс должен делать только что то одно. Тут вопрос со стороны акторов этого класса. Если всех устраивает его изменение в поведении - это ок. Если ожидаемое поведение для разных потребителей становится разным - принцип нарушен. Условно ваш networking manager имеет сортировку по убыванию и всех все устраивает, но появляется класс которому нужна сортировка по возрастанию, тут мы видим нарушение.
А мне, с уровнем jun++, статья очень понравилась. Читал много раз другие статьи, но все было слишком абстрактно, а тут есть примеры как должно быть и как НЕ должно.
Автор, спасибо, пиши еще.
SOLID в Swift. Простое объяснение с примерами для начинающих