Круг — это не отдельная независимая сущность, а лишь частный случай возможного состояния эллипса.
Да, в условиях отсутствия контекста применения этих классов вполне можно сказать, что класс Circle излишен и убрать его совсем тоже решение. Причём при некоторых контекстах даже идеальное решение. С другой стороны может быть контекст, в котором окружность будет именно отдельной независимой сущностью без возможности стать эллипсом. Но мне что-то лень фантазировать на эту тему :-)
возврат объекта другого класса — тоже нетривиальная задача, если нужно соблюсти принцип гласящий, что код не должен знать о всех возможных реализациях интерфейса, но только сам интерфейс.
Обычно её решают как раз тривиально, в данном случае метод просто будет всегда возвращать Ellipse, а в более общем случае IFigure.
А абстрактный пример с окружностью и эллипсом сильно надуман и конкретная реализация зависит от контекста применения данных классов. В целом можно сказать, что вариантов реализации, не нарушающих SOLID, в данном примере вполне хватает.
Да, но при растягивании по одной оси круг перестаёт быть кругом, а значит методы stretch… должны либо нарушить правила наследования (установив более сильные предусловия и нарушая LSP), либо должны кидать исключения (что по сути и есть уменьшение интерфейса), либо должны возвращать объект другого типа.
Важное уточнение, только начиная с 4.0. А подобная задача мелькает на собеседованиях гораздо дольше, чем существует .NET 4.0
С Java и Perl соглашусь. Действительно языков оказалось больше, чем я полагал.
Ну а функциональные — это отдельная тема, тут изначально речь шла о PHP, в котором в stdlib этого нет, да и не в stdlib есть возможность работать со строками, содержащими большие числа, но не с целочисленным типом данных.
Ну хорошо, раз Вы сами вызвались, назовите хотя бы ещё 8 популярных языков, кроме Ruby и Python (чтобы до десятка добрать), которые в стандартной библиотеке имеют целочисленный тип, способный вместить 1000!
Под аббревиатурой ООП скрываются два разных понятия: объектно-ориентированное проектирование и объектно-ориентированное программирование. ОО-проектирование можно использовать на любом языке и понимать под объектом что угодно, хоть указатель на кучу. То, что обсуждается в статье, имеет отношение именно к проектированию.
А ОО-программирование накладывает лишь одно условие: всё есть объект, причём объект — экземпляр класса. Ну и как следствие, класс есть объект :-)
При программировании на языке с полной поддержкой этого условия, типа Ruby, у вас будет не 95, а 100% кода удовлетворять этой идее.
P.S. Кстати, насчёт Ruby в статье есть ошибка. На нём нельзя написать программу без классов, просто это объявление может быть неявным (сделано на уровне языка). Да и на ОО-чистоту надо проверять не так, а по возможности программировать без объектов.
Но в любом случае контекст выполнения находится всегда внутри некого объекта. Можете убедиться в этом, написав в любом месте
> ООП наследование не позволяет реализовать уменьшение интерфейса.
Да, так и есть. Наследование в ООП — это расширение интерфейса и/или переопределение методов с условием, что метод может заменить исходное предусловие эквивалентным или более слабым, а исходное постусловие — эквивалентным или более сильным. Поэтому и нельзя наследовать круг от эллипса. В таких случаях, а также когда необходимо уменьшение интерфейса следует применять факторизацию, т.е. вынесение общего в абстрактный класс.
Да о чём спор? Должно быть и то и то и OpenID :-)
Сайты, которые не дают зарегистрировать аккаунт с помощью классической пары email+пароль, явно отдают несерьёзностью.
С другой стороны дополнить классический вариант авторизацией через соц.сети мало кому мешает.
Вряд ли для внутренних систем компании, у которой строгий корпоративный стиль подойдут «мультяшные» прототипы. :)
Подойдут. Не знаю почему, видимо тут что-то на уровне психологии, но когда показываешь прототип с конечными шрифтами, то его начинают воспринимать как дизайн, что в корне не правильно и опускает уровень обсуждения до элементов оформления, что на стадии прототипа вообще ни малейшей роли не играет.
пока буду юзать более «строгий» и лично для меня более удобный MockFlow
Шрифт можно заменить на какой угодно, просто переопределите CSS, который я выше указывал.
Хотя по моему опыту ощущение «мультяшности» просто необходимо для прототипов, если вы собираетесь показывать их заказчику.
Вы забываете что большинство зданий возводятся по типовому проекту. Это ближе к установке CMS в одной из базовых комплектаций, чем к разработке ПО. При строительстве здания по уникальному проекту только разработка арх.проекта и то легко займёт пару лет, не говоря уж про само строительство.
А здания, которые стоят веками, составляют ничтожный процент от общего количества построенного за эти века. К тому же практически все они входят в 3 типа: совсем примитивные, совсем аварийные и памятники-архитектуры. Последние не используются по прямому назначению и для их поддержания в адекватном состоянии выделяются огромные бюджеты.
Однако ПО само по себе не изнашивается в отличии от зданий, т.е. срок жизни программного обеспечения ограничен только сроком жизни типа оборудования, на котором его можно запускать. Разумеется это как минимум десятки лет.
Другой вопрос в моральном устаревании, которое появляется из-за изменений требований к ПО, а отнюдь не из-за внутренних проблем в ПО. Так что пример с ПО для спутников вовсе не единственный, возьмите сотни программ для компьютеров 30 летней давности, они по-прежнему хорошо на них работают.
Повеяло субъективными определениями… А что «черная работа» для неё?
На основании одной фразы тупо делать далеко идущие выводы. Тем более, что по сути фраза верная, лишь немного резкая по форме. А так в первую очередь для компании не выгодно, если сеньоры будут заниматься простыми задачами, т.к. в этом случае они по определению не смогут работать в состоянии потока, а значит не смогут работать эффективно. Если же это будет носить систематический характер, то специалист просто потеряет интерес к работе, которая ведёт его к профессиональной деградации, и уйдёт в другое место.
Мой комментарий (чуть выше) о том же самом как-то остался незамеченным… Действительно Ruby или Python дадут вычислить 1000!
Но делать это через рекурсию не стоит хотя бы потому, что глупо забивать стек при реализации задачи, вовсе не требующей рекурсии. Но Ruby и Python — скорее исключения (и то надо не recursion limit поднимать, а обычным циклом считать), т.к. для большинства языков программирования не хватит возможностей stdlib для написания за 5 минут метода, вычисляющего факториал (для теста хотя бы тот же 1000!). Просто тупо не будет целочисленного типа данных, в который влезет результат. Это можно обойти, но не за пару минут…
Cравнивать надо процент от зарплаты на руки, который ушёл на одинаковое кол-во товаров, как вы их назвали «расходы на жизнь». А то у вас получается идиотическая ситуация: живете в России, а думаете что можно купить на вашу зарплату в США. Определитесь уж с местом жительства, а то на доставке разоритесь быстрее, чем на колебаниях курса :-)
Да, в условиях отсутствия контекста применения этих классов вполне можно сказать, что класс Circle излишен и убрать его совсем тоже решение. Причём при некоторых контекстах даже идеальное решение. С другой стороны может быть контекст, в котором окружность будет именно отдельной независимой сущностью без возможности стать эллипсом. Но мне что-то лень фантазировать на эту тему :-)
Обычно её решают как раз тривиально, в данном случае метод просто будет всегда возвращать Ellipse, а в более общем случае IFigure.
А абстрактный пример с окружностью и эллипсом сильно надуман и конкретная реализация зависит от контекста применения данных классов. В целом можно сказать, что вариантов реализации, не нарушающих SOLID, в данном примере вполне хватает.
Важное уточнение, только начиная с 4.0. А подобная задача мелькает на собеседованиях гораздо дольше, чем существует .NET 4.0
С Java и Perl соглашусь. Действительно языков оказалось больше, чем я полагал.
Ну а функциональные — это отдельная тема, тут изначально речь шла о PHP, в котором в stdlib этого нет, да и не в stdlib есть возможность работать со строками, содержащими большие числа, но не с целочисленным типом данных.
А ОО-программирование накладывает лишь одно условие: всё есть объект, причём объект — экземпляр класса. Ну и как следствие, класс есть объект :-)
При программировании на языке с полной поддержкой этого условия, типа Ruby, у вас будет не 95, а 100% кода удовлетворять этой идее.
P.S. Кстати, насчёт Ruby в статье есть ошибка. На нём нельзя написать программу без классов, просто это объявление может быть неявным (сделано на уровне языка). Да и на ОО-чистоту надо проверять не так, а по возможности программировать без объектов.
Но в любом случае контекст выполнения находится всегда внутри некого объекта. Можете убедиться в этом, написав в любом месте
Да, так и есть. Наследование в ООП — это расширение интерфейса и/или переопределение методов с условием, что метод может заменить исходное предусловие эквивалентным или более слабым, а исходное постусловие — эквивалентным или более сильным. Поэтому и нельзя наследовать круг от эллипса. В таких случаях, а также когда необходимо уменьшение интерфейса следует применять факторизацию, т.е. вынесение общего в абстрактный класс.
Более того есть даже коммерческий Open Source и бесплатные проприетарные вещи.
Сайты, которые не дают зарегистрировать аккаунт с помощью классической пары email+пароль, явно отдают несерьёзностью.
С другой стороны дополнить классический вариант авторизацией через соц.сети мало кому мешает.
Подойдут. Не знаю почему, видимо тут что-то на уровне психологии, но когда показываешь прототип с конечными шрифтами, то его начинают воспринимать как дизайн, что в корне не правильно и опускает уровень обсуждения до элементов оформления, что на стадии прототипа вообще ни малейшей роли не играет.
тоже хороший вариант :-)
Хотя по моему опыту ощущение «мультяшности» просто необходимо для прототипов, если вы собираетесь показывать их заказчику.
А вообще подобные шрифты обычно используют, чтобы было видно, что это набросок, а не дизайн.
А здания, которые стоят веками, составляют ничтожный процент от общего количества построенного за эти века. К тому же практически все они входят в 3 типа: совсем примитивные, совсем аварийные и памятники-архитектуры. Последние не используются по прямому назначению и для их поддержания в адекватном состоянии выделяются огромные бюджеты.
Однако ПО само по себе не изнашивается в отличии от зданий, т.е. срок жизни программного обеспечения ограничен только сроком жизни типа оборудования, на котором его можно запускать. Разумеется это как минимум десятки лет.
Другой вопрос в моральном устаревании, которое появляется из-за изменений требований к ПО, а отнюдь не из-за внутренних проблем в ПО. Так что пример с ПО для спутников вовсе не единственный, возьмите сотни программ для компьютеров 30 летней давности, они по-прежнему хорошо на них работают.
На основании одной фразы тупо делать далеко идущие выводы. Тем более, что по сути фраза верная, лишь немного резкая по форме. А так в первую очередь для компании не выгодно, если сеньоры будут заниматься простыми задачами, т.к. в этом случае они по определению не смогут работать в состоянии потока, а значит не смогут работать эффективно. Если же это будет носить систематический характер, то специалист просто потеряет интерес к работе, которая ведёт его к профессиональной деградации, и уйдёт в другое место.
Но делать это через рекурсию не стоит хотя бы потому, что глупо забивать стек при реализации задачи, вовсе не требующей рекурсии. Но Ruby и Python — скорее исключения (и то надо не recursion limit поднимать, а обычным циклом считать), т.к. для большинства языков программирования не хватит возможностей stdlib для написания за 5 минут метода, вычисляющего факториал (для теста хотя бы тот же 1000!). Просто тупо не будет целочисленного типа данных, в который влезет результат. Это можно обойти, но не за пару минут…