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.


Объект →