Предметное мышление: Предметное мышление | это… Что такое Предметное мышление?

Содержание

Типы мышления (модель Джерома Брунера)

Мышление - это индивидуальный способ переработки поступающей информации, форма психического
отражения человеком действительности.              
      Выделяют 4 базовых типа мышления, каждый из которых обладает специфическими характеристиками: 
- предметное
- образное
- знаковое
- символическое                                                        
Джером Брунер, американский психолог и педагог, крупнейший специалист в области исследования когнитивных процессов. рассматривал мышление как перевод  с  одного  языка  на  другой.                                                                    
Таким образом, при четырех базовых языках возникает  шесть  вариантов  перевода:                                                                  
      - предметно-образный (практический),                                    
      - предметно-знаковый (гуманитарный),                                    
      - предметно-символический (операторный ),                                
      - образно-знаковый (художественный),                                    
      - образно-символический (технический),                                  
      - знаково-символический (теоретический).                                 
 
      Выделяются следующие факторы мышления:                                
      - практичность - теоретичность;                                         
      - гуманитарность - техничность;                                         
      - художественность - операторность;                                     
      - конкретность - абстрактность.                                         
 
                           
 
      Предметное мышление.                                                  
Люди с практическим складом ума предпочитают предметное мышление, для  которого характерны неразрывная связь с предметом в пространстве и  времени, осуществление 
 преобразования информации с помощью
предметных действий,  последовательное выполнение операций. Существуют физические ограничения на 
 преобразование. Результатом такого типа мышления становится мысль,  воплощенная в новой конструкции.                                                 
 
      Символическое мышление.                                               
 Люди с математическим складом ума отдают предпочтение  символическому  мышлению, когда происходит 
преобразование информации с помощью правил  вывода (в частности, алгебраических правил или 
арифметических знаков и  операций). Результатом является мысль, выраженная в виде структур  и  формул,  фиксирующих существенные отношения между символами.    
                    
        Знаковое мышление.                                                    
 Личности с гуманитарным складом ума предпочитают  знаковое  мышление.  Оно характеризуется преобразованием информации  с  помощью  умозаключений.  Знаки объединяются в более крупные единицы по правилам единой  грамматики.  Результатом является мысль в форме понятия или высказывания,  фиксирующего  
 существенные отношения между обозначаемыми предметами.                      
 
      Образное мышление.                                                   
Люди с художественным складом ума предпочитают образный тип мышления. Это отделение от предмета в пространстве и времени, осуществление преобразования информации с помощью действий с образами
 . Нет физических ограничений на преобразование. Операции могут осуществляться 
как  последовательно,  так и одновременно. Результатом служит мысль, воплощенная в новом образе.

Предметное мышление и творческое мышление

Набрела я на вот такую интересную статью http://psyberia.ru/mindterritory/predmet , выдержка из которой — ниже. О пользе и вреде порядка и беспорядка. Именно так : о пользе и вреде порядка и о пользе и вреде беспорядка.
И есть там любопытные моменты о «сканере» внутреннем и активном внимании. И о том, что перебарщивать с наведением порядка для других — не стоит. Даже если у вас этот «сканер» развит, вполне возможно, что другим более присуще «активное внимание».

Но цель поста даже не в дискуссии о пользе и вреде. Скорее мне интересно, как можно воспользоваться преимуществами «сканера», не утратив при этом присущее «полезное внимание»

Потому, как у меня, например, образовалась серьезная проблема — как только я начинаю что-то «системно записывать» или раскладывать — я начинаю не замечать элементарнейшие раньше вещи. Иными словами, начинаю делать ошибки. При этом «сканер» природно мне не присущ, потому работает кое-как, а активное внимание уже утрачивается в надежде на то, что он сработает.

Как найти тот БАЛАНС между порядком и беспорядком, который не приведет к катастрофе?
Потому, что в ситуации полной упорядоченности жизни я начинаю чувствовать себя растерянно, неуютно и делать ошибки. После этой статьи я поняла — почему.

Может кому-то удалось это совместить, и такие «неупорядоченные» личности, как я, все же умудрились сохранить в рабочем состоянии свой «детектор ошибок», при этом воспользовавшись преимуществом «внутреннего сканера»

Бардак на рабочем столе обычно приписывают шибко творческим личностям. А почему? Какие тут есть идеи? Почему идеальный порядок так плохо рифмуется с творчеством?

