Это если вы считаете, что «изучение» обязано происходить во время работы программы. Я не считаю.
Вообще, про моделирование это на редкость сложная и глубокая тема. Предлагаю для ясности остаться каждый при своей позиции.
Вообще-то в клиент-серверной архитектуре и данные, и поведение могут быть на сервере. См. «тонкий клиент».
Случаи разные бывают. 3-х уровневый К/С тоже никто не отменял.
А SOA ли это?
Обязательно. Почему нет? На микросервисную архитектуру оно, конечно, мало похоже, но SOA в чистом виде.
сервис инкапсулирует свои данные и поведение
Опять же случаи разные бывают. Сервис может, например, просто шлюзовать инфопоток, вообще не вникая, что за беда через него струится.
это ООП «на большом уровне», где объектом является каждый сервис
Вот в этом-то и дело, что на таком большом уровне мы приходим к тому, с чего начали рассуждение, а именно что объект — это просто некий кусок системы, который объектом-то назван только потому, что нам нужно им оперировать как единой целой сущностью.
что-то странное скажу, но можно иметь ООП вообще без наследования
В обморок не упал. Оно, конечно, против классики, но когда дело доходит до дела, то это бывает вполне рабочий вариант.
Но она там есть. Просто в силу определения, приведенного выше.
Внимательно читаем определение: «Под моделью понимается некоторый материальный или мысленно представляемый объект (образ объекта), который в процессе изучения замещает объект-оригинал, сохраняя некоторые важные для данного исследования типичные его черты».
Долго и упорно гипнотизируем слово «изучение». В нём — ключ к пониманию происходящего. Если в программе нужно иметь некий механизм, который другой части программы будет давать прогноз относительно того, как будут складываться обстоятельства, то этот механизм безусловно будет моделью. Насколько часто бывает востребована такая конструкция? Ну, это смотря в какой предметной области работаем. Если программа составляет метеопрогноз, то можно предположить, что тема моделирование атмосферных процессов в ней будет раскрыта основательно. Но если программа является адресной книжкой, то ценность моделирования в ней весьма сомнительна.
Например клиент-серверные архитектуры — про это.
… которые инкапсулируют в себе данные и поведение.
Очень странно инкапсулируют. Данные инкапсулируют на сервер, а поведение — на клиент :))
SOA — тоже про это.
… которая инкапсулирует в себе данные и поведение.
Для примера посмотрим на сервис электронного архива. Data warehouse для, грубо говоря, бинарников заранее не определённого назначения. Нормальный такой объект, да? При этом, что забавно, этот самый сервис совсем не обязательно должен быть написан с применением ООП. В конце концов, его можно написать на чистом C без единого плюса.
Не знаю кому как, но лично мне бывает не удобно работать с ОО-реализацией SOA (SOAP). Слишком много лишней дури наворочено. Перекидываться по-простянке XMLями или JSONами через банальный HTTPRequest и удобнее, и практичнее.
А напомните мне, какая парадигма разработки не требует доработок по мере уточнения задачи?
Все требуют. Такова жизнь. Вопрос здесь в уровне отчаяния, с которым встречается каждое уточнение задачи. По своему опыту скажу, что проще всего получается выкручиваться, когда ООП применено в очень куцем варианте. Например, когда количество уровней иерархии ограничено двумя (есть набор базовых классов, на основе которых лепим потомков, но налепить потомка потомка — ни-ни). Дурацкое ограничение, которое поначалу дико бесит, но потом, когда случается уточнение постановки, начинаешь понимать, как сказочно повезло.
Да понятно, что прокатывает. Вопрос сложности.
5 минут на написание запроса — не ахти какая сложность ;)
Почему работающий механизм не может содержать в себе модель?
Потому что она там не нужна.
Примерно потому же, почему в конструкции автомобиля нигде не содержится моделька дороги с игрушечными мостиками и светофорчиками.
Мы все находимся в плену, как я её называю, «отражательной» парадигмы понимания понимания (пардон за тавтологию). Типа реальный мир находит своё отражение в представлениях познающего субъекта. Что должно представлять собой это отражение? Правильно, модель. Чрезвычайно убогая парадигма. Начать хотя бы с того, что у нас в мозгах нет ни одного зеркала, чтобы отражать, и закончить хотя бы тем, что моделирование подразумевает не только моделируемое явление, но и того гаврика, который этим моделированием «в процессе изучения замещает объект-оригинал». Короче, прямиком выходим на теорию внутримозгового гомункла. Полная ерунда. Бессмысленная и беспощадная логическая петля. Если мне не изменяет память, эта тухлятина была обильно полита грязью ещё аж в знаменитом сентябрьском 79-го года номере SciAm.
В общем, пусть моделирование останется там, где ему самое место. Как метод исследования. А мы, технари, будем к нему прибегать только тогда, когда нам нужно именно моделирование. Например, для проведения нагрузочных испытаний будем делать роботов, которые действительно будут моделировать пользовательскую активность. Кстати, моделирование бизнес-процессов — тоже зачётная тема. Очень помогает.
Предложите лучше.
Декомпозиция программных продуктов — весьма популярная и живая тема. Например клиент-серверные архитектуры — про это. SOA — тоже про это. На ОО свет белый клином не сошёлся. ОО тоже бывает полезно, но только если без фанатизма.
Ну так и пример масштабируется вместе с усложнением жизни.
Плохо масштабируется. Необходимость постоянной перетряски иерархий объектов по мере уточнения задачи — родовая травма ОО.
SQLю это как два пальца.
… но нет, на самом деле. Где-то начиная с «на заданную дату».
Да ладно… Я сам сто раз так делал. Нормально прокатывает.
Для этого у нас есть функции. Здесь же мы берёмся снижать воспринимаемую сложность пары «код + данные, с которыми он работает». Выбранный способ (строительство заборчика вокруг данных), ИМХО, не самый лучший. Единственное, на мой взгляд, преимущество этого способа в том, что он является первым, что приходит в голову.
… и провести границу...
Ага. Построить заборчик. Потом другой. Возвести заборостроение в базовый принцип, и после этого удивляться, что ландшафт жёстко фрагментировался и превратился в нагромождение какой-то немыслимой хреновни.
Заборы строить безусловно нужно. Иметь системы, построенные по принципу «гуляй, ветер», не хочется никому. Мотивов тому может быть масса, начиная от банального разграничения сфер ответственности команд разработчиков и до локализации катастроф. Но, как всегда бывает в таких случаях, к вопросам нужно подходить с умом, а не тупо следовать моде.
Возьмем в качестве примера простой заказ: позиция, количество, общая сумма. Общая сумма — это вычислимое поле, оно считается как «цена позиции * количество». Это правило — это как раз поведение.
Хороший пример, но, к сожалению жизнь бывает слегка сложнее. Начать хотя бы с того, что цена и количество — это не «просто циферки». Цена в валюте, а количество в единицах измерения. Помимо двух циферок есть ещё договор клиента, в котором указана валюта взаиморасчётов, есть прайс, в котором указана рекомендуемая цена товара, но, как на зло, не по той единице, которая в заказе, а по другой, и между ними таблица пересчёта (это литры в кубометры легко пересчитываются, а кубометры в тонны уже не очень). Да, и ещё цена в прайсе не в той валюте, которая в договоре. Сумму-то мы посчитаем простым умножением, но это всего 1% нашей задачи, если не меньше. А всё остальное пускает свои щупальца по всей системе. И ладно бы если бы это можно было решить APIшками классов, так ведь ещё возникает всякое гадство типа «быстро одной кнопкой получить список имеющихся в наличии товарных позиций с ценами, пересчитанными в выдранную валюту по курсу на указанную дату». SQLю это как два пальца. Юзер моргнуть не успеет. А как оно и, главное, сколько времени будет продираться через интерфейсы объектной модели?
Когда я пишу в коде record OrderLine {ItemId: string, Quantity: decimal, Total: decimal} — я тоже создаю модель предметной области, только выраженную кодом
Вы не модель создаёте, а работающий механизм. В корне неправильно называть моделированием факт пригодности этого механизма к использованию в той предметной области, для которой он предназначен. Не, ну вдумайтесь. Разве автомобиль содержит в себе модель пассажира, груза и дороги? Разве в автомобиле есть какая-то деталька, которая там служит моделью дороги? Только, умоляю, не говорите «колесо». Колесо — круглое, а дорога плоская.
Ни из чего. Нет у него встроенной опции «состоять из...». Любое деление на объекты — результат счастливого сочетания следующих двух вещей:
1. (естественно) Пригодности обозреваемого куска (или аспекта) реальности к тому, чтобы на нём мы смогли выделить отдельные объекты. Если говорить о материальном мире, то предметы в твёрдом агрегатном состоянии в этом плане удобны, а с жидкостями и газами приходится изворачиваться с разной степенью успешности. С нематериальными объектами тоже бывает по-разному.
2. Способностей субъекта и особенностей той ситуации, в которой он в данный конкретный момент находится. Мой любимый пример — стакан воды. Когда мы говорим «принеси стакан воды», мы имеем в виду ёмкость+жидкость, а когда говорим «выпей стакан воды», мы имеем в виду только жидкость.
Применительно к ООП ситуация выглядит драматично. Допустим, сегодня мы твёрдо уверены, что стаканы воды — это всегда с ёмкостью, и колбасим логику исходя именно из такого способа выделения объекта из реальности. А завтра оказывается, что нам нужно запрограммировать логику ситуации «в желудке 2 стакана воды». А у нас стеклянный стакан ну никак не пролазит через пищевод :))
Никакое разделение мира на объекты не является окончательным и единственно правильным. А мы мало того, что на это закладываемся, так ещё и придумываем себе на свою голову отягчающие обстоятельства в виде иерархий классов.
Ни браузер, ни веб-сервер не делают ничего. Всю работу делает компьютер.
В некотором смысле это правда, но правда совершенно никчёмная. Что с ней делать? Что она нам даёт? Мы в своих делах никогда не имеем дело с той аппаратурой, которая непосредственно выполняет наш код. Вы имеете физический доступ к тем узлам процессора, на которых исполняется Ваш код? Я — точно нет. Я всегда имею дело с буковками на экране.
Где проверяется пользовательский ввод? Да вот здесь, в функции CheckUserInput. Где ошибка, завалившая сервак? Да вот здесь, в запросе, в соединении таблиц забыли вписать доп. условие и получили, по сути, cross join. Не знаю как кто, но обычно я даже примерно себе не представляю, где физически находятся те компьютеры, которые «делают всю работу». Где-то на планете Земля. Это точно. Для космических аппаратов я ещё ничего не программил.
поскольку нам удобно использовать абстракцию объекта при описании окружающей действительности, будет удобно, если мы сможем использовать ту же абстракцию в программировании
Абсолютно верно!
С этой точки зрения мы, конечно, обречены работать с объектами. Таков наш способ взаимодействия с реальностью: мы выделяем из неё объекты, и уже потом с ними взаимодействуем. Не важно, что мы делаем — ботинок чиним, стенку шпаклюем или ваяем веб-морду. И в этом плане нет ничего странного в том, чтобы наши программы состояли из объектов.
Но возникает целый ряд «но». Хорошо, объекты. Но почему они должны в себе инкапсулировать данные и поведение? Возьмём, например, адресную книгу (объект), содержащую в себе из записи (тоже объекты). Запись адресной книги — это просто структурированный кусок бинарных данных. Какое собственное поведение должно быть у куска бинарных данных? Программист морщит лоб и начинает ваять конструктор и геттеры-сеттеры. Хоть такое, высосанное из пальца, но всё же поведение. Ну не глупость?
В базах данных, на мой взгляд, более здравый подход: адресная книга — это таблица, а что и как с ней делать (то есть вся прикладная логика) вынесено на усмотрение тех, кто её юзает. Надо по имени найми мэйл — пожалуйста. Надо по мэйлу узнать имя — тоже нет проблем. SQL в руки. Встроить какую-то логику в триггеры, конечно, бывает полезно, но о том, чтобы всё, что может происходить с адресной книгой, объявить её поведением и попытаться инкапсулировать в этот объект — это никому даже в страшном сне в голову не придёт.
Каждая программа содержит ту или иную модель бизнес-области.
Нет. Она строится с учётом разнообразных моделей предметной области, но чтобы они в программу закладывались — про такое я не слышал. Да и в каком виде их туда лучше закладывать? В Визио или лучше в PNG? :))
А если серьёзно, то в молоток не закладывается модель забивания гвоздей, в автомобиль не закладывается модель пассажира. Почему в программу должна закладываться какая-то там модель? То есть сущности, свойства которых в достаточной мере соответствует свойствам элементов моделируемой системы?
Между тем, чтобы «являться моделью» и «быть сконструированным с учётом результатов моделирования» — большая логическая разница. Нужно просто перестать путаться.
Мне кажется, лучше говорить не о моделях, а об инструментах и метафорах. Адресная книга у нас будет не моделью блокнотика, а инструментом накопления фактов о корреспондентах. А текстовый редактор пусть не будет моделью листа бумаги, но метафора «лист бумаги» пусть будет идейной основой визуального представления.
«Предметно-ориентированное программирование» — тоже как-то не очень. Сразу возникает вопрос типа «а что, бывает беспредметное программирование?»
По мотивам этого всего придумался недомемчик «Objection Oriented» :))
Мне кажется, косяк в самой основе ООП. В глубинном принципе, который можно сформулировать примерно так: «Если реальный мир состоит из объектов, то если и наши программы будут состоять из объектов, то моделировать ими реальный мир будет надёжнее, естественнее и результативнее».
В таком (и всех подобных ему) рассуждении есть сразу два косяка:
1. Реальный мир ни из каких объектов не состоит. Он, гад такой, вообще хрен знает из чего сам по себе состоит. Мировая теоретико-физическая мысль корчится в конвульсиях, пытаясь представить себе реальность в виде струн, стремящихся минимизировать покрываемую ими по десятимерному пространству-времени площадь, но всё глубже и глубже запутывается в измышлятине и поправочных коэффициентах. О каком стопудово объективном существовании таких вещей, как камни, деревья, люди и т.п. можно говорить в таких непотребных обстоятельствах? Любое разбиение реального мира на объекты (любое!!!) — результат волюнтаризма субъекта и особенностей тех обстоятельств, в которые в данный конкретный момент его, субъекта, занесло. Чуть изменились обстоятельства, и всё, капец. У нас уже на том же материале уже другие объекты. Будем в тысяче первый раз перетряхивать объектную модель нашей ООПшной проги. Или лепить очередную систему костылей, которая нам позволит классом «Собака» описывать не только собак и кошек (это было костылём в прошлый раз), но и аквариумных рыбок.
2. «Моделирование» — зачётная тема, но её ценность слегка (на самом деле не слегка, а очень сильно) преувеличена. Можно всю жизнь протрудиться программером и накодить гигабайты кода, но ни разу не написать ничего, что можно было бы назвать моделью чего-то. Веб-сервер не моделирует выдачу веб-страниц клиентам, а выдаёт их. Браузер не моделирует прорисовку страниц, а прорисовывает их. Даже позорный сумматор не моделирует суммирование, а делает его. И кошка не моделирует охоту на мышку. Автомобиль не моделирует перевозку пассажиров и грузов. И мы сами пишем тут комменты, а не моделируем это самое написание. Моделирование — узкая нишевая задача, почти совсем не встречающаяся в реальной промышленной практике. Ну и какого хрена мы должны решающим преимуществом инструмента считать его способность решать те задачи, решение которых нам заведомо не нужно? (В скобках замечу, что даже для моделирования ООП подходит не для всякого, а только для имитации взаимодействия небольших количеств дискретных сущностей)
Как-то так получается, что реально вкусными и повсеместно полезными у нас оказываются чисто служебные классы. Такие, как String, Array, HashTable и т.п. А все многочисленные ООА и ООД оказываются весьма опасным с точки зрения проектных рисков ментальным мусором.
Про кошачий запах — сомнительно. Моя, например, очень благосклонно относится к местным кошатникам. Даже к хозяйке злейшей вражины идёт ластиться. Когда она, конечно, без вражины.
В дополнение к гипотезе о запахе. Может быть, у Вас есть какая-то особенность поведения? Например, нетипичная походка.
Собаки — жуткие консерваторы. Любое отклонение от того, что они приняли за нормальное положение вещей, воспринимают как предвестник зомби-апокалипсиса, от которого срочно нужно всех спасти. Собственно, эту особенность их психики люди давно и с удовольствием эксплуатируют.
Разве это опровержение? Это больше похоже на развитие темы ;)
Как-то так повелось, что при играх с собаками мы много и охотно контактируем с ними своими боковыми головами, и практически никогда средней. Ну и, естественно, собака сразу усваивает, что две маленькие головы любят играть в прекрасную игру «собаки-кусаки», а средняя не любит. Ну не любит, ну и ладно. Не больно-то и хотелось.
Читаешь документацию… смотришь список всех функций… сверяешься с книгой… забиваешь проблему в поисковик… заходишь на github.com...
Лишь окончательно убедившись, что нигде нет готового кода, которым можно было бы воспользоваться, стоит приступать к программированию самому.
Приступаешь к программированию и с ужасом обнаруживаешь, что сам не можешь написать ни строчки. Как же так? Я же это… всё знаю, всё понимаю, всё выучил, во всём разобрался, научился находить ответы на самые каверзные вопросы. Почему не могу написать даже элементарной ерунды? Даже, прости господи, сортировку пузырьком?
Для того, чтобы уметь ходить, нужно ходить. Знать на латыне названия всех костей, мышц и сухожилий — это хорошо, но опционально. Быть в курсе самых модных «best practices» в этом деле — тоже может быть полезно и познавательно, но тоже опционально. Магистерская степень по теоретической механике — безусловно круто, но ни в коем случае не заменит глупого, неуклюжего и неэффективного самостоятельного хождения своими собственными ногами по грешной земле.
Так уж мы устроены, что понимание и делание у нас реализовано, грубо говоря, разными нейроцепями. Они рядом, они дружат, они друг другу помогают. Но тем не менее, они разные. Натренировав только одну, мы не получаем автоматом другую тоже натренированной. Она, горемычная, так и остаётся дура дурой.
В сухом остатке: читать доки / книжки / статьи / github — безусловно нужно и полезно, не точно никак не «вместо». Вместе — пожалуйста, но вместо — не надо.
Ну и что, что изобретёшь очередной велосипед? Разве это повод для переживаний? Велосипедостроение, в конце концов, существует до тех пор, пока люди не перестают изобретать велосипеды.
У меня есть теория (глупая, конечно, но всё же...), что собаки воспринимают наши руки как дополнительные головы. Они ж ведь сами, если надо что-то, например, взять и понести, используют для этого свою пасть. И мы с их точки зрения тоже используем нечто аналогичное.
Рассматривать наши руки как конечности — это с их точки зрения глупо. Конечности — чтобы ходить, а кушать и что-то делать нужно головами.
Соответственно, наш указующий жест — это «зачем-то пристально посмотрел своей дополнительной головой вон туда». Точно есть смысл обратить внимание.
«Маленькая и лёгкая» — совсем не обязательно граммы. Это могут быть тонны. Или десятки тонн. Но в любом случае не миллионы, потребные для того, чтобы приволочь в телесном виде колонистов и их хозяйство.
Ну да, нужен совсем другой уровень технологий, чем тот, который есть сейчас. Но он точно не из разряда «так не бывает». В конце концов, по похожей методе растения, которые сами никак перемещаться не могут, устроили экспансию на острова в океане.
Если не принимать во внимание туманные перспективы продырявливания пространства или какого другого преодоления скорости света, то мне видятся следующие две возможности:
1. Рассылка семян. То есть строятся не огромные ковчеги, в которые грузятся каждой твари по паре в живом или замороженном виде, а маленькая и относительно лёгкая «семечка», которая по прибытии на место выращивает из себя разную машинерию и, в частности, приёмник, на который будет принимать от нас колонистов в цифровом виде. Нет смысла таскать сквозь межзвёздную пустоту атомы вещества. Вещества, как и энергии, во Вселенной везде пруд пруди. Грубо говоря, через пустоту нужно таскать информацию.
2. Прямо противоположная стратегия. Строятся огромные жилые «острова» размером с большой астероид, и отправляются не особо спеша дрейфовать по галактике. Без особой цели пристать к какой-нибудь звезде. То есть, конечно, по ходу дела приставать к звезде полезно, чтобы, например, пополнить запасы вещества и, возможно, отпочковать «детку», но потом всё равно полететь дальше. Человечество становится таким кочевым племенем космических цыган.
Обратите пожалуйста внимание на то, что представленные затраты — это только затраты на 2-х сотрудников Центрального аппарата и 148 сотрудников территориальных органов Роскомнадзора. Плюс материальное оснащение их рабочих мест.
То есть здесь в расчёте речь идёт только о затратах на проверяльщиков. Только на контроль уйдёт порядка 110 млн. руб. Сколько это в процентах от того «итого», который мы, граждане, должны будем выложить за то, чтобы за нами могли следить? Процент? Десятая доля процента? Сотая?
это псевдонаучные теорий/философия, не имеющая никакой практической пользы
иначе это философия или псевдонаука
Вот тут Вы попали в самую точку. В десяточку. Поздравляю. Эти мои рассуждения — действительно не наука. Их при всём желании нельзя приписать ни к физике, ни к химии, ни к биологии, ни к социологии, ни даже к географии. Подобную чепуху можно было бы отнести к псевдонауке, но только в том случае, если бы я декларировал, что вот это говоримое есть наука. Но я это нигде здесь не утверждал. Сами проверьте и убедитесь. Контекстный поиск в помощь. Это всякие астрологи, хироманты, соционики и прочие подобные им добрые люди с пеной у рта утверждают, что их ремёсла являются науками. А я про то, что говорил, ничего подобного не утверждал. Не наука, и давайте с лёгким сердцем проедем эту тему.
Это философия. Весьма странная человеческая деятельность, которая иногда чем-то бывает похожа науку, но, конечно же, не наука. Вот историю философии с некоторой натяжкой можно назвать наукой. Но саму философию — нет. Но я бы поостерёгся говорить, что раз она не наука, то от неё нет никакой практической пользы. Особенно в этой теме. Просто потому, что сам критерий Поппера — не научная штука, а именно философская. Метанаучная. Эпистемология — слышали про такое? Именно поэтому, кстати, сам этот критерий самому себе не подчиняется. Как я писал где-то в соседней ветке обсуждения, поваренная книга сама не обязана быть вкусной или даже хотя бы съедобной.
Это я не к тому, что критерий Поппера в философии нигде не применяется. Конечно применяется. Это хороший инструмент, и если его применение в тему, то почему бы его и не применить? Но нет и не может быть жёсткого требования, чтобы всё сказанное было фальсифицируемым.
Случаи разные бывают. 3-х уровневый К/С тоже никто не отменял.
Обязательно. Почему нет? На микросервисную архитектуру оно, конечно, мало похоже, но SOA в чистом виде.
Опять же случаи разные бывают. Сервис может, например, просто шлюзовать инфопоток, вообще не вникая, что за беда через него струится.
Вот в этом-то и дело, что на таком большом уровне мы приходим к тому, с чего начали рассуждение, а именно что объект — это просто некий кусок системы, который объектом-то назван только потому, что нам нужно им оперировать как единой целой сущностью.
В обморок не упал. Оно, конечно, против классики, но когда дело доходит до дела, то это бывает вполне рабочий вариант.
«Под моделью понимается некоторый материальный или мысленно представляемый объект (образ объекта), который в процессе изучения замещает объект-оригинал, сохраняя некоторые важные для данного исследования типичные его черты».
Долго и упорно гипнотизируем слово «изучение». В нём — ключ к пониманию происходящего. Если в программе нужно иметь некий механизм, который другой части программы будет давать прогноз относительно того, как будут складываться обстоятельства, то этот механизм безусловно будет моделью. Насколько часто бывает востребована такая конструкция? Ну, это смотря в какой предметной области работаем. Если программа составляет метеопрогноз, то можно предположить, что тема моделирование атмосферных процессов в ней будет раскрыта основательно. Но если программа является адресной книжкой, то ценность моделирования в ней весьма сомнительна.
Очень странно инкапсулируют. Данные инкапсулируют на сервер, а поведение — на клиент :))
Для примера посмотрим на сервис электронного архива. Data warehouse для, грубо говоря, бинарников заранее не определённого назначения. Нормальный такой объект, да? При этом, что забавно, этот самый сервис совсем не обязательно должен быть написан с применением ООП. В конце концов, его можно написать на чистом C без единого плюса.
Не знаю кому как, но лично мне бывает не удобно работать с ОО-реализацией SOA (SOAP). Слишком много лишней дури наворочено. Перекидываться по-простянке XMLями или JSONами через банальный HTTPRequest и удобнее, и практичнее.
Все требуют. Такова жизнь. Вопрос здесь в уровне отчаяния, с которым встречается каждое уточнение задачи. По своему опыту скажу, что проще всего получается выкручиваться, когда ООП применено в очень куцем варианте. Например, когда количество уровней иерархии ограничено двумя (есть набор базовых классов, на основе которых лепим потомков, но налепить потомка потомка — ни-ни). Дурацкое ограничение, которое поначалу дико бесит, но потом, когда случается уточнение постановки, начинаешь понимать, как сказочно повезло.
5 минут на написание запроса — не ахти какая сложность ;)
Примерно потому же, почему в конструкции автомобиля нигде не содержится моделька дороги с игрушечными мостиками и светофорчиками.
Мы все находимся в плену, как я её называю, «отражательной» парадигмы понимания понимания (пардон за тавтологию). Типа реальный мир находит своё отражение в представлениях познающего субъекта. Что должно представлять собой это отражение? Правильно, модель. Чрезвычайно убогая парадигма. Начать хотя бы с того, что у нас в мозгах нет ни одного зеркала, чтобы отражать, и закончить хотя бы тем, что моделирование подразумевает не только моделируемое явление, но и того гаврика, который этим моделированием «в процессе изучения замещает объект-оригинал». Короче, прямиком выходим на теорию внутримозгового гомункла. Полная ерунда. Бессмысленная и беспощадная логическая петля. Если мне не изменяет память, эта тухлятина была обильно полита грязью ещё аж в знаменитом сентябрьском 79-го года номере SciAm.
В общем, пусть моделирование останется там, где ему самое место. Как метод исследования. А мы, технари, будем к нему прибегать только тогда, когда нам нужно именно моделирование. Например, для проведения нагрузочных испытаний будем делать роботов, которые действительно будут моделировать пользовательскую активность. Кстати, моделирование бизнес-процессов — тоже зачётная тема. Очень помогает.
Декомпозиция программных продуктов — весьма популярная и живая тема. Например клиент-серверные архитектуры — про это. SOA — тоже про это. На ОО свет белый клином не сошёлся. ОО тоже бывает полезно, но только если без фанатизма.
Плохо масштабируется. Необходимость постоянной перетряски иерархий объектов по мере уточнения задачи — родовая травма ОО.
Да ладно… Я сам сто раз так делал. Нормально прокатывает.
Ага. Построить заборчик. Потом другой. Возвести заборостроение в базовый принцип, и после этого удивляться, что ландшафт жёстко фрагментировался и превратился в нагромождение какой-то немыслимой хреновни.
Заборы строить безусловно нужно. Иметь системы, построенные по принципу «гуляй, ветер», не хочется никому. Мотивов тому может быть масса, начиная от банального разграничения сфер ответственности команд разработчиков и до локализации катастроф. Но, как всегда бывает в таких случаях, к вопросам нужно подходить с умом, а не тупо следовать моде.
Хороший пример, но, к сожалению жизнь бывает слегка сложнее. Начать хотя бы с того, что цена и количество — это не «просто циферки». Цена в валюте, а количество в единицах измерения. Помимо двух циферок есть ещё договор клиента, в котором указана валюта взаиморасчётов, есть прайс, в котором указана рекомендуемая цена товара, но, как на зло, не по той единице, которая в заказе, а по другой, и между ними таблица пересчёта (это литры в кубометры легко пересчитываются, а кубометры в тонны уже не очень). Да, и ещё цена в прайсе не в той валюте, которая в договоре. Сумму-то мы посчитаем простым умножением, но это всего 1% нашей задачи, если не меньше. А всё остальное пускает свои щупальца по всей системе. И ладно бы если бы это можно было решить APIшками классов, так ведь ещё возникает всякое гадство типа «быстро одной кнопкой получить список имеющихся в наличии товарных позиций с ценами, пересчитанными в выдранную валюту по курсу на указанную дату». SQLю это как два пальца. Юзер моргнуть не успеет. А как оно и, главное, сколько времени будет продираться через интерфейсы объектной модели?
Вы не модель создаёте, а работающий механизм. В корне неправильно называть моделированием факт пригодности этого механизма к использованию в той предметной области, для которой он предназначен. Не, ну вдумайтесь. Разве автомобиль содержит в себе модель пассажира, груза и дороги? Разве в автомобиле есть какая-то деталька, которая там служит моделью дороги? Только, умоляю, не говорите «колесо». Колесо — круглое, а дорога плоская.
1. (естественно) Пригодности обозреваемого куска (или аспекта) реальности к тому, чтобы на нём мы смогли выделить отдельные объекты. Если говорить о материальном мире, то предметы в твёрдом агрегатном состоянии в этом плане удобны, а с жидкостями и газами приходится изворачиваться с разной степенью успешности. С нематериальными объектами тоже бывает по-разному.
2. Способностей субъекта и особенностей той ситуации, в которой он в данный конкретный момент находится. Мой любимый пример — стакан воды. Когда мы говорим «принеси стакан воды», мы имеем в виду ёмкость+жидкость, а когда говорим «выпей стакан воды», мы имеем в виду только жидкость.
Применительно к ООП ситуация выглядит драматично. Допустим, сегодня мы твёрдо уверены, что стаканы воды — это всегда с ёмкостью, и колбасим логику исходя именно из такого способа выделения объекта из реальности. А завтра оказывается, что нам нужно запрограммировать логику ситуации «в желудке 2 стакана воды». А у нас стеклянный стакан ну никак не пролазит через пищевод :))
Никакое разделение мира на объекты не является окончательным и единственно правильным. А мы мало того, что на это закладываемся, так ещё и придумываем себе на свою голову отягчающие обстоятельства в виде иерархий классов.
В некотором смысле это правда, но правда совершенно никчёмная. Что с ней делать? Что она нам даёт? Мы в своих делах никогда не имеем дело с той аппаратурой, которая непосредственно выполняет наш код. Вы имеете физический доступ к тем узлам процессора, на которых исполняется Ваш код? Я — точно нет. Я всегда имею дело с буковками на экране.
Где проверяется пользовательский ввод? Да вот здесь, в функции CheckUserInput. Где ошибка, завалившая сервак? Да вот здесь, в запросе, в соединении таблиц забыли вписать доп. условие и получили, по сути, cross join. Не знаю как кто, но обычно я даже примерно себе не представляю, где физически находятся те компьютеры, которые «делают всю работу». Где-то на планете Земля. Это точно. Для космических аппаратов я ещё ничего не программил.
С этой точки зрения мы, конечно, обречены работать с объектами. Таков наш способ взаимодействия с реальностью: мы выделяем из неё объекты, и уже потом с ними взаимодействуем. Не важно, что мы делаем — ботинок чиним, стенку шпаклюем или ваяем веб-морду. И в этом плане нет ничего странного в том, чтобы наши программы состояли из объектов.
Но возникает целый ряд «но». Хорошо, объекты. Но почему они должны в себе инкапсулировать данные и поведение? Возьмём, например, адресную книгу (объект), содержащую в себе из записи (тоже объекты). Запись адресной книги — это просто структурированный кусок бинарных данных. Какое собственное поведение должно быть у куска бинарных данных? Программист морщит лоб и начинает ваять конструктор и геттеры-сеттеры. Хоть такое, высосанное из пальца, но всё же поведение. Ну не глупость?
В базах данных, на мой взгляд, более здравый подход: адресная книга — это таблица, а что и как с ней делать (то есть вся прикладная логика) вынесено на усмотрение тех, кто её юзает. Надо по имени найми мэйл — пожалуйста. Надо по мэйлу узнать имя — тоже нет проблем. SQL в руки. Встроить какую-то логику в триггеры, конечно, бывает полезно, но о том, чтобы всё, что может происходить с адресной книгой, объявить её поведением и попытаться инкапсулировать в этот объект — это никому даже в страшном сне в голову не придёт.
Нет. Она строится с учётом разнообразных моделей предметной области, но чтобы они в программу закладывались — про такое я не слышал. Да и в каком виде их туда лучше закладывать? В Визио или лучше в PNG? :))
А если серьёзно, то в молоток не закладывается модель забивания гвоздей, в автомобиль не закладывается модель пассажира. Почему в программу должна закладываться какая-то там модель? То есть сущности, свойства которых в достаточной мере соответствует свойствам элементов моделируемой системы?
Между тем, чтобы «являться моделью» и «быть сконструированным с учётом результатов моделирования» — большая логическая разница. Нужно просто перестать путаться.
Мне кажется, лучше говорить не о моделях, а об инструментах и метафорах. Адресная книга у нас будет не моделью блокнотика, а инструментом накопления фактов о корреспондентах. А текстовый редактор пусть не будет моделью листа бумаги, но метафора «лист бумаги» пусть будет идейной основой визуального представления.
По мотивам этого всего придумался недомемчик «Objection Oriented» :))
В таком (и всех подобных ему) рассуждении есть сразу два косяка:
1. Реальный мир ни из каких объектов не состоит. Он, гад такой, вообще хрен знает из чего сам по себе состоит. Мировая теоретико-физическая мысль корчится в конвульсиях, пытаясь представить себе реальность в виде струн, стремящихся минимизировать покрываемую ими по десятимерному пространству-времени площадь, но всё глубже и глубже запутывается в измышлятине и поправочных коэффициентах. О каком стопудово объективном существовании таких вещей, как камни, деревья, люди и т.п. можно говорить в таких непотребных обстоятельствах? Любое разбиение реального мира на объекты (любое!!!) — результат волюнтаризма субъекта и особенностей тех обстоятельств, в которые в данный конкретный момент его, субъекта, занесло. Чуть изменились обстоятельства, и всё, капец. У нас уже на том же материале уже другие объекты. Будем в тысяче первый раз перетряхивать объектную модель нашей ООПшной проги. Или лепить очередную систему костылей, которая нам позволит классом «Собака» описывать не только собак и кошек (это было костылём в прошлый раз), но и аквариумных рыбок.
2. «Моделирование» — зачётная тема, но её ценность слегка (на самом деле не слегка, а очень сильно) преувеличена. Можно всю жизнь протрудиться программером и накодить гигабайты кода, но ни разу не написать ничего, что можно было бы назвать моделью чего-то. Веб-сервер не моделирует выдачу веб-страниц клиентам, а выдаёт их. Браузер не моделирует прорисовку страниц, а прорисовывает их. Даже позорный сумматор не моделирует суммирование, а делает его. И кошка не моделирует охоту на мышку. Автомобиль не моделирует перевозку пассажиров и грузов. И мы сами пишем тут комменты, а не моделируем это самое написание. Моделирование — узкая нишевая задача, почти совсем не встречающаяся в реальной промышленной практике. Ну и какого хрена мы должны решающим преимуществом инструмента считать его способность решать те задачи, решение которых нам заведомо не нужно? (В скобках замечу, что даже для моделирования ООП подходит не для всякого, а только для имитации взаимодействия небольших количеств дискретных сущностей)
Как-то так получается, что реально вкусными и повсеместно полезными у нас оказываются чисто служебные классы. Такие, как String, Array, HashTable и т.п. А все многочисленные ООА и ООД оказываются весьма опасным с точки зрения проектных рисков ментальным мусором.
Собаки — жуткие консерваторы. Любое отклонение от того, что они приняли за нормальное положение вещей, воспринимают как предвестник зомби-апокалипсиса, от которого срочно нужно всех спасти. Собственно, эту особенность их психики люди давно и с удовольствием эксплуатируют.
Как-то так повелось, что при играх с собаками мы много и охотно контактируем с ними своими боковыми головами, и практически никогда средней. Ну и, естественно, собака сразу усваивает, что две маленькие головы любят играть в прекрасную игру «собаки-кусаки», а средняя не любит. Ну не любит, ну и ладно. Не больно-то и хотелось.
Для того, чтобы уметь ходить, нужно ходить. Знать на латыне названия всех костей, мышц и сухожилий — это хорошо, но опционально. Быть в курсе самых модных «best practices» в этом деле — тоже может быть полезно и познавательно, но тоже опционально. Магистерская степень по теоретической механике — безусловно круто, но ни в коем случае не заменит глупого, неуклюжего и неэффективного самостоятельного хождения своими собственными ногами по грешной земле.
Так уж мы устроены, что понимание и делание у нас реализовано, грубо говоря, разными нейроцепями. Они рядом, они дружат, они друг другу помогают. Но тем не менее, они разные. Натренировав только одну, мы не получаем автоматом другую тоже натренированной. Она, горемычная, так и остаётся дура дурой.
В сухом остатке: читать доки / книжки / статьи / github — безусловно нужно и полезно, не точно никак не «вместо». Вместе — пожалуйста, но вместо — не надо.
Ну и что, что изобретёшь очередной велосипед? Разве это повод для переживаний? Велосипедостроение, в конце концов, существует до тех пор, пока люди не перестают изобретать велосипеды.
Рассматривать наши руки как конечности — это с их точки зрения глупо. Конечности — чтобы ходить, а кушать и что-то делать нужно головами.
Соответственно, наш указующий жест — это «зачем-то пристально посмотрел своей дополнительной головой вон туда». Точно есть смысл обратить внимание.
Ну да, нужен совсем другой уровень технологий, чем тот, который есть сейчас. Но он точно не из разряда «так не бывает». В конце концов, по похожей методе растения, которые сами никак перемещаться не могут, устроили экспансию на острова в океане.
1. Рассылка семян. То есть строятся не огромные ковчеги, в которые грузятся каждой твари по паре в живом или замороженном виде, а маленькая и относительно лёгкая «семечка», которая по прибытии на место выращивает из себя разную машинерию и, в частности, приёмник, на который будет принимать от нас колонистов в цифровом виде. Нет смысла таскать сквозь межзвёздную пустоту атомы вещества. Вещества, как и энергии, во Вселенной везде пруд пруди. Грубо говоря, через пустоту нужно таскать информацию.
2. Прямо противоположная стратегия. Строятся огромные жилые «острова» размером с большой астероид, и отправляются не особо спеша дрейфовать по галактике. Без особой цели пристать к какой-нибудь звезде. То есть, конечно, по ходу дела приставать к звезде полезно, чтобы, например, пополнить запасы вещества и, возможно, отпочковать «детку», но потом всё равно полететь дальше. Человечество становится таким кочевым племенем космических цыган.
То есть здесь в расчёте речь идёт только о затратах на проверяльщиков. Только на контроль уйдёт порядка 110 млн. руб. Сколько это в процентах от того «итого», который мы, граждане, должны будем выложить за то, чтобы за нами могли следить? Процент? Десятая доля процента? Сотая?
Это философия. Весьма странная человеческая деятельность, которая иногда чем-то бывает похожа науку, но, конечно же, не наука. Вот историю философии с некоторой натяжкой можно назвать наукой. Но саму философию — нет. Но я бы поостерёгся говорить, что раз она не наука, то от неё нет никакой практической пользы. Особенно в этой теме. Просто потому, что сам критерий Поппера — не научная штука, а именно философская. Метанаучная. Эпистемология — слышали про такое? Именно поэтому, кстати, сам этот критерий самому себе не подчиняется. Как я писал где-то в соседней ветке обсуждения, поваренная книга сама не обязана быть вкусной или даже хотя бы съедобной.
Это я не к тому, что критерий Поппера в философии нигде не применяется. Конечно применяется. Это хороший инструмент, и если его применение в тему, то почему бы его и не применить? Но нет и не может быть жёсткого требования, чтобы всё сказанное было фальсифицируемым.