Это просто смена рода деятельности. Нельзя одновременно быть программистом и руководить серьезным бизнесом. Хотя может у некоторых людей с раздвоением личности и получится :-)
Другими словами, программист может стать руководителем, но в этом момент он либо перестанет быть программистом, либо станет фиговым руководителем.
Мне показалось, что статья скорее про Waterfall vs Agile, чем про американских и русских дизайнеров.
И в этом плане ничего нового: в случае водопада вы получаете фиксированный бюджет на 100 страничное ТЗ, который будет с достоверной вероятностью нарушен. С достоверной, потому что он будет превышен если вам хоть капельку не понравится то, что вам покажут в качестве первого результата работы. А во втором случае вы можете узнать только бюджет на итерацию, т.к. о бюджете и о ТЗ на весь проект agile-компания даже разговаривать не будет, потому что аппетит у заказчика меняется с каждой итерацией и хз сколько итераций займёт проект.
Для проекта, конечно, итеративная модель разработки лучше, если он не совсем уж тривиальный и при условии, что заказчик лучше понимает свою ЦА, чем исполнитель. Но почему-то многие заказчики с неохотой на неё соглашаются, им приятнее тешить себя иллюзией, что кто-то может точно оценить бюджет и сроки проекта в самом начале.
Блин, ну если кто-то считает, что в windows есть нормальная история команд, то пусть почитает хотя бы обзорную статью о возможностях нормальной истории команд, при том, что это только «верхушка айсберга».
Думаю, если Вы напишете подобную статью, как всё это сделать не в bash, а в cmd, получите кучу плюсов в карму :-)
Есть ещё четвёртый вариант — движок на базе популярного фреймворка. Такие легко кастомизировать и расширять, а плюсом ко второму варианту идёт то, что при тех же возможностях кастомизации уже готово не только ядро, но и наиболее популярные фичи в конкретной области, будь то 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 в статье есть ошибка. На нём нельзя написать программу без классов, просто это объявление может быть неявным (сделано на уровне языка). Да и на ОО-чистоту надо проверять не так, а по возможности программировать без объектов.
Но в любом случае контекст выполнения находится всегда внутри некого объекта. Можете убедиться в этом, написав в любом месте
> ООП наследование не позволяет реализовать уменьшение интерфейса.
Да, так и есть. Наследование в ООП — это расширение интерфейса и/или переопределение методов с условием, что метод может заменить исходное предусловие эквивалентным или более слабым, а исходное постусловие — эквивалентным или более сильным. Поэтому и нельзя наследовать круг от эллипса. В таких случаях, а также когда необходимо уменьшение интерфейса следует применять факторизацию, т.е. вынесение общего в абстрактный класс.
Другими словами, программист может стать руководителем, но в этом момент он либо перестанет быть программистом, либо станет фиговым руководителем.
И в этом плане ничего нового: в случае водопада вы получаете фиксированный бюджет на 100 страничное ТЗ, который будет с достоверной вероятностью нарушен. С достоверной, потому что он будет превышен если вам хоть капельку не понравится то, что вам покажут в качестве первого результата работы. А во втором случае вы можете узнать только бюджет на итерацию, т.к. о бюджете и о ТЗ на весь проект agile-компания даже разговаривать не будет, потому что аппетит у заказчика меняется с каждой итерацией и хз сколько итераций займёт проект.
Для проекта, конечно, итеративная модель разработки лучше, если он не совсем уж тривиальный и при условии, что заказчик лучше понимает свою ЦА, чем исполнитель. Но почему-то многие заказчики с неохотой на неё соглашаются, им приятнее тешить себя иллюзией, что кто-то может точно оценить бюджет и сроки проекта в самом начале.
Думаю, если Вы напишете подобную статью, как всё это сделать не в bash, а в cmd, получите кучу плюсов в карму :-)
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 и бесплатные проприетарные вещи.