Есть ещё четвёртый вариант — движок на базе популярного фреймворка. Такие легко кастомизировать и расширять, а плюсом ко второму варианту идёт то, что при тех же возможностях кастомизации уже готово не только ядро, но и наиболее популярные фичи в конкретной области, будь то e-commerce, новостной портал или соц.сеть. Для каждой области будет отдельный движок на одном фреймворке.
Ruby 1.8.6 уже сильно не актуален. Уже состоялся последний релиз Ruby 1.8.7, осталось 11 месяцев, в которые при необходимости будут выпускать security-патчи и на этом всё.
Так что если будете делать хостинг для Ruby, делайте поддержку только 1.9.3+
Круг — это не отдельная независимая сущность, а лишь частный случай возможного состояния эллипса.
Да, в условиях отсутствия контекста применения этих классов вполне можно сказать, что класс 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 1.8.6 уже сильно не актуален. Уже состоялся последний релиз Ruby 1.8.7, осталось 11 месяцев, в которые при необходимости будут выпускать security-патчи и на этом всё.
Так что если будете делать хостинг для Ruby, делайте поддержку только 1.9.3+
Да, в условиях отсутствия контекста применения этих классов вполне можно сказать, что класс 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 летней давности, они по-прежнему хорошо на них работают.
На основании одной фразы тупо делать далеко идущие выводы. Тем более, что по сути фраза верная, лишь немного резкая по форме. А так в первую очередь для компании не выгодно, если сеньоры будут заниматься простыми задачами, т.к. в этом случае они по определению не смогут работать в состоянии потока, а значит не смогут работать эффективно. Если же это будет носить систематический характер, то специалист просто потеряет интерес к работе, которая ведёт его к профессиональной деградации, и уйдёт в другое место.