Здесь, вероятно, ключ к разгадке лежит в разнице между нашим зрительным восприятием и нашей зрительной памятью. Для того, чтобы найти предмет, можно искать его глазами, а можно искать его в своей памяти. И если вещи жестко определены на своих местах, то их будет достаточно трудно увидеть сознательно. У нас формируется шаблон зрительного опыта, а процесс поиска становится процессом «сравнения» увиденного с запомненным ранее. Это похоже на сканер, который считывает штрих-код с упаковки. Активное внимание напрочь отсутствует.

Если же предметный мир никак не организован, то этот сканер не работает, ибо у него нет исходных данных. Человек вынужден всё время задействовать активное внимание. В этом есть как свои плюсы, так и минусы. Минус – в том, что такой человек сильно перегружает своё сознание. С ним много труднее разговаривать, он постоянно «уходит в себя», переключает своё внимание на что-то постороннее, всё время «сам себе на уме». А плюс – в том, что он умеет замечать и подмечать то, что не способен увидеть сторонник идеального порядка. В его поле зрения постоянно попадают мелочи и детали, которые укрылись от взора других людей. Он умеет видеть и замечать. На что «сканер» просто неспособен.

Ссылка на полный текст статьи вверху.

Object Thinking (DV-Microsoft Professional) Дэвид Уэст

27 сентября 2019 г.

Если вы серьезно относитесь к объектно-ориентированному программированию, вам необходимо прочитать эту книгу. Я писал код на Java и C++ более 15 лет и ненавидел то, что создавал. Эта книга перевернула мое сознание. Я не стал лучше кодировать после прочтения, так как внутри нет кода. Я стал гораздо лучшим дизайнером. Я даже написал несколько собственных книг после прочтения работ Дэвида Уэста.

Я настоятельно рекомендую вам подумать о том, что вы найдете в этой книге. Не воспринимайте это как очередную книгу о программировании. Эта книга должна стать поворотным пунктом в вашей профессиональной жизни. В противном случае просто выбросьте его, вы еще не готовы к нему.

объектно-ориентированное программирование

6 июня 2012 г.

В этой книге мне очень понравились две вещи. Первым было обсуждение различных школ философии и того, как эти идеи проявляются в программном обеспечении. Вторым были врезки по истории, которые представляли разных ученых-компьютерщиков и объясняли их вклад в эту область.

Основная мысль книги заключалась в том, что вы должны писать свои приложения как набор объектов, взаимосвязь которых приводит к эмерджентному поведению вашего приложения. Кроме того, ваши модели должны пытаться моделировать объекты и понятия реального мира в вашей предметной области.

Это здорово и все такое, но в книге нет примеров. Никто. И он делает огромное количество утверждений о том, насколько этот подход лучше и чем все остальные хуже, но ничем не подкрепляет эти утверждения. Ничего.

Итак, в конце концов, у меня осталось ощущение, что, вероятно, там есть несколько хороших идей, но я совершенно не убежден, что автор когда-либо писал реальное бизнес-приложение. Кроме того, я думаю, что он может быть просто сварливым старым чуваком, которому грустно, что Small Talk уступил место более зрелым и практичным языкам, таким как C++ и Java.

tech

10 мая 2017 г.

