Smalltalk в примерах/Объектно-ориентированное мышление
Смолток это один из чистых объектно-ориентированных (ОО) языков. В отличие от C++, который очень легко позволяет писать процедурный код (т.е. использовать C++ как улучшенный C), в Смолтоке трудно писать процедурный код. Мышление объектами очень отличается от мышления в процедурных терминах и обычно требуется 8-12 месяцев для знакомых с процедурным программированием чтобы начать довольно свободно мыслить объектно-ориентированно. При использовании языка, который не помогает этому процессу, становится более лёгким нахождение в полушизофреническом состоянии.
Маленькие шаги править
В силу того, что Smalltalk позволяет легко модифицировать код, итеративный подход при написании программ становится самым естественным. Когда я сталкиваюсь со сложной задачей, я обычно не знаю как я её решу. Я трачу некоторое время на анализ и проектирование, чтобы понять проблему, но я редко получаю полное решение сразу. Таким образом, я просто начинаю и пишу Smalltalk код. Процесс написания кода, создания классов и описания взаимодействий, даёт мне более глубокое понимание задачи и её решения. Это понимание в свою очередь позволяет мне написать ещё немного кода, чтобы проверить новые идеи, а новое написание даёт новое понимание и т.д. ---
\begin{figure}[!htb]
\begin{center}
\includegraphics{cykl.eps}
\end{center}
\caption{Цикл разработки объектно ориентированной программы}
\label{cykl}
\end{figure}
Описывай концепции править
Очень просто писать, тестировать и изменять код в Смолтоке. Эта простота написания позволяет тебе осуществлять замысел в коде, думая о концепциях вместо того чтобы беспокоиться о деталях (какая разница между разработкой и реализицией).
MyClass>>doSomething self myDoConceptualThingOne. self myDoConceptualThingTwo. self myDoConceptualThingThree
MyClass>>doSomethingWith: anObject self myDoConceptualThingOne. anObject doConceptualThingTwo. self myDoConceptualThingThree. self myDoConceptualThingFour
Откладывай работу править
В силу того что хорошие методы в Smalltalk малы, очень тяжело сделать много работы в таком методе. Это приводит нас к следующему принципу объектно ориентированного подхода в Smalltalk: откладывайте работу так долго, как только это возможно -- создайте другой метод, выполняющий её. Простота написания Smalltalk кода даёт возможность отложить реальную работу на потом, и большинство методов будут всего лишь разделять эту работу. Конечно кто-то должен в конечном итоге сделать работу, но если вы отложите ее на самый конец, вы получите более объектно-ориентированную систему.
MyClass>>myDoLoop [object := self mySharedQueue next, object isHeartbeat ifTrue: [self myHeartbeat: object], object isSuccessResponse ifTrue: [self mySuccessResponse: object], object isFailureResponse ifTrue: [self myFailureResponse: object] ] repeat.
MyClass>>myDoLoop [object := self mySharedQueue next, self myProcessObject: object ] repeat.
MyClass>>myDoLoop [self myProcessObject: self myGetObject] repeat
MyClass»myGetInput ^ self mySharedQueue next.
Говори, не спрашивай править
\potom
MyClass»myProcessObject: anObject anObject processYourself
MyWindow>>displayObj ect: aGraphicalObj ect aGraphicalObject isSquare ifTrue: [self myDisplaySquare: aGraphicalObject]. aGraphicalObject isCircle ifTrue: [self myDisplayCircle: aGraphicalObject]. aGraphicalObject isTriangle ifTrue: [self myDisplayTriangle: aGraphicalObject].
MyWindow»displayOb j ect: aGraphicalOb j ect aGraphicalObject displayYourselfOn: self
Не проверяй результатов выполнения править
\potom
Главное в объектно ориентированном мышлении править
Короткие методы править
Средняя длина метода в Смолтоке семь строк. Я всегда придерживаюсь правила что методы должны помещаться в окно браузера и я очень редко нарушаю это правило. Если метод слишком длинный, я попытаюсь найти две или три концепции которые он выполняет, и создам отдельные методы для каждой из них. Соответственно если у тебя есть методы которые не помещаются в окно браузера, ты возможно думаеш процэдурно. (\potom)
Не слишком плотные методы править
Другим индикатором того что твои методы делают очень много является то что они выглядят очень чёрными. Это эстетический критерий, но он помогает эвристически определить что ты пытаешься сделать очень много в одном методе. Пытайся сделать методы глупыми. Метод глупый если очень просто определить что он делает; его не нужно документировать. Чёрные методы обычно являются противоположностью глупым методам, больная плотность говорит о том что в одном методе делается много вещей.
Объекты без супер-интеллекта править
Нет правила о том сколько методов должен иметь объект, но есть несколько эстетических критериев которые ты можешь принять. Если ты увидишь, что у некоторого объекта много больше методов, чем у других, возможно ты распределил объём работы неудачно. В хорошей объектно-ориентированной системе, ты не должен иметь супер-интеллектуальных объектов. Вместо этого, у тебя должно быть много равнозначных взаимодействующих объектов. Супер-интеллектуальные объекты часто показывают, что ты думаешь процедурно (в известном смысле процедурная система это один супер-интеллектуальный объект). Возможно пришло время пересмотреть твои объекты, если у тебя появились классы с неравным распределением методов между ними.
Отсутствие объектов администраторов править
Очень просто создать систему с объектом администратором который говорит другим объектам что делать. Хорошая объектно-ориентированная система имеет тенденцию состоять из набора равных взаимодействующих объектов, с довольно равным распределением обязанностей и объёмом работы. Объекты-администраторы имеют тенденцию принимать решения, которые могут принять другие объекты. Если у тебя есть класс имя которого заканчивается на Администратор (Manager), возможно Вам следует подумать о том, как распределить его задачи между объектами, которыми он управляет.
Объекты с ясными ответственностями править
Каждый класс должен иметь ясную ответственность. Если ты не можешь выразить назначение класса в одной ясной фразе возможно твоя структура классов нуждается в пересмотре.
Не очень много переменных экземпляра править
Если в классе много переменных экзэмпляра возможно этот класс пытается сделать слишком многое, т.е. ты распределил объём работы неудачно. Возможно удастся создать другие объекты которые могут выполнять вспомогательную роль или сотрудничать с объектами даннова класса.
Начало использования объектно ориентированного мышления править
Может быть трудно начать думать в терминах объектов, если некоторое время ты программировал на процедурном языке. Один подход, который я нашел очень удобным - это изучать Смолток и объектно-ориентированное программирование, работая в паре на одном компьютере. Одна клавиатура, один монитор - два человека. Один набирает код, другой дает советы, задает вопросы и указывает на ошибки. Затем они меняются ролями и другой человек набирает код. При таком подходе ты ---. Проектировать лучше при помощи другого человека из-за того, что он задает вопрос "почему?" и предлагает альтернативные решения. В коде получается меньше ошибок из-за того, что кто-то другой просматривает код. Код обычно получается более эффективным, maintainable и последовательным. Из-за того, что второй человек просматривает весь код, ---.
Т.к. два человека работают над всеми возможностями, ты получаешь два человека которые понимают код вместо одного. И оба человека читают код друг друга. У программистов есть свой собственный стиль, техника и стандартные решения. При работе в паре, они изучают эти вещи друг у друга и растут как программисты. При периодической смене партнёров, эти техники и решения переходят от человека к человеку, и как результат каждый человек учится у тех с кем он работал раньше.
Когда я начал программировать на Смолтоке, я работал с другим разработчиком в паре. Это было большим удовольствием и мы оба учились многому друг у друга. \potom.