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.