# Объектное мышление
Это хорошая книга, в которой представлены несколько интересных и неочевидных идей о философии разработки программного обеспечения. Например, связь с герменевтикой и постмодернизмом, хотя и не обязательно новая, обычно не рассматривается. Так что, безусловно, стоит обратить внимание на неформалистское направление для вдохновения в отношении SWE.
Но у меня есть некоторые возражения против книги, и я думаю, что они довольно серьезные.
Во-первых, что касается вышеупомянутого литературного подхода к разработке программного обеспечения — программирование — это не литература. Хотя с точки зрения его создания вполне может быть верно, что вопрос коммуникации имеет первостепенное значение, и мы должны сосредоточиться на нем, а не на формальных методах. Это не литература в том смысле, что у нас действительно есть четкие объективные показатели для измерения успеха проекта разработки программного обеспечения. Стоимость, количество ошибок, обнаруженных после релиза, продолжительность разработки — все это полностью измеримо и очень важно. Мы не создаем программное обеспечение ради искусства (хотя нам, возможно, придется подходить к самому процессу как к художественному, а не инженерному проекту, конечно, это то, что пытается доказать книга, и у меня нет реальных возражений против этой идеи) , мы создаем его в чисто прагматических целях, и, следовательно, его можно объективно оценить как успех или неудачу. Тот факт, что его можно снабдить явными числовыми метриками, идеально подходит для рандомизированных контрольных испытаний. Чем формалистический подход (даже дифференцирующие методы) хуже или лучше литературного, мы можем проверить опытным путем. И нет места для интерпретации таких экспериментов, потому что они подпадают под научный метод. Сложность заключается в том, что такие строгие эксперименты были бы чрезвычайно сложными и невероятно дорогими. Я хочу сказать не о том, что мы должны отказаться от литературного подхода в пользу формалистического, а только о том, что у нас нет доказательств ни для того, ни для другого, в то время как доказательство действительно возможно найти (что, по-видимому, не относится к литературе и некоторым другим связанным с языком). / семиотические проблемы вообще).
Еще одна критика, которую я имею по отношению к тексту, заключается в том, что он в основном строит свои аргументы путем, во-первых, обращения к авторитету и, во-вторых, путем простого повторения утверждения, что парадигма ООП является лучшей. Он повторяет снова и снова, без каких-либо подтверждений, что это способ делать что-то, что это сделает вашу программу лучше, что это сделает разработчиков лучшими людьми, что это облегчит изменение программы, рассуждать о чем угодно. ты. А потом снова повторяет. А потом еще разок. И еще один. Это должно убедить меня, я думаю. Ну, это не так. На самом деле, это делает как раз наоборот. Это звучит так много раз, что сейчас я отношусь к этой идее более скептически, чем до прочтения этой книги.
Может быть, я слишком глубоко укоренился в своих привычках, но когда книга подталкивает к объединенному подходу, у меня возникает что-то вроде коленного рефлекса, и я хочу немедленно прекратить ее читать. Когда он продолжает идею помещения всех объектов, богатых данными, в объединенные словари (например, Map в терминах Java), на этом этапе становится действительно трудно пытаться оценить его советы.
И самое главное, что полностью испортило для меня сообщение, это то, что эта книга, я не шучу, содержит в себе жемчужину очень плохо написанного фанфика. Вот такой «пример» того, как разработка проекта может проходить в модальности ООП/ХР, который на самом деле является просто историей (не ХР-историей, а литературной), рассказывающей нам о волшебном мире ООП/ХР. странным пасторальным тоном, полным рассказов о том, как все хорошо в ООП-королевстве любви. Разработчики XP в сюжетной программе похожи на счастливых маленьких эльфов, они знают, что в процессе рефакторинга они достигнут блаженного результата в виде более удобного в сопровождении программного обеспечения, которое делает все так, как должно, они всегда хорошо рефакторируют свои истории XP, а затем идут с улыбкой к своим компьютерам и общаются с ними довольно герменевтически (они даже не создают артефактов документации, потому что намерения разработчика не могут быть переданы с помощью таких средств). И, о боже, о боже, программное обеспечение хорошо работает в их руках. Теперь его так легко поддерживать, так легко расширять, и все они берутся за руки и танцуют свой счастливый маленький танец. Более того, ребята, которые больше других работали с предметами, создают что-то еще лучше, и все это сразу видят. И это все БС. На самом деле, это не более чем фантазия, замаскированная под «пример» текста, который имеет целью остаться в моей памяти как реальный исторический отчет об успехе ООП/ХР. Это подрывная деятельность (не VCS).
Некоторые цитаты из вкладышей «Перспективное мышление»:
> «Разработчики разбиваются на пары, выбирают историю и начинают разработку. Все уверены, что мы можем начать разработку с таким скудным определением требований и без какого-либо формального моделирования. \[…\] Никто не чувствует необходимости создавать синтаксически точные модели, но удивительно, как много всего записывается и рисуется в процессе обсуждения и написания кода. Интересно, что те, кто занимается объектами дольше, как правило, делают меньше заметок по мере их выполнения \[…\]» (стр. 50)
> «Однажды в пятницу днем команда собирается уходить, когда Салли оглядывает комнату, как будто видит ее впервые. «Знаешь, — говорит она почти себе, — это место — довольно хорошая визуальная метафора» (стр. 167)
> «Все здесь уверены — мы все усвоили много знаний \[…\] об объекте. мышления и практики XP». \[…\] «Каким-то образом мы научились новому способу думать о проблемах, новому словарю для размышлений и новому способу действовать — работать». «И радость и спокойствие вместе с уверенностью». «Ха, похоже, мы все как-то просветлены». (стр. 168)
Есть один более-менее проработанный пример с заявкой на ипотеку, но он меня все равно разочаровал. Недостаточно подробностей, слишком много ласковых слов.
В общем, я бы порекомендовал эту книгу, кажется, что в ней таятся некоторые глубокие идеи (многие из которых, как мне кажется, я не раскрыл, вероятно, из-за отсутствия у меня умственных способностей), но, пожалуйста, включите своего скептика хотя бы в 8 перед чтением. И всегда думайте, «подтверждено ли это утверждение доказательствами»? Если нет, вы все равно можете принять это, провести свои собственные эксперименты (даже один), но помните, в очень постмодернистской традиции, что это акт веры.

