К Сlick претензий нет, пользуюсь, удобно. Есть группы, вложенная структура команд, опции, флаги, аргументы и т.п. + расширения вида click_log и указанного ниже Trogon и м.б. что еще.
Коллега написал про ООП, забыв про ООА и ООD. Также коллега ничего не сказал о DDD. OO подход в разработке (работе с требованиями, проектировании, программировании) - это активная история 90-х и 2000-х. Я в этом время стартовал свою проф. деятельность. В основе лежит восприятие человеком внешнего мира. ОО базировалось на теории типов, теории категорий, теории множеств и в целом дополняло имеющуюся на тот момент реляционную теорию с теми же корнями. А использование Xerox объектов для организации кода - лишь проявление общего подхода применительно к UI слою и немного сомнительно что Xerox был первым в ООП, учитывая наличие реляционной теории до из 70-х. Последняя с основой в теории множеств, повторюсь, как и ОО.
Ключевое в ОО подходе - это восприятие мира человеком и коммуникация человеком информацией о мире. Было декларировано, что восприятие объектно (мы воспринимаем объекты), и коммуницируем мы информацией об объектах (говоря о собаке соседа) и абстрактно об их классах (говоря о собаках в целом). А так как машина предназначена для человека, то отражения (подчеркну) отражения объектов реального мира в структуру программ (мы называем это моделью предметной области) - хороший способ их [программ] организации (о чем собственно и пишут в комментариях).
А далее выяснилось, что много предметных областей, которые существуют только в рамках компьютерных вычислений. Например - окошки, формочки и т.п. Но они то же perceivable (воспринимаемы как объекты) и хорошие кандидаты на классы.
NB: Статья чуток поверхностная и тема ОО не раскрыта даже на 10%. Scrum нет нужды оценивать, так опять же нужно было углубиться в инженерный процесс как основу и его приложения в различных контекстах (это не простая тема). Scrum - это упрощение реального процесса, организационный framework, усреднение индивидов до team collaboration (недостатков), с заявленной потенциальной пользой от возникающей синергии и накатки одного и того же процесса (выгоды). Но тут пусть другие. Не люблю Scrum.
К Сlick претензий нет, пользуюсь, удобно. Есть группы, вложенная структура команд, опции, флаги, аргументы и т.п. + расширения вида click_log и указанного ниже Trogon и м.б. что еще.
Коллега написал про ООП, забыв про ООА и ООD. Также коллега ничего не сказал о DDD. OO подход в разработке (работе с требованиями, проектировании, программировании) - это активная история 90-х и 2000-х. Я в этом время стартовал свою проф. деятельность. В основе лежит восприятие человеком внешнего мира. ОО базировалось на теории типов, теории категорий, теории множеств и в целом дополняло имеющуюся на тот момент реляционную теорию с теми же корнями. А использование Xerox объектов для организации кода - лишь проявление общего подхода применительно к UI слою и немного сомнительно что Xerox был первым в ООП, учитывая наличие реляционной теории до из 70-х. Последняя с основой в теории множеств, повторюсь, как и ОО.
Ключевое в ОО подходе - это восприятие мира человеком и коммуникация человеком информацией о мире. Было декларировано, что восприятие объектно (мы воспринимаем объекты), и коммуницируем мы информацией об объектах (говоря о собаке соседа) и абстрактно об их классах (говоря о собаках в целом). А так как машина предназначена для человека, то отражения (подчеркну) отражения объектов реального мира в структуру программ (мы называем это моделью предметной области) - хороший способ их [программ] организации (о чем собственно и пишут в комментариях).
А далее выяснилось, что много предметных областей, которые существуют только в рамках компьютерных вычислений. Например - окошки, формочки и т.п. Но они то же perceivable (воспринимаемы как объекты) и хорошие кандидаты на классы.
NB: Статья чуток поверхностная и тема ОО не раскрыта даже на 10%. Scrum нет нужды оценивать, так опять же нужно было углубиться в инженерный процесс как основу и его приложения в различных контекстах (это не простая тема). Scrum - это упрощение реального процесса, организационный framework, усреднение индивидов до team collaboration (недостатков), с заявленной потенциальной пользой от возникающей синергии и накатки одного и того же процесса (выгоды). Но тут пусть другие. Не люблю Scrum.