Описание структуры сущностей в ООП — не главное.
Ради чего всё создаётся — взаимодействие между сущностями в предметке.
Сущности взаимодействуют по протоколам.
Описание актов взаимодействия сущностей предметной области через предоставляемый функционал, описываемый через интерфейсы/абстрактные классы — вырожденный случай описания последовательностей взаимодействия. Только лишь потому, что нет адекватных синтаксических конструкций описания последовательности такого взаимодействия во времени (в модельной временной шкале). Вернее такое средство есть только в одном единственном языке — Zonnon.
«Наследование» подавляющим большинством народа понимается в корне неверно. Люди путают наследование, как выделение общих свойств на этапе анализа предметной области с механизмом обеспечения повторного использования кода на этапе реализации.
ООП — НЕ подразумевает какой-то конкретный язык. Не помню, но кто-то из создателей Smalltalk-а сказал «когда мы создавали ООП, мы не имели в виду С++». В моей практике я использовал ОО[А|Д|П] во всех языках реализации, вне зависимости от наличия «поддержки ООП» в конкретном использованном языке (конкретно использовались: ассемблеры AVR, ADSP21xx, C, C++, Smalltalk, FORTH (про ФОРТ — отдельный, самый интересный, разговор ;) )) — главное, что бы была возможность адресоваться к области памяти, хранящей состояние экземпляра «класса». Сама модель поддержки ООП в данном языке значения не имеет. Есть — хорошо. Нет — достигается средствами её самодельной эмуляции и через препроцессинг. Порой (по задаче) не нужна даже VMT.
Дальше.
Неправильно народ также понимает и «полиморфизм» и «активность» объектов.
Полиморфизм НЕ требует наличия свойства наследования в языке. Это — лишь дань выбранному способу поддержки решений, принятых на этапе анализа системы + способ реализации повторного использования кода.
Полиморфизм можно реализовывать не только через «статические аспекты описания классов» — традиционный подход на сегодня, но и — через едиснтвенную «точку доступа» — канал связи с сущностью. Здесь полиморфность экземпляра реализуется через соответствие объекта-клиента, инициировавшего обмен с «сервером», тому протоколу обмена, который анонсировал объект«сервер», для реализации нужной функциональности. Например, типизированные каналы в Go — вырожденный случай описания на разновидности РБНФ дисциплины обмена по данному каналу с данным объектом-сервером в языке Zonnon. Конечный автомат, сгенерированный по такому описанию к каналу проверяет все аспекты обмена по своему каналу (последовательности присылаемых полей в сообщении, их тип и разрешённые значения). Прелесть здесь в том, что взаимодействие не сводится только к атомарным «одноразовым» обменам между клиентом и сервером. Такое взаимодействие может быть совершенно произвольным по временной протяжённости и количеству актов взаимодействий (с произвольными перерывами между актами обмена) — всё зависит от того, что вы описали в РБНФ-описании автомата на канале.
Активность.
Активный объект – это НЕ объект, в который «заходит» поток ОС.
Понятие «поток ОС» должно быть совершенно выброшено из лексикона разработчиков. Исключение может быть только в случае разработки частей, работающих с сущностями операционной системы, непосредственно на уровне ОС.
Да, активный объект имеет в своём составе «поток ОС», реализующий его «жизненный цикл» («активность»). Но на уровне прикладных задач потоков НЕТ и быть не может. «Поток» — название чего-то, с чем имеет дело операционная система, а не ваша задача. Стартующий поток ОС, в котором реализуется «активность/жизненный цикла активного объекта», должен начинать работать ТОЛЬКО в контексте его объекта-владельца. Ещё раз: поток операционной системы, реализующий жизненный цикл активного объекта НИЧЕГО не знает, кроме ссылки на экземпляр своего владельца-«запускателя» и точки входа метода класса этого объекта, реализующего активность в рамках экземпляра этого класса.
(Тут следует упомянуть пагубность широко распространённой практики получения «активных» объектов путём наследования от библиотечных классов-«оберток» над системными потоками. Это — в корне неверно. Авторы таких решений могут сколько угодно рассуждать об ООП, но совершают совершенно дичайшую ошибку уже на этапе анализа и дизайна своей системы: наследование подразумевает принадлежность потомка и наличие у него признаков наследуемого класса. НО! в 99.999999999% случаев ВАШ объект из ВАШЕЙ задачи НЕ ЯВЛЯЕТСЯ ПОТОКОМ! Активным объектом — ДА. ПОТОКОМ — НЕТ.)
Активности в процессе реализации жизненных циклов своих хозяев «посещают» контексты экземпляров других объектов.
Совокупность всех жизненных циклов активных объектов, определённых в вашей системе и составляют, собственно, её «функционирование».
В заключение ещё небольшое замечание, которое может устранить неимоверно огромное количество ошибок и послужить отличнейшим базисом для «тестопригодности» всей совокупности объектов вашей системы.
При проектировании ООП-системы все интерфейсные методы должны быть или командами, или запросами.
Команды не должны возвращать результата. Результат исполнения команды должен проверяться в отдельном запросе.
Запросы НИ В КОЕМ СЛУЧАЕ не могут иметь побочных действий.
Команды воздействую на состояние только указанного объекта. Что бы было понятно, то случай, типа пресловутого if( (result = obj.read( file, buffer, n)) ) должны быть просто исключены из практики программирования. Состояние объекта после команды проверяйте в последующем запросе.
Конечно, как и всякий НОРМАЛЬНЫЙ человек, предусматриваю.
А вы — не?
Что-то летящее сверху и попадание — это уже совершённое действие, результат неправильной оценки рисков и ситуаций.
У нормальных людей принято, что легче снизить вероятность неприятности, уклониться от неё, проверить на признаки её приближения или наступления, чем обеспечить «разгребание по факту произошедшего». Как? А никогда не смотрели «Пластилиновую ворону»? «Не стойте и не прыгайте, не пойте, не пляшите, там где идёт строительство или подвешен груз.» Я не хожу там, где что-то может сверху упасть. На счёт летящего из окон — уже давно были придуманы широкополые шляпы. Вы что же думаете, зря, что ли, Д'Артаньян сотоварищи ими в Париже пользовались? Там ведь, даже в Версале, штатно отхожих мест не было. Дамы и кавалеры, если не в ведро, так — натурально — в окно нужды справляли.
А для того, что бы не подскользнуться, НОРМАЛЬНЫЕ люди или соответствующую обувь надевают, или что-то делают с подошвой или поверх обуви используют ледоступы.
Даже летящий рояль сверху — тоже в пределах домена. Просто в этом случае «система» уже не имеет средств и ресурсов к противодействию.
Да — что там «рояли». Я, если в Питер или в Архангельск еду летом, всё равно с собой свитер захватываю. Та же Предусмотрительность.
Я не понимаю вашего неразумения.
Вы — действительно аналитик?
А что, в Омске, вне зависимости от места нахождения преподавателей основ информатики, постоянно что-то с неба валится?
Вы — не из тех аналитиков, что класс «счёт» наследуют множественно от классов «клиент» и «блюдо»?
Ой-ой-ой…
Всё — ещё серьёзнее, чем показалось в начале.
Как там один мудрец сказал? «Есть ситуации, при которых если надо ещё что-то объяснять, то объяснять уже ничего не надо».
Давайте лучше останемся «при своих»?
Успехов!
Хорошо. Начнём с начала.
ЧТО и КАК вы поняли? В двух-трёх предложениях, пожалуйста.
(А то ведь, как оно бывает. Работаешь в отрасли больше четверти века. Твои системы уже эксплуатируются в изделиях в авиации (и — «чуток» повыше и подальше), а потом приходит вьюноша-спец, у которого в скилах стоит нечто вроде «профессиональная разработка сайтов» и начинает тебе объяснять, «как правильно»… Несколько забавная и курьёзная ситуация, не находите?
А есть разница?
Типа, как «мягкое реальное время» а ля Майкрософт?
Самолёт, он, знаете ли, или летает, или это — не самолёт.
Как и в разработке медоборудования для палат интенсивной терапии нет понятия «немножечко неживой».
Можно сколько угодно размахивать флажками и дудеть в трубы возле разрекламированной вундервафли. Можно даже навыпускать её в количестве нескольких сотен. Но это — будет либо то, что называется «полное соответствие с ТЗ», либо — мёртвая конячка, каждый дрыг которой сопровождается и обеспечивается магическими ритуалами и отписками.
Господи, помилуй!
Ну, а здесь-то — за что было минусовать?!
Здесь было что-то высказано супротив природы или логики развития отраслей и социумов?
Или — просто у кого-то не совпало с детскими хотелками на счёт устройства Мира?
Ну так — напишите свои соображения и/или обоснования…
Хотя бы по поставленному минусу.
Раньше хабра касался только по чтению заинтересовавших статей. Не обращая внимания и не зная, что, оказывается, тут есть хитровыделанная система рейтингов и оценок. И, к моему разочарованию, эта система поддерживает случай, когда толпа малолеток или, введённых в заблуждение, граждан, совместными усилиями могут совершенно «затоптать» здравые высказывания и мысли.
Это ж где такой ужас преподают и в виде знания накапливают???
Примените ваше предложение к случаю, когда было проигнорировано опустошение резервуара с инсулином на инсулиновой помпе, устанавливаемой в палате интенсивной терапии…
Или поработайте с таким же подходом при реализации автопилота на самолёте, когда не была заложена реакция на внезапное скольжение в режиме посадки…
Вы согласны на отсидку годиков так на десять в виде платы за «разгребание последствий маловероятного события» и/или «игнорирования маловероятной нештатной ситуации»?
Случаи специально экстраполированы до утрирования. Но, обычно, именно такой метод позволяет показывать пагубность сложившихся, в некритичных областях ИТ. практик и их натягивания на традиционно рисковые области разработок.
Про прошивку.
Смена (относительно «безболезненная») рода занятий большинством представителей некоего социума возможна лишь при условии гарантированности существования этих представителей на период овладения новой специальностью и «въезжания» в неё.
Понятно, что пока человек ещё «подмастерье», то и претендовать он может только на небольшую часть вознаграждения за свой труд. Ну просто потому, что ещё нет навыков и есть огромное количество времени, растрачиваемое на «окончательную притирку» и исправления брака, делающегося в новых условиях.
Вопрос в том, хватает ли этой «небольшой части» для поддержания минимально приемлемого уровня жизни?
Почему в обществе, в последние годы (где-то с конца 60-х) начала распространятся уверенность «независимости от прошивки»?
И — в каком обществе?
Обобщённо, можно сказать, что этому способствует два рода факторов.
Первый — со стороны рода занятий. Прогресс обеспечил появление набора специальностей, порог вхождения в которые не предполагает каких-то особенных физических качеств или приложения значимых (не говоря уж о запредельных) интеллектуальных усилий. Примером можно привести положение из нашей отрасли: теперь любой человек из мира веба стал называться программистом.
Второй — со стороны общества. Переходы из специальности в специальность возможны, когда сама структура производства общественного продукта предполагает безболезненность нахождения в обществе огромной армии людей, меняющих свой род занятий несколько раз в жизни и находящихся в периодах «неполной отдачи и низкокачественного выхода продукции в это время». Остаётся разобраться в причинах такой «терпимости».
Очевидно, что такое положение вещей может быть только в том социуме, который не находится на грани выживания или в зоне риска. Иначе бы всё сводилось бы к фразе из анекдота «а — чего думать? прыгать надо!»
С одной стороны очень хорошо, что человек имеет возможность попробовать себя в разных точках приложения себя, пока не найдёт своё дело. С другой необходима объективная оценка рисков для общества в целом растраты ценных ресурсов на упомянутые «периоды переквалификации» и на ту часть общества, которая делает не своё дело.
Если вам надоело обсуждение данной темы, предлагаю его прекратить, потому, что могут начать вылезать аргументы и логические цепочки доказательств своей правоты, уводящие нас в совершенные дебри форумной дискуссии… :)
И — что?
Я в чём-то не прав?
Лучше же и для человека, и для его нанимателей, что бы человек занимался СВОИМ делом, а — не «ломать его через коленку»!
Человек может ошибаться или заблуждаться на счёт того, что — ЕГО.
Но надо, всё равно, дать ему шанс.
Одна моя одногруппница закончила два технических вуза. Десять лет проработала в инженерной специальности. Потом была просто каким-то офис-менеджером. А потом — просто плюнула на всё и пошла в третий раз в ВУЗ. Закончила инъяз в универе с педагогическими мотивами. И это — уже около сорока ей было. Оказывается она всю жизнь мечтала преподавать иностранные языки маленьким деткам. И теперь она рада и счастлива. И вспоминает с ужасом то время, когда пошла на поводу у родителей и их наставлений и ЗАСТАВЛЯЛА себя заниматься тем, что ей не нравилось и было НЕ ЕЁ.
Я сам не сказать, что поменял специальность, но — специализацию в ИТ.
Начинал на кафедре. Занимался моделированием сложных (социо-технических) систем, потом принимал участие в разрабатке биллинговых систем. А потом — тоже — махнул рукой и, в довольно зрелом возрасте, ушёл в эмбеддинг и разработку систем управления.
И обрёл нирвану…
… совместно с глубочайшим удовлетворением начальства и заказчиков.
Деньги определяют многое, но — не всё. Когда начинаешь понимать, что живёшь не своей жизнью, надо что-то менять. Критерий хорошей оплаты за тобой сделанное, без творческого удовлетворения от этого сделанного — довольно сомнителен. А если ещё и удаётся найти коллектив таких же коллег, занимающимся СВОИМ делом, то эффекты могут быть поразительными. Даже производительность труда и качество продукции на выходе становятся на порядки выше, чем у «тех, кто на галерах». Причём, часто никто в таких коллективах не заморачивается новыми процессами (кого куда усадить, какие роли навесить и какие артефакты в процессе согласования выпускать). Никто не агитирует за необходимость изучать что-то новое. Всё работает, как часики и идёт — как «по маслу». Я уже упоминал о своём опыте, когда мы, вдвоём с электронщиком, за два с половиной года, «выкатили» комплексную систему сбора, хранения и последующей наземной обработки и анализа полётных данных, лучшую и с большим потенциалом расширения функционала, чем наши конкуренты, в количестве 15-20 человек, смогли сварганить за почти 10 лет работы. Это — не похвальба и не фантазии. Это — показатель.
Вы, скорее всего, попутали адресата ваших упрёков на счёт ФП.
Связь между мной и ФП ограничивается только наличием набора книг Душкина и прочих корифеев ФП на одной из моих книжных полок, но прочитанных максимум до благодарностей в разделах введений в этих книжек. :)
А вот с ООП я работаю с 1988 года.
… и, как мне кажется, вы совершенно неверно воспринимаете или интерпретируете понятие «глобальное состояние». В последнем абзаце вы «агрегировали» состояния отдельных объектов, реализующих функциональности БД, кешев, пулов коннектов и «прочего» в некое «глобальное состояние».
Поймите, что, упоминаемые вами, «кеши» и «пулы» — лишь инструменты/структуры для реализации объектов более высокого уровня.
Обычно на уровне предметной области (от встроенных систем и — до, например, управления каскадом ГЭС или программ моделирования экономических систем размером с государство), понятий «кеш» или «пул» — НЕТ. Если же они там появляются, значит авторы модели предметной области смешали семантические уровни в своих моделях.
Даже если у меня есть «пулы» на уровне, например, какой-то ОСРВ или библиотеки, то напрямую нагружать их понятийностью или реализацией функционала из предметной области — будет ОГРОМНОЙ ошибкой.
Списки, кеши, пулы могут реализовывать и поддерживать внутренние и состояния выделенных объектов предметных областей, но сами они НЕ МОГУТ являться носителями сущностей этих областей.
Это примерно также, как с широко распространённой ошибкой получения «активных объектов» через наследование от класса Поток во многих библиотеках классов (от Delphi и — до Явы). Авторы этих библиотек сделали колоссальную методологическую ошибку, позволив неокрепшим молодым умам программистов реализовывать активность объектов в своих системах через реализацию некоего унаследованного от класса Thread виртуального метода Execute или Run. В результате массовое программистское мышление не только было отодвинуто от верного шаблона реализации активных объектов, но и убеждено в том, что именно так и надо делать…
Все ваши сомнения и сарказм мигом улетучатся, если вы овладеете ООАДП.
Из вашего последнего абзаца (
А во втором случае опять заниматься синхронизацией изменений с разных потоков. И все это с довольно туманными целями. Потому что не понятно, что мне помешает поломать состояние при пересоздании так же, как и при модификации.
) я понял, что вы про активные объекты не слышали. Причём, я прошу заметить, что при проектировании на уровне системы активных объектов у разработчиков, при разговоре на уровне их предметной области, появление слов «поток» и «мьютекс» — показатель лютой непрофпригодности. :)
В предметной области обычно НЕТ понятия «приложение». (Если только вы не работаете на уровне ядра ОС или её планировщика процессов)
Что за объект предметной в вашей области у вас ответственен за реализацию понятия «место хранения данных из приходящих сообщений»?
Если у кого-то возникает потребность в «логической необходимости» учёта глобального состояния программы, значит он сталкивается с кардинальным просчётом в архитектуре проектируемой системы.
ыт депендз.
До сих именно эта «странность» мне помогала сделать за два-три года больше, чем дюжина разрабов за восемь лет не могла добиться. Причём, как я уже упоминал, в областях, куда любой веб-разраб даже подумать приблизиться побоится.
Ради чего всё создаётся — взаимодействие между сущностями в предметке.
Сущности взаимодействуют по протоколам.
Описание актов взаимодействия сущностей предметной области через предоставляемый функционал, описываемый через интерфейсы/абстрактные классы — вырожденный случай описания последовательностей взаимодействия. Только лишь потому, что нет адекватных синтаксических конструкций описания последовательности такого взаимодействия во времени (в модельной временной шкале). Вернее такое средство есть только в одном единственном языке — Zonnon.
«Наследование» подавляющим большинством народа понимается в корне неверно. Люди путают наследование, как выделение общих свойств на этапе анализа предметной области с механизмом обеспечения повторного использования кода на этапе реализации.
ООП — НЕ подразумевает какой-то конкретный язык. Не помню, но кто-то из создателей Smalltalk-а сказал «когда мы создавали ООП, мы не имели в виду С++». В моей практике я использовал ОО[А|Д|П] во всех языках реализации, вне зависимости от наличия «поддержки ООП» в конкретном использованном языке (конкретно использовались: ассемблеры AVR, ADSP21xx, C, C++, Smalltalk, FORTH (про ФОРТ — отдельный, самый интересный, разговор ;) )) — главное, что бы была возможность адресоваться к области памяти, хранящей состояние экземпляра «класса». Сама модель поддержки ООП в данном языке значения не имеет. Есть — хорошо. Нет — достигается средствами её самодельной эмуляции и через препроцессинг. Порой (по задаче) не нужна даже VMT.
Дальше.
Неправильно народ также понимает и «полиморфизм» и «активность» объектов.
Полиморфизм НЕ требует наличия свойства наследования в языке. Это — лишь дань выбранному способу поддержки решений, принятых на этапе анализа системы + способ реализации повторного использования кода.
Полиморфизм можно реализовывать не только через «статические аспекты описания классов» — традиционный подход на сегодня, но и — через едиснтвенную «точку доступа» — канал связи с сущностью. Здесь полиморфность экземпляра реализуется через соответствие объекта-клиента, инициировавшего обмен с «сервером», тому протоколу обмена, который анонсировал объект«сервер», для реализации нужной функциональности. Например, типизированные каналы в Go — вырожденный случай описания на разновидности РБНФ дисциплины обмена по данному каналу с данным объектом-сервером в языке Zonnon. Конечный автомат, сгенерированный по такому описанию к каналу проверяет все аспекты обмена по своему каналу (последовательности присылаемых полей в сообщении, их тип и разрешённые значения). Прелесть здесь в том, что взаимодействие не сводится только к атомарным «одноразовым» обменам между клиентом и сервером. Такое взаимодействие может быть совершенно произвольным по временной протяжённости и количеству актов взаимодействий (с произвольными перерывами между актами обмена) — всё зависит от того, что вы описали в РБНФ-описании автомата на канале.
Активность.
Активный объект – это НЕ объект, в который «заходит» поток ОС.
Понятие «поток ОС» должно быть совершенно выброшено из лексикона разработчиков. Исключение может быть только в случае разработки частей, работающих с сущностями операционной системы, непосредственно на уровне ОС.
Да, активный объект имеет в своём составе «поток ОС», реализующий его «жизненный цикл» («активность»). Но на уровне прикладных задач потоков НЕТ и быть не может. «Поток» — название чего-то, с чем имеет дело операционная система, а не ваша задача. Стартующий поток ОС, в котором реализуется «активность/жизненный цикла активного объекта», должен начинать работать ТОЛЬКО в контексте его объекта-владельца. Ещё раз: поток операционной системы, реализующий жизненный цикл активного объекта НИЧЕГО не знает, кроме ссылки на экземпляр своего владельца-«запускателя» и точки входа метода класса этого объекта, реализующего активность в рамках экземпляра этого класса.
(Тут следует упомянуть пагубность широко распространённой практики получения «активных» объектов путём наследования от библиотечных классов-«оберток» над системными потоками. Это — в корне неверно. Авторы таких решений могут сколько угодно рассуждать об ООП, но совершают совершенно дичайшую ошибку уже на этапе анализа и дизайна своей системы: наследование подразумевает принадлежность потомка и наличие у него признаков наследуемого класса. НО! в 99.999999999% случаев ВАШ объект из ВАШЕЙ задачи НЕ ЯВЛЯЕТСЯ ПОТОКОМ! Активным объектом — ДА. ПОТОКОМ — НЕТ.)
Активности в процессе реализации жизненных циклов своих хозяев «посещают» контексты экземпляров других объектов.
Совокупность всех жизненных циклов активных объектов, определённых в вашей системе и составляют, собственно, её «функционирование».
В заключение ещё небольшое замечание, которое может устранить неимоверно огромное количество ошибок и послужить отличнейшим базисом для «тестопригодности» всей совокупности объектов вашей системы.
При проектировании ООП-системы все интерфейсные методы должны быть или командами, или запросами.
Команды не должны возвращать результата. Результат исполнения команды должен проверяться в отдельном запросе.
Запросы НИ В КОЕМ СЛУЧАЕ не могут иметь побочных действий.
Команды воздействую на состояние только указанного объекта. Что бы было понятно, то случай, типа пресловутого if( (result = obj.read( file, buffer, n)) ) должны быть просто исключены из практики программирования. Состояние объекта после команды проверяйте в последующем запросе.
Фууууухххх…
Пока — всё. :)
Михаэль Франц шлёт всем инноваторам горячий привет из поздних 80-х…
А вы — не?
Что-то летящее сверху и попадание — это уже совершённое действие, результат неправильной оценки рисков и ситуаций.
У нормальных людей принято, что легче снизить вероятность неприятности, уклониться от неё, проверить на признаки её приближения или наступления, чем обеспечить «разгребание по факту произошедшего». Как? А никогда не смотрели «Пластилиновую ворону»? «Не стойте и не прыгайте, не пойте, не пляшите, там где идёт строительство или подвешен груз.» Я не хожу там, где что-то может сверху упасть. На счёт летящего из окон — уже давно были придуманы широкополые шляпы. Вы что же думаете, зря, что ли, Д'Артаньян сотоварищи ими в Париже пользовались? Там ведь, даже в Версале, штатно отхожих мест не было. Дамы и кавалеры, если не в ведро, так — натурально — в окно нужды справляли.
А для того, что бы не подскользнуться, НОРМАЛЬНЫЕ люди или соответствующую обувь надевают, или что-то делают с подошвой или поверх обуви используют ледоступы.
Даже летящий рояль сверху — тоже в пределах домена. Просто в этом случае «система» уже не имеет средств и ресурсов к противодействию.
Да — что там «рояли». Я, если в Питер или в Архангельск еду летом, всё равно с собой свитер захватываю. Та же Предусмотрительность.
Я не понимаю вашего неразумения.
Вы — действительно аналитик?
Вы — не из тех аналитиков, что класс «счёт» наследуют множественно от классов «клиент» и «блюдо»?
Всё — ещё серьёзнее, чем показалось в начале.
Как там один мудрец сказал? «Есть ситуации, при которых если надо ещё что-то объяснять, то объяснять уже ничего не надо».
Давайте лучше останемся «при своих»?
Успехов!
ЧТО и КАК вы поняли? В двух-трёх предложениях, пожалуйста.
(А то ведь, как оно бывает. Работаешь в отрасли больше четверти века. Твои системы уже эксплуатируются в изделиях в авиации (и — «чуток» повыше и подальше), а потом приходит вьюноша-спец, у которого в скилах стоит нечто вроде «профессиональная разработка сайтов» и начинает тебе объяснять, «как правильно»… Несколько забавная и курьёзная ситуация, не находите?
Типа, как «мягкое реальное время» а ля Майкрософт?
Самолёт, он, знаете ли, или летает, или это — не самолёт.
Как и в разработке медоборудования для палат интенсивной терапии нет понятия «немножечко неживой».
Можно сколько угодно размахивать флажками и дудеть в трубы возле разрекламированной вундервафли. Можно даже навыпускать её в количестве нескольких сотен. Но это — будет либо то, что называется «полное соответствие с ТЗ», либо — мёртвая конячка, каждый дрыг которой сопровождается и обеспечивается магическими ритуалами и отписками.
Дальше — просто читать не стал.
Удачи вам!
Особенно — не попадать на самолёты, системы управления которых, спроектированы вашими единомышленниками… :)
Ну, а здесь-то — за что было минусовать?!
Здесь было что-то высказано супротив природы или логики развития отраслей и социумов?
Или — просто у кого-то не совпало с детскими хотелками на счёт устройства Мира?
Ну так — напишите свои соображения и/или обоснования…
Хотя бы по поставленному минусу.
Раньше хабра касался только по чтению заинтересовавших статей. Не обращая внимания и не зная, что, оказывается, тут есть хитровыделанная система рейтингов и оценок. И, к моему разочарованию, эта система поддерживает случай, когда толпа малолеток или, введённых в заблуждение, граждан, совместными усилиями могут совершенно «затоптать» здравые высказывания и мысли.
Примените ваше предложение к случаю, когда было проигнорировано опустошение резервуара с инсулином на инсулиновой помпе, устанавливаемой в палате интенсивной терапии…
Или поработайте с таким же подходом при реализации автопилота на самолёте, когда не была заложена реакция на внезапное скольжение в режиме посадки…
Вы согласны на отсидку годиков так на десять в виде платы за «разгребание последствий маловероятного события» и/или «игнорирования маловероятной нештатной ситуации»?
Случаи специально экстраполированы до утрирования. Но, обычно, именно такой метод позволяет показывать пагубность сложившихся, в некритичных областях ИТ. практик и их натягивания на традиционно рисковые области разработок.
Смена (относительно «безболезненная») рода занятий большинством представителей некоего социума возможна лишь при условии гарантированности существования этих представителей на период овладения новой специальностью и «въезжания» в неё.
Понятно, что пока человек ещё «подмастерье», то и претендовать он может только на небольшую часть вознаграждения за свой труд. Ну просто потому, что ещё нет навыков и есть огромное количество времени, растрачиваемое на «окончательную притирку» и исправления брака, делающегося в новых условиях.
Вопрос в том, хватает ли этой «небольшой части» для поддержания минимально приемлемого уровня жизни?
Почему в обществе, в последние годы (где-то с конца 60-х) начала распространятся уверенность «независимости от прошивки»?
И — в каком обществе?
Обобщённо, можно сказать, что этому способствует два рода факторов.
Первый — со стороны рода занятий. Прогресс обеспечил появление набора специальностей, порог вхождения в которые не предполагает каких-то особенных физических качеств или приложения значимых (не говоря уж о запредельных) интеллектуальных усилий. Примером можно привести положение из нашей отрасли: теперь любой человек из мира веба стал называться программистом.
Второй — со стороны общества. Переходы из специальности в специальность возможны, когда сама структура производства общественного продукта предполагает безболезненность нахождения в обществе огромной армии людей, меняющих свой род занятий несколько раз в жизни и находящихся в периодах «неполной отдачи и низкокачественного выхода продукции в это время». Остаётся разобраться в причинах такой «терпимости».
Очевидно, что такое положение вещей может быть только в том социуме, который не находится на грани выживания или в зоне риска. Иначе бы всё сводилось бы к фразе из анекдота «а — чего думать? прыгать надо!»
С одной стороны очень хорошо, что человек имеет возможность попробовать себя в разных точках приложения себя, пока не найдёт своё дело. С другой необходима объективная оценка рисков для общества в целом растраты ценных ресурсов на упомянутые «периоды переквалификации» и на ту часть общества, которая делает не своё дело.
Если вам надоело обсуждение данной темы, предлагаю его прекратить, потому, что могут начать вылезать аргументы и логические цепочки доказательств своей правоты, уводящие нас в совершенные дебри форумной дискуссии… :)
Я в чём-то не прав?
Лучше же и для человека, и для его нанимателей, что бы человек занимался СВОИМ делом, а — не «ломать его через коленку»!
Человек может ошибаться или заблуждаться на счёт того, что — ЕГО.
Но надо, всё равно, дать ему шанс.
Одна моя одногруппница закончила два технических вуза. Десять лет проработала в инженерной специальности. Потом была просто каким-то офис-менеджером. А потом — просто плюнула на всё и пошла в третий раз в ВУЗ. Закончила инъяз в универе с педагогическими мотивами. И это — уже около сорока ей было. Оказывается она всю жизнь мечтала преподавать иностранные языки маленьким деткам. И теперь она рада и счастлива. И вспоминает с ужасом то время, когда пошла на поводу у родителей и их наставлений и ЗАСТАВЛЯЛА себя заниматься тем, что ей не нравилось и было НЕ ЕЁ.
Я сам не сказать, что поменял специальность, но — специализацию в ИТ.
Начинал на кафедре. Занимался моделированием сложных (социо-технических) систем, потом принимал участие в разрабатке биллинговых систем. А потом — тоже — махнул рукой и, в довольно зрелом возрасте, ушёл в эмбеддинг и разработку систем управления.
И обрёл нирвану…
… совместно с глубочайшим удовлетворением начальства и заказчиков.
Деньги определяют многое, но — не всё. Когда начинаешь понимать, что живёшь не своей жизнью, надо что-то менять. Критерий хорошей оплаты за тобой сделанное, без творческого удовлетворения от этого сделанного — довольно сомнителен. А если ещё и удаётся найти коллектив таких же коллег, занимающимся СВОИМ делом, то эффекты могут быть поразительными. Даже производительность труда и качество продукции на выходе становятся на порядки выше, чем у «тех, кто на галерах». Причём, часто никто в таких коллективах не заморачивается новыми процессами (кого куда усадить, какие роли навесить и какие артефакты в процессе согласования выпускать). Никто не агитирует за необходимость изучать что-то новое. Всё работает, как часики и идёт — как «по маслу». Я уже упоминал о своём опыте, когда мы, вдвоём с электронщиком, за два с половиной года, «выкатили» комплексную систему сбора, хранения и последующей наземной обработки и анализа полётных данных, лучшую и с большим потенциалом расширения функционала, чем наши конкуренты, в количестве 15-20 человек, смогли сварганить за почти 10 лет работы. Это — не похвальба и не фантазии. Это — показатель.
Связь между мной и ФП ограничивается только наличием набора книг Душкина и прочих корифеев ФП на одной из моих книжных полок, но прочитанных максимум до благодарностей в разделах введений в этих книжек. :)
А вот с ООП я работаю с 1988 года.
… и, как мне кажется, вы совершенно неверно воспринимаете или интерпретируете понятие «глобальное состояние». В последнем абзаце вы «агрегировали» состояния отдельных объектов, реализующих функциональности БД, кешев, пулов коннектов и «прочего» в некое «глобальное состояние».
Поймите, что, упоминаемые вами, «кеши» и «пулы» — лишь инструменты/структуры для реализации объектов более высокого уровня.
Обычно на уровне предметной области (от встроенных систем и — до, например, управления каскадом ГЭС или программ моделирования экономических систем размером с государство), понятий «кеш» или «пул» — НЕТ. Если же они там появляются, значит авторы модели предметной области смешали семантические уровни в своих моделях.
Даже если у меня есть «пулы» на уровне, например, какой-то ОСРВ или библиотеки, то напрямую нагружать их понятийностью или реализацией функционала из предметной области — будет ОГРОМНОЙ ошибкой.
Списки, кеши, пулы могут реализовывать и поддерживать внутренние и состояния выделенных объектов предметных областей, но сами они НЕ МОГУТ являться носителями сущностей этих областей.
Это примерно также, как с широко распространённой ошибкой получения «активных объектов» через наследование от класса Поток во многих библиотеках классов (от Delphi и — до Явы). Авторы этих библиотек сделали колоссальную методологическую ошибку, позволив неокрепшим молодым умам программистов реализовывать активность объектов в своих системах через реализацию некоего унаследованного от класса Thread виртуального метода Execute или Run. В результате массовое программистское мышление не только было отодвинуто от верного шаблона реализации активных объектов, но и убеждено в том, что именно так и надо делать…
Из вашего последнего абзаца () я понял, что вы про активные объекты не слышали. Причём, я прошу заметить, что при проектировании на уровне системы активных объектов у разработчиков, при разговоре на уровне их предметной области, появление слов «поток» и «мьютекс» — показатель лютой непрофпригодности. :)
Что за объект предметной в вашей области у вас ответственен за реализацию понятия «место хранения данных из приходящих сообщений»?
До сих именно эта «странность» мне помогала сделать за два-три года больше, чем дюжина разрабов за восемь лет не могла добиться. Причём, как я уже упоминал, в областях, куда любой веб-разраб даже подумать приблизиться побоится.