На самом деле все эти книги о методологии и подходах к программному обеспечению несколько утомительны. Что нужно увидеть инженеру-программисту, чтобы на самом деле убедиться или, по крайней мере, начать думать в том направлении, в котором его хочет видеть сторонник той или иной идеологии? Очередная книга, полная слов, эссе и обещаний? Нет, я думаю, что сейчас мы хотим просто код. Дайте нам код, дайте нам большие, сложные проекты с открытым исходным кодом на Github или что-то еще, что мы можем изучить, из чего мы можем извлечь уроки, и решить для себя достоинства подхода, на который вы хотите, чтобы мы подписались. Трудно писать книгу, так что, может быть, не надо. Пишите публичный код, это было бы здорово, а не причитания и фанфики.

Если вы программист, эта книга обязательна к прочтению! Почему? Это напоминает вам, почему программирование — это не просто написание кода в стиле, который вы приняли и который возник из вас самих. Это целый мир, состоящий из взаимодействий объектов, как и мир, в котором мы живем. Он напоминает вам о хороших принципах, коммуникативных идеях и методологиях для поиска взаимодействий объектов в данной области. В нем излагаются принципы XP и то, как действительно быть гибким в разработке программного обеспечения. Это отличное чтение, правда!

научно-популярное программирование

Мэтт

13 отзывов1 подписчик

Феноменальный. При втором прочтении. На этот раз без словаря. Концепции, изложенные в этой книге, жизненно важны для понимания всеми разработчиками бизнес-приложений. Это будет установлено как обязательное чтение для моей группы разработчиков.

Эта книга действительно заставила меня задуматься о том, как я смотрю на программное обеспечение, которое пишу, и надеюсь, что смогу использовать эту информацию для улучшения своего кода.

Читать

Принципиально стоящее.

Устаревший, но не ужасно, и историческая перспектива кода пользовательского интерфейса позволила мне построить интересное параллаксное представление о том, как я подхожу к нему сегодня как веб-разработчик.

Иногда идеи бывают капризными, странными или и тем, и другим: его игнорирование систем типов — это игнорирование тех, кто предполагает, что «строгая типизация» является синонимом Java, и как давний программист Ruby я называю его полный бред. мнение о том, что ошибки типов редко встречаются в профессиональном коде, поддерживаемом тестами. Его любовь к бескрайним морям объектов, которые волей-неволей испускают события, часто читается так, будто он ставит любимые теории выше практических проблем отладки. И хотя его ненависть к реляционным базам данных вполне обоснована (достаточно для того, чтобы теперь я понял, почему некоторые разработчики, которых я в остальном уважаю, питают странную привязанность к Mongo), его неприятие моделирования данных как полезного процесса заходит слишком далеко.

В конечном счете, самым большим недостатком книги является тот, который я всегда вижу в «классическом» написании XP. Многие из практик и заявлений Agile имеют поразительное сходство с феминистскими идеями старой школы, часто *особенно* с идеями интерсекциональных феминисток и/или феминисток. Очень мало agile-писателей признают эту конвергентную эволюцию или — боже упаси — читают феминистские работы, включают их, цитируют эти источники. Эта проблема *особенно* бросается в глаза в _Объектном мышлении_, поскольку Уэст уделяет так много времени философским основам объектно-ориентированного проектирования и понятиям автономии объектов, охватывая восходящие или неиерархические модели продукта, образование как процесс инкультурации. а не передачу знаний и т. д. (Часть о том, что эффективная разработка программного обеспечения является культурно передаваемой практикой, была особенно вопиющей; Уэст, похоже, не осознавал, что этот отрывок также читается как прославление однородности «культуры» в инженерии.)

По иронии судьбы я думаю, что если бы Уэст усвоил идеи чернокожих феминисток о том, как следует анализировать человеческую практику в контексте их жизненного опыта… то, что он сказал о системах типов и реляционных базах данных, могло бы лучше сочетаться? Но это я сопливый.

