Smalltalk в примерах/Методы: различия между версиями

Содержимое удалено Содержимое добавлено
Нет описания правки
Строка 1:
Методы содержат код, который выполняется в ответ на присланное сообщение. В отличии от C или C++ в которых могут быть функции не возвращающие значения, в Smalltalk все методы возвращают значение. Если нет явного возвращения переменной, метод должен возвратить <tt>self</tt>, объекту вызвавшему метод.
 
<!--
Строка 21:
==Длина метода==
 
В библиотеке классов VisualWorks, средняя длиннадлина метода равна 7 строкам. Короткий метод хорош тем, что позволяет программисту легко понять, что делает данный метод. Короткий метод также проще использовать заново, и проще переопределить классы-потомки для того, чтобы изменить их поведение. Поэтому хорошая идея определить браузер "стандартного" размера и руководствоваться тем, что все методы должны помещаться в окно браузера. Если метод большой, обычно есть возможность разбить его на меньшие методы с помощью разделения на концепции, которые вы реализовываете, и помещая каждую концепцию в свой метод. Например, длинный метод может разделяться на короткие методы, как в примере:
 
<!--
Строка 43:
-->
 
Имена методов должны говорить о том, что делает метод. Не экономьте буквы; более важна ясность имени, чем его длиннадлина. Программист должен быть способен, посмотрев на метод и прочитав его имя, немедленно сказать, что он делает. Однако, не всегда просто подобрать хорошее имя, когда вы просто смотрите на метод. Оно может прийти на ум, когда вы вызываете метод, посылая ему сообщение. Так что, даже если имя кажется подходящим, пока вы описываете метод, будьте готовы вернуться и исправить имя после использования его в других методах.
<!--
Method names should say exactly what the method does. Don't be stingy with the number of characters; it's more important to be understandable than short. A programmer should be able to pick up someone else's code and immediately know what the method does, just be reading the name. However, it's not always easy to come up with a great method name when you are looking at the method itself. It's when the method is being invoked, when you are doing the message send, that you'll get the best idea of how good the name is. If it makes sense in the context where it is sent, then you've probably got a good name. So, while it's okay to name the method when you are writing it, be prepared to go back and change the name after you use it in other methods.