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

     Да, такая постановка вопроса имеет  рациональное зерно, но все же представляется довольно ограниченной.

1. Программирование помогает лучше формулировать логику решения практически любой задачи (совсем не обязательно чисто вычислительной). Как говорили в старину, "арифметика мозги в порядок приводит".
2. Расширение функциональности готовых программ с неизбежностью требует их более тонкой настройки и адаптации к нуждам конкретного пользователя. Использование методов программирования резко расширяет возможности решения этой задачи.
3. Привлечение для этого профессиональных разработчиков часто просто бессмысленно: сделать самому — быстрее, чем идти в другое крыло здания для общения с коллегами.

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

     

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

Используемая  литература.

1. Информатика, Н.В.Макарова, Л.А.Матвеев, В.Л.Бройдо, Москва 2005.
2. Статья «Поговорим о программировании», А.Колесов.
3. Статья «Об эффективности программ», П.Дворкин.
4. Интернет.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

О критериях эффективности  в программировании.    

 

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

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

     После появления па рубеже 70-х годов  интегральных схем средней, а затем  и большой (БИС) интеграции старая характеристика сложности цифрового устройства по числу используемых в нем диодов и транзисторов потеряла всякий смысл. С другой стороны, если в 50—60-х годах никому и в голову не могло прийти оценивать конструктивную сложность цифрового устройства суммарным числом «ножек» на цоколях всех его ламп или общим числом выводов на диодах и транзисторах, то в 70-х годах оказалось, что общее число активных компонентов уже не имеет решающего значения, а в большинстве случаев более важными параметрами являются количество выводов и число кристаллов.

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

     Совершенно  иная ситуация сложилась в технологии программирования. Критерии эффективности  программ, сформировавшиеся в 50-х годах  для ламповых ЭВМ, с трудом «вытравлялись» из науки и

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

«Во имя эффективности  в программировании вычислений было совершено  больше прегрешений (причем не всегда ее удавалось  достичь), чем по какой-либо другой причине, включая  непроходимую глупость». 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Заключение.

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

     Жесткие рекомендации (что и как надо делать) тут не подойдут, потому что у  каждого человека своя, индивидуальная система внутренних ценностей и мотиваций. Программирование невозможно свести к набору готовых универсальных приемов и рецептов на все случаи, которые достаточно заучить и механически внедрить.

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

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

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

     

     

     Иначе знания, почерпнутые из книг, останутся  мертвой информацией. А чтобы  этого не случилось, постарайтесь осознать самое главное правило программиста:  

исходя  из собственной мотивации, искать творческие идеи по реализации поставленной задачи и применять  их на практике.