Смешанные чувства. Могло бы быть и лучше (или, может быть, мне нужно перечитать это снова)

Мне понравилась предыстория философии объектов и некоторые идеи о том, как идентифицировать и проектировать объекты. Это немного изменило мой образ мыслей, и это хорошо. Мне также понравились идеи правил самооценки и несколько общих дизайнов объектов (называемых здесь фреймворками).

Что мне не понравилось, так это то, что материал изложен по существу (как будто все несомненно верно), без обсуждения (или даже упоминания) альтернативных идей. Кроме того, книга была бы гораздо более ценной, если бы в ней были хотя бы несколько примеров реализации (особенно в главе о правилах самооценки, где автор говорит что-то вроде «Мы внедрили такие правила с моим коллегой, но мы никогда не публиковал статью. Но поверьте мне, это возможно».).
У меня также возникло ощущение, что Дэвид Уэст пытался связать свои идеи с XP (agile) — может быть, в качестве маркетингового хода — как будто объектного мышления было недостаточно, чтобы существовать самостоятельно.

Поскольку книга довольно теоретическая, я думаю, что мне придется перечитать ее (частями).

Приятно читать!
Это не учебник по программированию, и он не научит вас писать лучший код. Он представит вам подход объектного мышления к проблемам, которые решаются при разработке программного обеспечения. Он не претендует на то, что это единственный подход к решению таких проблем, но он расширит ваше понимание ООП и проектирования программного обеспечения.

Книга начинается с интересного обсуждения формалистической и гермевтической философии, их значения в области разработки программного обеспечения и некоторого исторического контекста. Автор приходит к выводу, что формалистская методология наносит ущерб процессу проектирования программного обеспечения, который представляет собой деятельность, ориентированную на человека, творческую и ориентированную на предметную область. С этого момента этот вывод используется для построения понимания объектов, которое не ограничивает их простой комбинацией данных и методов.

К счастью, автор предоставил обширный список ссылок как на философские книги, так и на книги по дизайну программного обеспечения, так что каждый читатель может заняться любой интересующей его темой.

Мэтт

11 отзывов3 подписчика

Я считаю, что это сложная книга. В этой книге есть несколько очень необходимых идей, но это не столько «факты и уравнения», сколько точки зрения и парадигмы. Это то, что вы продолжаете читать и обдумывать, пока не «поймете». Вы можете прочитать его и обнаружить, что вы уже на борту, или вам нужно нажать его 5 раз.

Чтобы дать вам пример того, что я имею в виду, большинство программистов на Java, C++ и C#, вероятно, считают себя объектно-ориентированными разработчиками. На самом деле, большинство из них являются разработчиками, ориентированными на «Объект данных», разработчиками, ориентированными на классы, или разработчиками, ориентированными на модули. Эти термины не используются в книге, но если вы чувствуете, что между ними и объектно-ориентированным подходом есть различие, то вы, вероятно, готовы к тому уровню мышления, который описан в этой книге.

Это хорошее чтение, но немного сложное. Это не простое «давайте станем объектным кодером». Это и философское, и методологическое — не самое простое сочетание для большинства разработчиков, но, без сомнения, полезное чтение.

Превосходный исторический обзор истории объектно-ориентированного программирования и Smalltalk, ограниченный практический совет, но несколько полезных приемов проектирования.

Определенно мне захотелось выучить Smalltalk, и мне стало грустно, что я пропустил «золотой век».

Уэст уделяет особое внимание поведенческому аспекту объектов в противовес классическим программным субстанциям процедур и данных. При этом он часто обращается к Алану Кею и использует Smalltalk, поэтому примеры кода в книге сильно отличаются от примеров на Java или C++ (хорошо!). Моя единственная критика авторской концепции объектов заключается в том, что он иногда смешивает подклассы с подтипами, хотя он все еще исследовал различные типы наследования и имеет полностью ориентированный на сообщения взгляд на ООП.

XP — Экстремальное программирование — часто упоминается на протяжении всей книги, хотя раньше я мало что о нем слышал. Похоже, Agile был поглощен Agile, что очень прискорбно, поскольку Agile, к которому мы пришли, очень далек от ориентированных на человека эволюционных целей XP, на которых основывался первоначальный манифест. Представленные здесь методы моделирования и проектирования намеренно упрощены, но, тем не менее, кажется, что их можно улучшить.

