Здравствуйте, jeeist, Вы писали:
J>Извиняюсь, опять не смог ничего найти, хотя наверно J>такая тема уже где-то была.
J>Заинтересовал вопрос: как лучше освоить ООП? J>Точнее — что следует освоить перед этим.
Делаешь следующее
1. Читаешь "Рефакторинг" Фаулера.
2. Читаешь "Рефакторинг с использованием шаблонов" Джошуа Кериевски
3. По ходу чтения делаешь рефакторинги в проекте, который разрабатывается год-полтора в условиях меняющихся требований (часто противоположных).
4. Пользуешься советом Voblin (http://www.rsdn.ru/forum/philosophy/3547140.1.aspx
"Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем."
R>"Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем."
Очень правильно. Только вот как искать работу С#-исту или Джависту, который
не использует ООП? Поймет ли его потенциальный работодатель?
Здравствуйте, jeeist, Вы писали:
R>>"Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем."
J>Очень правильно. Только вот как искать работу С#-исту или Джависту, который J>не использует ООП? Поймет ли его потенциальный работодатель?
Т.е. ты даже стандартные либы использовать не будешь?
А в целом есть поговорка "в чужой монастырь с своим уставом не ходят", а ООП является основным подходом хотябы в яве (но это не мешает местами использовать другие методы)
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, jeeist, Вы писали:
R>>>"Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем."
J>>Очень правильно. Только вот как искать работу С#-исту или Джависту, который J>>не использует ООП? Поймет ли его потенциальный работодатель?
К>Т.е. ты даже стандартные либы использовать не будешь? К>А в целом есть поговорка "в чужой монастырь с своим уставом не ходят", а ООП является основным подходом хотябы в яве (но это не мешает местами использовать другие методы)
Задал вопрос, а потом сам (вроде бы) нашел ответ. На самом деле даже файл PHP
наверно можно рассматривать как объект+паттерн Фасад(?).
Так что (возможно я ошибаюсь, но) по-моему на Яве всегда
получается какой-то паттерн.
Только между слоями системы можно передавать бизнес-объекты,
а можно — XML, например.
На самом деле, все что творится в мире разработки ПО, все эти новые (и не очень) методики, парадигмы, идиомы, шаблоны, методологии и Бог еще знает что, направлены на повышение продуктивности программиста, на упрощение решения его повседневных задач и на борьбу с главным врагом любой системы — на борьбу со сложностью.
Сложность
Звезда в преддверии коллапса; ребенок, который учится читать; клетки крови, атакующие вирус, — это только некоторые из потрясающе сложных объектов физического мира. Компьютерные программы тоже бывают сложными, однако их сложность совершенно другого рода. Брукс пишет: "Эйнштейн утверждал, что должны существовать простые объяснения природных процессов, так как Бог не действует из каприза или по произволу. У программиста нет такого утешения: сложность, с которой он должен справиться, лежит в самой природе системы" [1].
Мы знаем, что не все программные системы сложны. Существует множество программ, которые задумываются, разрабатываются, сопровождаются и используются одним и тем же человеком. Обычно это начинающий программист или профессионал, работающий изолированно. Мы не хотим сказать, что все такие системы плохо сделаны или, тем более, усомниться в квалификации их создателей. Но такие системы, как правило, имеют очень ограниченную область применения и короткое время жизни. Обычно их лучше заменить новыми, чем пытаться повторно использовать, переделывать или расширять. Разработка подобных программ скорее утомительна, чем сложна, так что изучение этого процесса нас не интересует.
Существенная черта промышленной программы — уровень сложности: один разработчик практически не в состоянии охватить все аспекты такой системы. Грубо говоря, сложность промышленных программ превышает возможности человеческого интеллекта. Увы, но сложность, о которой мы говорим, по-видимому, присуща всем большим программных системам. Говоря "присуща", мы имеем в виду, что эта сложность здесь неизбежна: с ней можно справиться, но избавиться от нее нельзя.
и далее
Как говорит Брукс, "сложность программного обеспечения — отнюдь не случайное его свойство" [3]. Сложность вызывается четырьмя основными причинами:
— сложностью реальной предметной области, из которой исходит заказ на разработку;
— трудностью управления процессом разработки;
— необходимостью обеспечить достаточную гибкость программы;
— неудовлетворительными способами описания поведения больших дискретных систем.
Структура сложных систем
Существует мнение (в частности, прекрасно описанное в работе Буча), что существует ряд характеристик, присущих каждой сложной системе.
1. "Сложные системы часто являются иерархическими и состоят из взаимозависимых подсистем, которые в свою очередь также могут быть разделены на подсистемы, и т.д., вплоть до самого низкого уровням."
2. Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен и в большой степени оставляется на усмотрение исследователя.
3. "Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это обстоятельство позволяет отделять "высокочастотные" взаимодействия внутри компонентов от "низкочастотной" динамики взаимодействия между компонентами"
4. "Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных"
5. "Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы".
Роль абстракции
Выше мы ссылались на эксперименты Миллера, в которых было установлено, что обычно человек может одновременно воспринять лишь 7±2 единицы информации. Это число, по-видимому, не зависит от содержания информации. Как замечает сам Миллер: "Размер нашей памяти накладывает жесткие ограничения на количество информации, которое мы можем воспринять, обработать и запомнить. Организуя поступление входной информации одновременно по нескольким различным каналам и в виде последовательности отдельных порций, мы можем прорвать... этот информационный затор" [35]. В современной терминологии это называют разбиением или выделением абстракций.
Смысл абстрагирования. Абстрагирование является одним из основных методов, используемых для решения сложных задач. Хоар считает, что "абстрагирование проявляется в нахождении сходств между определенными объектами, ситуациями или процессами реального мира, и в принятии решений на основе этих сходств, отвлекаясь на время от имеющихся различий" [42]. Шоу определила это понятие так: "Упрощенное описание или изложение системы, при котором одни свойства и детали выделяются, а другие опускаются. Хорошей является такая абстракция, которая подчеркивает детали, существенные для рассмотрения и использования, и опускает те, которые на данный момент несущественны" [43]. Берзинс, Грей и Науман рекомендовали, чтобы "идея квалифицировалась как абстракция только, если она может быть изложена, понята и проанализирована независимо от механизма, который будет в дальнейшем принят для ее реализации" [44]. Суммируя эти разные точки зрения, получим следующее определение абстракции:
Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.
Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от несущественных. Абельсон и Суссман назвали такое разделение смысла и реализации барьером абстракции [45], который основывается на принципе минимизации связей, когда интерфейс объекта содержит только существенные аспекты поведения и ничего больше [46]. Мы считаем полезным еще один дополнительный принцип, называемый принципом наименьшего удивления, согласно которому абстракция должна охватывать все поведение объекта, но не больше и не меньше, и не привносить сюрпризов или побочных эффектов, лежащих вне ее сферы применимости.
Роль декомпозиции
Как отмечает Дейкстра, "Способ управления сложными системами был известен еще в древности — divide et impera (разделяй и властвуй)" [16]. При проектировании сложной программной системы необходимо разделять ее на все меньшие и меньшие подсистемы, каждую из которых можно совершенствовать независимо. В этом случае мы не превысим пропускной способности человеческого мозга: для понимания любого уровня системы нам необходимо одновременно держать в уме информацию лишь о немногих ее частях (отнюдь не о всех). В самом деле, как заметил Парнас, декомпозиция вызвана сложностью программирования системы, поскольку именно эта сложность вынуждает делить пространство состояний системы .
Еще в 1979 году в своей книге “Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design” Эда Йордона (Ed Yourdon) и Ларри Константайна (Larry L. Constantine) одни из первых определили фундаментальные понятия модульности ПО, такие как связанность (cohesion) и связность (coupling), основываясь на понятиях, приведенных в книге Алексендера “Notes On The Synthesis Of Form”.
По мнению Александера основной задачей при декомпозиции системы является осуществление следующих двух условий:
— максимизация связей внутри компонентов (высокое сцепление (high cohesion)) и
— минимизация связей между компонентами (низкая связность(low coupling)).
Эти проблемы широко известна в программной индустрии и описана в любой книге по проектированию и построению программных систем, но, если верить Александеру, они присущи проектированию любых сложных систем.
ООП
Объектно-ориентированная технология основывается на так называемой объектной модели. Основными ее принципами являются: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе не нов, но в объектной модели они впервые применены в совокупности.
Термин объектно-ориентированный, по мнению Бхаскара, "затаскан до потери смысла, как "материнство", "яблочный пирог" и "структурное программирование"" [7]. Можно согласиться, что понятие объекта является центральным во всем, что относится к объектно-ориентированной методологии. В главе 1 мы определили объект как осязаемую сущность, которая четко проявляет свое поведение. Стефик и Бобров определяют объекты как "сущности, объединяющие процедуры и данные, так как они производят вычисления и сохраняют свое локальное состояние" [8]. Определение объекта как сущности в какой-то мере отвечает на вопрос, но все же главным в понятии объекта является объединение идей абстракции данных и алгоритмов. Джонс уточняет это понятие следующим образом: "В объектном подходе акцент переносится на конкретные характеристики физической или абстрактной системы, являющейся предметом программного моделирования... Объекты обладают целостностью, которая не должна — а, в действительности, не может — быть нарушена. Объект может только менять состояние, вести себя, управляться или становиться в определенное отношение к другим объектам. Иначе говоря, свойства, которые характеризуют объект и его поведение, остаются неизменными.
Стоит отметить, что наследование — не является ключевой характеристикой ООП (как писали некоторые на этом форуме).
Более того, все авторы (включая Буча и Мейера — наиболее авторитетных авторов в этой области) всячески остерегают разработчиков от чрезмерного использования наследования. Ведь наследование увеличивает связность (coupling), что негативно сказывается на понимании и последующем развитии системы. Этим инструментом (наследованием) нужно пользоваться весьма осторожно и всегда отдавать предпочтение агрегации, а применять наследования только для моделирования отношения является (IS A relationship).
Все это я веду к тому, что метод — это не самое главное. Все они имеют что-то общее и в чем-то отличаются.
Многие программисты на С уже много лет используют те принципы, которые лежат в основе ООП. Они используют абстракцию, инкапсуляцию и модульность. Несмотря на отсутствие поддержки ООП, С программисты давно совмещают данные и операции в отдельные модули и стараются максимизировать повторное использование и минимизировать связность.
Вообще, книга Буча не поможет стать настоящим мастером ООП (впрочем, как и любая другая книга), но это лучшая книга, которая в состоянии направить взгляд человека на проблему, а не на способ ее решения. Если топикпастер хочет понять, что же такое ООП в полной мере, то стоит обратиться к наиболее формализованному труду по этой теме: книге Бертрана Мейера "Объектно-ориентированное конструирование программных систем".
З.Ы. Нет "серебряной пули" и на горизонте ее тоже не видно. ООП — не панацея, это всего лишь один из множества способов решения задач разработчика. Многие идеи, присущие ООП, присущи и многим другим методам программирования, они не являются новыми, просто разное сочетание таких идей дает разный результат. Не нужно ни на чем зацикливаться, не нужно быть фанатом инструмента, технологии или методологии, это ограничивает сознание и дает однобокий взгляд на проблему.
[cut]
ST>З.Ы. Нет "серебряной пули" и на горизонте ее тоже не видно. ООП — не панацея, это всего лишь один из множества способов решения задач разработчика. Многие идеи, присущие ООП, присущи и многим другим методам программирования, они не являются новыми, просто разное сочетание таких идей дает разный результат. Не нужно ни на чем зацикливаться, не нужно быть фанатом инструмента, технологии или методологии, это ограничивает сознание и дает однобокий взгляд на проблему.
Думаю, в рамках выше сказанного будет интересна вот эта статья.
К сожалению, не понял формат Вашего сообщения — является ли весь выделенный Вами текст цитатой(-ами)
или это задумалось как статья?
Материал очень ценный, просто я не дорос еще до этого уровня.
ST>Мы знаем, что не все программные системы сложны. Существует множество программ, которые задумываются, разрабатываются, сопровождаются и используются одним и тем же человеком. Обычно это начинающий программист или профессионал, работающий изолированно. Мы не хотим сказать, что все такие системы плохо сделаны или, тем более, усомниться в квалификации их создателей. Но такие системы, как правило, имеют очень ограниченную область применения и короткое время жизни. Обычно их лучше заменить новыми, чем пытаться повторно использовать, переделывать или расширять. Разработка подобных программ скорее утомительна, чем сложна, так что изучение этого процесса нас не интересует.
... ST>5. "Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы".
Необходимость быть программистом+тестировщиком+ПМом+начальником действительно
утомляет и, если хорошо подумать, то результат действительно лучше не расширять.
Но все же с первого взгляда не видно, чем объясняется отличие между простой
системой 1 разработчика и простой системой разработанной коллективом.
Здравствуйте, jeeist, Вы писали:
J>К сожалению, не понял формат Вашего сообщения — является ли весь выделенный Вами текст цитатой(-ами) J>или это задумалось как статья?
J>Материал очень ценный, просто я не дорос еще до этого уровня.
Большая часть — это цитаты книги Гради Буча "Объектно-ориентированный анализ и проектирование", в частности первой ее части. Я приводил цитаты кусками, поэтому вполне мог "потерять" что-то ценное и изложение могло стать не совсем понятным.
2-е издание Буча доступно в электронном виде на русском языке. Первая часть книги (как по мне, наиболее ценная) практически не поменялась в третьем издании по сравнению со вторым.
Поэтому, если цитаты заинтересовали — почитайте хотя бы первую часть этой книги, должно быть как минимум интересно.
Здравствуйте, vl690001x, Вы писали:
J>>Заинтересовал вопрос: как лучше освоить ООП? J>>Точнее — что следует освоить перед этим.
V>Прочитай книгу Гради Буча "Объектно-ориентированный анализ и проектирование". Она есть в электронном виде, но такие книги лучше иметь в бумажном варианте. Собственно, даже не знаю, что нужно знать перед ООП, но однозначно, для этого надо быть в какой-то степени личностью, организованной по принципам ООП). Вообще, изучить ООП нелегко, это большая работа, но легких путей не бывает. НЕ БЫВАЕТ, советую еще раз перечитать эти слова.
Инжинер должен решать задачу, а не ходить нелегкими путями, как завещали прадеды. Причем решать максимально эффективно. Hype созданный для того, чтобы Rational Rose являясь абсолютным мусором продавалась за огромные деньги — он уже схлынул. ООП — имеет свои вполне конкретные плюсы. И решать с помощью ООП надо вполне инжинерные задачи, а не пытаться моделировать предметную область, как завещали Буч и компания.
Я, кстати, чем дальше тем больше сомневаюсь, что вопрос моделирования предметной области должен выражаться в терминах "а чтобы потом иметь естественный язык, который эту область описывали". Этого не получилось сделать на классах и объектах — решили вот теперь, что нужно с помощью макро-функциональщины моделировать языки, которые более гибкие и могут описать, как товары на склад/со склада уходят и транзакции между банками бегают. Язык, да еще и с уникальным синтаксисом, еще сложнее менять и отлаживать, чем набор классов. И если задача управления складов как всегда неожиданно потребовала, чтобы задача поддерживала три новых абстракции и радикально поменять пару существующих — то часто может оказаться, что лучше уж бы это был С-ный набор методов, который структуры передает, чем навороченная модель классов/собственная модель языка. Инструмент и инфраструктура для решения задачи опять может оказаться сложнее исходной задачи.
Здравствуйте, IT, Вы писали:
IT>Кстати, SQL по логике denisko тоже должен умереть. В нём же при дизайне БД надо отвечать на вопросы 'как организовать структуру, чтобы все объекты дружили, как выстроить их иерархию, как, как,как ... Куча как...'
Вот SQL как раз пофиг как...Например ему пофиг как объект наблюдатель и объект инквизитор придут в гости к объекту поле данных и будут уныло тупить,
поскольку архитектор "на этапе проектирования" не заложил в них способность поддерживать светскую беседу. Он просто говорит сделай мне то-то и то-то. Понимаешь надо уходить от того, что тебе приходится утирать сопли объектам и разбираться что и как в них от рождения было заложено. И какие у них там семеные и иерархические проблемы. Надо так -- дал поручение объекту, если выполнил то сказал спасибо, нет -- дал песты. И не дай бог заботится о том, чтобы у это шибздрика было реализован интерфейс пестополучатель. Возможна такая картинка? Да вполне. Возможна ли скоро? Да, имхо препятствий кроме лени нет. Какая парадигма удобнее для нее альтруистичная (когда ты объектам и папа и мама и на дудец игрец и вообще в курсе их проблем) или функциональная ( когда есть что тебе надо сделать, а как и кем -- пофиг. Ты платишь за результат) ответь сам.
+1024. Ты очень даже прав. Просто не могу не поделиться своими терзаниями по этому поводу.
Предостережение. Букв буде много, а мысли сумбурны. Автор не несет ответственность за возможное повреждение вашего мозга.
По мне уже 20 лет гуляет идея. Родилась она, когда я проектировал имитационные модели сложных космических систем. Как-то меня осенило, что объектов и их свойств в реальном мире как таковых нет. Это лишь способ отражения объективной реальности в нашей голове. А что же есть? Есть структуры и их взаимодействия.
Пример 1.
Не существует свойство «синий», например, у автомобиля. Это лишь один из возможных результатов трехстороннего взаимодействия некоторых элементов:
1) поток фотонов из источника света;
2) отражение и излучение (незабываем про инфракрасный диапазон) фотонов кузовом автомобиля;
3) наблюдатели, которые увидят совершенно разные цвета, в зависимости от того, какого цвета очки у них на глазах.
Пример 2.
С одной стороны, если мы моделируем дорожное движение, то автомобили следует рассматривать как элементарные узлы структуры, которые вступая во взаимодействие (обгоняя, подрезая, тормозя), консистентно изменяют свое положение в фазовом пространстве (скорость, ряд).
С другой стороны, автомобили перестают быть элементарными узлам структуры, как только мы начинаем рассматривать их взаимодействие при столкновении (вопрос поклонникам ООП: при столкновении кто кому посылает события?). Мы должны перейти на более низкий структурный уровень. На этом уровне элементарными узлами, по-видимому, должны быть: бампер, кузов, рама, двигатель и проч. составные части, а также способы их соединения (болты, сварка и т.д.).
Вывод. Свойств и объектов нет. Есть структуры и их взаимодействия.
Что же из этого следует?
Программирование это способ отображения ментальных моделей в исполнимый код (без доказательства).
ИМХО, элементарным и неделимым атомом нашего знания является представление о структурах и взаимодействиях в них. Поэтому наиболее экономное представление наших ментальных моделей в программных системах мы получим, когда научимся изоморфно отражать элементы структур и их взаимодействия из наших ментальных моделей в программные компоненты.
), предлагаю попытаться представить, как это может выглядеть.
Мы должны разработать библиотечный метод carry (Еcarrier, Еthing). Элемент Еcarrier должен реализовывать интерфейсы: "Брать" и "Перемещаться в пространстве". А элемент Еthing должен реализовывать интерфейсы: "Вес" и "Форма".
В этом случае наша модель действия нести получится достаточно универсальной. Метод не будет меняться от того, что человек реализует интерфейс Брать руками, собака — зубами, а подъемный кран — крюком. Поэтому мы сможем легко пополнять нашу программную систему любыми элементами, которые реализуют необходимые для Еcarrier, Еthing интерфейсы и нам не понадобится менять нашу универсальную функцию.
Есть еще много фундаментальных проблем, которые требуется решить на пути к новой более экономной парадигме программирования. Например, что есть время и как его моделировать в программных системах? А пространство? А физические поля?
Я размышляю хоть и много, но не очень продуктивно
Мой коллега по ЦУПу, человек с необычайной энергией, развивая некоторые мои идеи, разработал некоторый универсальный решатель научно-технических задач. Если кого заинтересовало, смотреть здесь и около. Однако, это лишь инструмент инженера, а не новая парадигма программирования, которую бы хотелось получить.
Буду рад, если мой поток сознания подтолкнет кого-нибудь к продуктивным размышлениям в обозначенном направлении.
Здравствуйте, craft-brother, Вы писали:
CB>Предостережение. Букв буде много, а мысли сумбурны. Автор не несет ответственность за возможное повреждение вашего мозга.
После того, как не далее как вчера дочитал "Структуру реальности" Дэвида Дойча, мой мозг уже ничто, наверное, повредить не может
CB>Программирование это способ отображения ментальных моделей в исполнимый код (без доказательства). CB>... CB>Есть еще много фундаментальных проблем, которые требуется решить на пути к новой более экономной парадигме программирования. Например, что есть время и как его моделировать в программных системах? А пространство? А физические поля?
А зря без доказательства.
Меня не оставляет смутное ощущение, что мировой теоретикал компутер сайнс неоправданно сильно заигрался моделированием. С одной стороны, это понятно. Компьютер — чрезвычайно эффективный вычислитель, а вычисление — это применение формулы, а формула — это математическая модель явления. Но кто из нас, айтишников, хотя бы 50% своего рабочего времени занимается научными расчётами? Ась? Есть здесь такие?
Когда-то, давным давно, когда компьютеры можно было пересчитать по пальцам, они действительно использовались исключительно для выполнения тяжёлых расчётов (в основном в чрезвычайно актуальных задачах ядерной физики и баллистики). Теперь же они используются в основном как средство общения и как развлекательные центры. Сейчас компьютер — это один из инструментов решения повседневных задач. Вернее сказать, это целый набор разнообразных инструментов (программ), удачно использующий заложенный в свою основу идею универсального вычислителя.
Т.е. программирование — это не способ отражения, и не способ преломления, а способ создания инструментов. Давайте теперь посмотрим, какие инструменты в истории материальной культуры были наиболее удачны и востребованы, и где там внутри них заложены модели:
Топор. Один из первых созданных человеком инструментов. Активно используется до сих пор. Модели дерева в себе не содержит, модели стройки — тоже. Только заострённый кусок твёрдого тяжёлого материала, прикреплённый к не очень длинной ручке. Молоток, нож — та же фигня. Никаких моделей.
Колесо (круглый предмет, закреплённый на оси). При желании можно найти прообраз, но никаких моделей не содержит. Да и вообще, очень всем нужные средства транспорта — автомобиль, паровоз, самолёт, ракета, не содержат в себе реализаций моделей предметной области.
Перо, чернила, бумага. Одна из самых первых, и до сих пор одна из самых распространённых и полезных информационных технологий. Никаких моделей в себе не содержит.
Да, естественно, при создании инструмента мы должны весьма чётко представлять себе мир, в который попадёт создаваемый предмет. Учесть и законы физики, и законы химии, и психологию, и социологию, и эргономику. Пропустить макрокосм через свой личный микрокосм. Может быть, это и есть то самое моделирование? Вряд ли. В предмет закладывается только результат этого "моделирования", но сама модель в предмет не закладывается. "Модель" остаётся в голове создателя и, возможно, в набросках/технической документации/мемуарах.
Отсюда вопрос. Почему всем "обычным" ремесленникам нужны средства производства, просто и эффективно решающие задачу, а программисту нужны исключительно такие, которые позволяют закладывать в продукт какую-то модель? Декларируемая как преимущество ООП его способность закладывать в программу модель мира — это на самом деле никакое не преимущество. Это увод мысли в сторону, бессмысленная трата времени и сил.
Ничего не имею против моделирования как такового. Моделирование — хорошая и мощная исследовательская технология. В самом деле, гораздо проще, дешевле и безопаснее "взрывать" модель термоядерного фугаса в памяти компьютера, чем устраивать реальный бабах. Гораздо логичнее сначала продуть деревянную модельку самолёта в аэродинамической трубе, чем собирать реальный аппарат и бегать потом по полю собирать дымящиеся обломки. Проще имитационно промоделировать систему массового обслуживания, чем потом краснеть перед заказчиком, когда всё накроется.
Но когда дело доходит до дела, мы должны создавать не модели предметов, а сами предметы. Мы должны закладывать в результат нашего труда не модель, а результат моделирования (ментального, имитационного или какого-нибудь ещё). Давайте не будем усложнять и без того непростую жизнь программиста совершенно бесплодными соблазнами и тупиковыми путями.
CB>ИМХО, элементарным и неделимым атомом нашего знания является представление о структурах и взаимодействиях в них. Поэтому наиболее экономное представление наших ментальных моделей в программных системах мы получим, когда научимся изоморфно отражать элементы структур и их взаимодействия из наших ментальных моделей в программные компоненты.
Не надо быть чересчур самонадеянными. В голове у нас (у всех) бардак полный. Абсолютно нечёткая логика, а иногда и вообще полное её отсутствие. Противоречие на противоречии. С точки зрения инженера-схемотехника наш мозг — это печальный результат взрыва на макаронной фабрике. Но во всём этом не только наша слабость, но и величайшая наша сила. Математика и компьютеры — наша палочка-выручалочка, позволяющая хоть как-то упорядочить это безобразие. Может быть, не стоит портить палочку-выручалочку?
Поймите правильно. Это не призыв заморозить TCS и запретить кому-то над чем-то думать. Просто есть действительно важные, актуальные и совершенно никем не проработанные направления исследований, а есть соблазнительная, вкусная, но совершенно не питательная (может быть, пока не питательная) жвачка для ума типа прохождения теста Тьюринга или моделирования реального мира в программных реализациях текстового редактора.
Здравствуйте, Voblin, Вы писали:
V>Отсюда вопрос. Почему всем "обычным" ремесленникам нужны средства производства, просто и эффективно решающие задачу, а программисту нужны исключительно такие, которые позволяют закладывать в продукт какую-то модель? Декларируемая как преимущество ООП его способность закладывать в программу модель мира — это на самом деле никакое не преимущество. Это увод мысли в сторону, бессмысленная трата времени и сил.
Может потому-что программист в виде продукта и создает эти самые модели и больше ничего?
V>Ничего не имею против моделирования как такового. Моделирование — хорошая и мощная исследовательская технология.
Так очень большая часть работы любого программиста исследовательская, или как минимум требующая очень похожих навыков.
Здравствуйте, FR, Вы писали:
V>>Декларируемая как преимущество ООП его способность закладывать в программу модель мира — это на самом деле никакое не преимущество. Это увод мысли в сторону, бессмысленная трата времени и сил. FR>Может потому-что программист в виде продукта и создает эти самые модели и больше ничего?
Может быть, в этом и проблема? Если бы кораблестроители вместо кораблей стали строить модели кораблей, а землекопы вместо копания ямок копали бы в песочнице модели ямок, никто бы их по головке не погладил...
FR>Так очень большая часть работы любого программиста исследовательская, или как минимум требующая очень похожих навыков.
У кого как. По своему опыту скажу, что процентов 80 работы по изготовлению продукта — это созидание (т.е. синтез). Исследовательская работа (т.е. анализ) обычно бывает в начале процесса при постановке задачи и выборе метода решения и в конце, когда нужно понять, почему оно не работает
Анализ и синтез — это принципиально разные навыки. Оба они, конечно, нужны, но способность к синтезу в нашем ремесле важна принципиально.
Здравствуйте, Voblin, Вы писали:
FR>>Может потому-что программист в виде продукта и создает эти самые модели и больше ничего?
V>Может быть, в этом и проблема? Если бы кораблестроители вместо кораблей стали строить модели кораблей, а землекопы вместо копания ямок копали бы в песочнице модели ямок, никто бы их по головке не погладил...
Если бы у кораблестроителей была возможность с помощью чистого описания и моделирования строить реальный корабль, они с радостью бы это делали.
V>У кого как. По своему опыту скажу, что процентов 80 работы по изготовлению продукта — это созидание (т.е. синтез). Исследовательская работа (т.е. анализ) обычно бывает в начале процесса при постановке задачи и выборе метода решения и в конце, когда нужно понять, почему оно не работает
Не только, этап конструирования и мелкого проектирования длится до окончания разработки, и исследование там тоже нередко применяется.
V>Анализ и синтез — это принципиально разные навыки. Оба они, конечно, нужны, но способность к синтезу в нашем ремесле важна принципиально.
Здравствуйте, FR, Вы писали:
V>>Может быть, в этом и проблема? Если бы кораблестроители вместо кораблей стали строить модели кораблей, а землекопы вместо копания ямок копали бы в песочнице модели ямок, никто бы их по головке не погладил... FR>Если бы у кораблестроителей была возможность с помощью чистого описания и моделирования строить реальный корабль, они с радостью бы это делали.
Здесь я, конечно, перегнул маленько Естественно, те кораблестроители, которые сидят в проектных институтах, строят именно модели кораблей. У них эти модели называются "чертёж", "спецификация", "технологическая карта", "рабочий проект". В отличие от материального производства в программировании, как правило, результат проектирования и является готовым изделием (ничто так хорошо и однозначно не документирует программу как её исходник).
Речь о другом. В конструкцию корабля не закладывается имитационная модель моря, порта, матросов и перевозимого груза. Знания о море, конструкции портовых сооружений, о людях и т.п. используются при проектировании (а как же ещё?), но непосредственно в конструкцию не закладываются.
Если при проектировании гипотетической программы-корабля применить ООП, сразу же возникнет соблазн создать классы CSea, CSalor, CCargo и пр., и попытаться нарисовать всё сложное взаимодействие между ними. Зачем — ХЗ Просто потому, что считается модным моделировать реальный мир и того требует методология ООД.
V>>У кого как. По своему опыту скажу, что процентов 80 работы по изготовлению продукта — это созидание (т.е. синтез). Исследовательская работа (т.е. анализ) обычно бывает в начале процесса при постановке задачи и выборе метода решения и в конце, когда нужно понять, почему оно не работает FR>Не только, этап конструирования и мелкого проектирования длится до окончания разработки, и исследование там тоже нередко применяется.
В реальном софтостроении на этапе разработки моделирование применяется вообще очень редко. Макетирование (пробные прогоны на неполной функциональности, юнит-тесты) — сплошь и рядом. Моделирование — что-то вообще не припомню прецедентов. Разница между макетированием и моделированием — огромная.
V>>Анализ и синтез — это принципиально разные навыки. Оба они, конечно, нужны, но способность к синтезу в нашем ремесле важна принципиально. FR>Угу вот только оба навыка необходимы.
Конечно. И ещё важен навык написания пользовательской документации без применения ненормативной лексики.
Здравствуйте, SergeyT., Вы писали:
ST>Здравствуйте, jeeist, Вы писали:
J>>К сожалению, не понял формат Вашего сообщения — является ли весь выделенный Вами текст цитатой(-ами) J>>или это задумалось как статья?
J>>Материал очень ценный, просто я не дорос еще до этого уровня.
ST>Большая часть — это цитаты книги Гради Буча "Объектно-ориентированный анализ и проектирование", в частности первой ее части. Я приводил цитаты кусками, поэтому вполне мог "потерять" что-то ценное и изложение могло стать не совсем понятным. ST>2-е издание Буча доступно в электронном виде на русском языке. Первая часть книги (как по мне, наиболее ценная) практически не поменялась в третьем издании по сравнению со вторым. ST>Поэтому, если цитаты заинтересовали — почитайте хотя бы первую часть этой книги, должно быть как минимум интересно.
Читал 10 лет назад, несколько раз читал, было интересно, но не связывалось с реальной жизнью.
Но значит, выбор все же был правильный.
Спасибо за совет! Учту, но на данный момент меня интересуют книги, в которых описано, что такое программирование,
например, цикл. Что такое императивное, функциональное программирование.
Имеется ввиду не книги типа Java за полчаса для идиотов, а книги, которые используются
в курсах связанных с информатикой/computer science.
Здравствуйте, jeeist, Вы писали:
J>Здравствуйте, SergeyT., Вы писали:
J>Спасибо за совет! Учту, но на данный момент меня интересуют книги, в которых описано, что такое программирование, J>например, цикл. Что такое императивное, функциональное программирование.
J>Имеется ввиду не книги типа Java за полчаса для идиотов, а книги, которые используются J>в курсах связанных с информатикой/computer science.
J>Ахо+Ульман?
Естественно, те кораблестроители, которые сидят в проектных институтах, строят именно модели кораблей. У них эти модели называются "чертёж", "спецификация", "технологическая карта", "рабочий проект". В отличие от материального производства в программировании, как правило, результат проектирования и является готовым изделием (ничто так хорошо и однозначно не документирует программу как её исходник).