В конечном счете, в этой книге рассматривается постмодернистский взгляд на разработку программного обеспечения, основанный на уникальной способности программного обеспечения моделировать посредством метафоры объектов. Это в значительной степени противоречит формальным методам и представлению о том, что компьютеры являются чистой математической областью: лучше адаптировать компьютеры к беспорядочной и сложной природе реальности, чем пытаться подчинить реальность точности компьютера, хотя это кажется все больше и больше направление, принятое в последнее время. Эта книга, опубликованная в 2004 году, пришлась на конец периода объектно-ориентированного ажиотажа, после бурного подъема Java и вызванной ею горы отрицательной реакции, особенно в связи с тем, что Java стремится к стилю программирования, который противоречит объектному мышлению. Smalltalk не умер, но он никогда не вернется к коммерческому успеху, который был достигнут в эпоху, непосредственно предшествовавшую Java (я упоминал, что не люблю Java?) — нам нужны свежие взгляды на ООП, которые облегчают объектное мышление и делают принципиальные перерывы в основной поток данных/процедур/тяжелого синтаксиса C/ALGOL.

объектная технология

Очень интересная и наводящая на размышления первая половина, которая постепенно становится все менее и менее интересной. К последней четверти я просто хотел, чтобы это закончилось.

Я бы не рекомендовал читать ее самостоятельно, потому что наибольшая ценность, которую я извлек из этой книги, заключалась в обсуждении идей первых пяти глав с друзьями.

Джефф

55 обзоров14 подписчиков

Дает хороший обзор мышления в объектах в большей степени в стиле Smalltalk. Имеет хорошее обсуждение истории.

Некоторые интересные идеи, но слишком длинные: как и большинство книг по программной инженерии, ее можно было бы сократить до половины или даже меньше.

Отличная книга, не только техника ООП, но и текст об истории ООП и его философии

ИМХО единственная ДЕЙСТВИТЕЛЬНО хорошая книга об объектно-ориентированном программировании. Изменил свои взгляды и мысли глубоко.

notes/book-object-thinking.md на главной · eoinkelly/notes · GitHub

Автор
считает, что поведение является ключевой концепцией для
1. обнаружение
2. описание
3. проектирование объекты.
ему нравятся карты CRC, а не UML
он не увлекается формализмом
- утверждает, что «поведенческие» подходы к программному обеспечению безразличны к формализму
Объектно-ориентированный дизайн требует мышления, отличного от конструктивного проектирования
OO дизайн отличается культурой

ООП-дизайн имеет идеи о декомпозиции, которые отражают мировоззрение/культуру, отличную от традиционной разработки программного обеспечения. * мировоззрение: совместное использование социальных знаний и моделей поведения

Он считает, что быть гибким разработчиком программного обеспечения или экстремальным программистом — это культурная вещь. * как таковой он должен быть в первую очередь прожит * но книга и может помочь «настроить» вас на это

Формализм против герменевтики-постмодернизма * разные системы ценностей * приводит к разным идеям

Объектное мышление можно реализовать на любом языке программирования метафора и словарный запас играют большую роль в объектном мышлении * метафоры соединяют знакомое и незнакомое * словарный запас позволяет нам думать и общаться

Поведение — главный принцип * не классовые или сущностные отношения * не атрибуты данных и функции-члены (это разные вещи)

Другие книги с таким же видом

Объектно-ориентированный дизайн: Брокс, Вайнер, Уилкинсон
Использование карт CRC: Wilkinson

ДО НАЧАЛА ВНЕДРЕНИЯ

Автор считает, что XP и agile-методы переплетаются с объектным мышлением и каждый требует успеха другого.

«Лучшие люди» признан самой многообещающей серебряной пулей для преодоление кризиса программного обеспечения, и все же почти вся наша энергия была направлена тратиться на создание лучших инструментов, методов и процессов, а не на улучшение люди?»

«Все усилия по продвижению неформальных, повторяющихся, художественных и гуманных способов кажется, что разработка программного обеспечения встречает сопротивление, а затем кооптируется и обесценивается формальными разработка программного обеспечения?»

Выдержка из: Дэвид Уэст. «Объектное мышление (справочник разработчика)». iBooks.

Автор полагает, что руководство убедило руководство в том, что строгие формальные процессы улучшат программное обеспечение

Единственный неизменно надежный подход к хорошему программному обеспечению — это просто хорошие люди.

Промышленность уделяет так много внимания инструментам и процессам, потому что

не знаю, как «обновить» средних разработчиков до хороших разработчиков
распространено мнение, что «хороших» разработчиков недостаточно, чтобы обойти

убеждение в том, что хорошие разработчики «ненадежны» и им нельзя доверять — как правило, «художники»

Agile-методы сосредоточены на отношениях, поведении, культуре и адаптивной эвристике (люди вещи), а не формальные процессы

Цель должна заключаться в подготовке лучших разработчиков, а не в создании лучших программное обеспечение, потому что лучшее программное обеспечение создается лучшими разработчиками.

В большинстве учебников по инструментам и процессам упоминается предостережение о том, что вам нужна группа опытные разработчики, чтобы правильно использовать инструмент.

«опыт — это всего лишь кодовое слово для таких аспектов развития, как философия, отношение, практика, ошибки и даже эмоции — все это нельзя свести к синтаксическое представление и рецептурная формулировка в учебнике»

Оправдание для XP заключается в том, что «мы видели, как мастера-разработчики делают эти вещи. Мы видели, как менее опытные разработчики применяли эти методы и получали лучше», чем любая великая теория

«XP включает в себя устную традицию, которая еще не сведена к чернилам. и бумага (и, возможно, не может быть так сокращена)».

Автор говорит, что большинство книг по ХР предполагают объектное мышление, т. е. они связаны между собой. Можем ли мы объединить объектное мышление с функциональными подходами?

Повсеместное распространение объектно-ориентированных языков НЕ означает, что все овладели объектно-ориентированным мышлением

«Можно привести аргумент, что современное господствующее понимание объектов является лишь бледной тенью первоначальной идеи»

Поведенческий подход к пониманию объектов НЕ распространен * UML рассматривает объекты как «анимированные записи данных» или «мини-программы COBOL»

Smalltalk — язык программирования, наиболее близкий к инкапсуляции поведенческих объектов

Истории против сценариев

Истории всегда рассказываются покупателем и описывают взаимодействия в предметной области
Сценарии (которые являются частью метода CRC), как правило, изображают вещи в области решения

Автор упоминает, что воплощение карт CRC 1990-х годов на самом деле не использовало объектно-ориентированное мышление

ДО НАЧАЛА ГЛАВА 1

В этой книге большое внимание уделяется

мышлению

Сравнение объекта UML и антропоморфных объектов как мыслительных устройств

Структурированное программирование гласит: программа = структуры данных + алгоритмы (+ инкапсуляция черного ящика)

UML моделирует объект как «футбольный мяч» данных, окруженный операциями. Объектно-мыслящие более склонны антропоморфизировать объект

Как «мыслящее устройство» футбольный мяч не фокусируется на поведении — он обращается с объектами как с крошечными программами на языке COBOL

антропоморфизировать = проецировать человеческие характеристики на объекты

Кажется, что «мышление UML» тесно связано с мышлением «дизайна базы данных», где структура данных является руководящим принципом, а нормализация данных — обычной желаемой задачей.

Процесс, через который мы проходим при программировании

 концепция -> декомпозиция -> анализ -> дизайн -> исходный код -> объектный код -> исполнение
[обсуждать вещи в [исключительно области компьютеров]
 язык проблемного домена]

Объектное мышление здесь важно на всех этапах, кроме крайнего левого

В книге делаются большие заявления об объектно-ориентированном мышлении по сравнению с традиционным структурным программированием

метрики SLOC будут на порядок меньше при использовании объектно-ориентированного мышления!!!
в два раза быстрее (или быстрее) доставляют

Нужно будет увидеть что-нибудь, чтобы подтвердить это!

У него также есть некоторые характеристики по размеру объекта

обязанности на класс: в среднем 7
метода на класс: в среднем 12
строки кода на метод: менее 7 для smalltalk, около 15 для C++, Java

Автор говорит, что относитесь к этим цифрам как к приблизительному ориентиру, если вы слишком сильно отклонились, значит, что-то не так

ДО «ДУМАТЬ КАК ОБЪЕКТ» P 59

«Объектное мышление» означает «думать как объект» — в отличие от «думать как компьютер», которым является процедурный код.

Когда мы «думаем как компьютер», мы записываем все шаги, которые компьютер предпримет для решения задачи.

Плюсы/минусы:

++ думать как компьютер интуитивно
++ хорошо работает для простых задач
++ «мысли» компьютеров могут быть довольно большими шагами (состоящими из более мелких шагов)
— если последовательность внешних событий, поступающих в программу, не может контролироваться, то порядок «мыслей» также не может быть известен на самом деле
— если задача требует много разветвлений, человеческий мозг плохо с ней справляется
— если компьютер работает одновременно (или задействовано более одного компьютера), то мы практически не можем рассуждать о порядке, в котором что-то будет происходить в

Многие программы до сих пор написаны в стиле «думай как компьютер»

Эоин: Неясно, учитывался ли здесь функциональный стиль при выражении того, почему объектно-ориентированный стиль лучше, чем процедурный

Java и UML определяют объект как структуру данных + операции — если вы так думаете, то вы не «объектное мышление» — вы занимаетесь «компьютерным мышлением» 🙂

«Суть компьютерного мышления заключается в том, чтобы мыслить средствами решение проблемы. Вы смотрите на каждую проблему развития через призму означает, что вы собираетесь использовать для решения этой проблемы. При разработке, ориентированной на данные, средства решения состоят из отношений и отношений; для Пролога и LISP, набор предложений или деклараций состояний».
Выдержка из: Дэвид Уэст. «Объектное мышление (справочник разработчика)». iBooks.

«Объектное мышление предполагает совсем другое средство решения — сотрудничающее сообщество виртуальных людей. Виртуальный человек — это сущность, способная выполнять определенные задачи».

и виртуальные люди, и виртуальные машины являются метафорами того, как мы думаем о решениях проблемы, но это очень разные метафоры!

Выдержка из: Дэвид Уэст. «Объектное мышление (справочник разработчика)». iBooks.

«Объектное мышление фокусирует наше внимание на проблемном пространстве, а не на пространстве решения.

Выдержка из: Дэвид Уэст. «Объектное мышление (справочник разработчика)». iBooks.

Резюме:

Объектное мышление фокусируется на пространстве проблем, компьютерное мышление фокусируется на пространстве решений
Различные языки имеют разные инструменты в «пространстве решений», например.
- C = процедурные инструменты
- Лисп = ???
- Пролог = набор предложений

Муфта и сцепление

«На практике задачи неоднородны. Они полны узлов и щелей которые имеют четко выраженную структуру. Аналитический процесс терпит неудачу, только если он не учитывает эту структуру. — Кристофер Александер, 1964 г.

искать «естественные соединения» (разделения и классификацию) в проблемном пространстве (как резчик по дереву искал бы в деревянном блоке)

«естественные модули в проблемном пространстве не изоморфны (демонстрация соответствия между контекстом и решением) с обнаруженными модулями и определяется, когда вы думаете о дизайне компьютерной программы».

Он считает, что объектное мышление ищет «естественное» разделение ответственности в проблемном пространстве и что это разделение отличается от того, к которому вы пришли бы, если бы начали с точки зрения «Я собираюсь разработать компьютерную программу».

Он утверждает, что объектное мышление создает в пространстве решений (вашей программе) объекты, которые намного ближе к естественным в пространстве задач, и это очень хорошо!

Экстремальное программирование ценит общение и общий язык между заказчиком и разработчиком

«Мы добьемся успеха, если у нас будет стиль, который прославляет последовательный набор ценностей, которые служат как человеческим, так и коммерческим потребностям: общение, простота, обратная связь и смелость». Это утверждение представляет собой обсуждение Кент Беком ценностей в eXplained eXtreme Programming »9.0003

Объектное мышление способствует этому общему языку (благодаря тому, что объекты в программном обеспечении соответствуют описанным клиентом)

Каждый аспект объектного мышления поддерживает цель общения XP

идентификация объекта и распределение ответственности основаны на структуре предметной области, а не на структуре какой-либо компьютерной программы
- Мир природы сложен, но люди умеют в нем ориентироваться — эти же навыки можно использовать в программном обеспечении
- Объектное мышление приводит к меньшему количеству объектов, которые выполняют меньшую работу
- Сосредоточение внимания на координации автономных объектов вместо контроля и управления модулями и структурами данных также способствует простоте

Объектное мышление ценит быструю обратную связь

Smalltalk был оптимизирован для этого

«Объектное мышление воплощает именно ту смелость, за которую ратовал Кент Бек:
Время от времени у кого-то в команде появляется сумасшедшая идея, что просто может сократить сложность всей системы.

Типы мышления (модель Джерома Брунера)

Предметное мышление и творческое мышление

Object Thinking (DV-Microsoft Professional) Дэвид Уэст

notes/book-object-thinking.md на главной · eoinkelly/notes · GitHub

Сравнение объекта UML и антропоморфных объектов как мыслительных устройств

Процесс, через который мы проходим при программировании

Добавить комментарий Отменить ответ