Когда мы должны создать новый метод?
Я нашел и использовал этот хороший пример моделирования выбранных и опций. Вы можете сделать это, чтобы выбрать все, что вы хотите. Вот как Fiddle
html
css
body {
padding:50px;
background-color:white;
}
.s-hidden {
visibility:hidden;
padding-right:10px;
}
.select {
cursor:pointer;
display:inline-block;
position:relative;
font:normal 11px/22px Arial, Sans-Serif;
color:black;
border:1px solid #ccc;
}
.styledSelect {
position:absolute;
top:0;
right:0;
bottom:0;
left:0;
background-color:white;
padding:0 10px;
font-weight:bold;
}
.styledSelect:after {
content:"";
width:0;
height:0;
border:5px solid transparent;
border-color:black transparent transparent transparent;
position:absolute;
top:9px;
right:6px;
}
.styledSelect:active, .styledSelect.active {
background-color:#eee;
}
.options {
display:none;
position:absolute;
top:100%;
right:0;
left:0;
z-index:999;
margin:0 0;
padding:0 0;
list-style:none;
border:1px solid #ccc;
background-color:white;
-webkit-box-shadow:0 1px 2px rgba(0, 0, 0, 0.2);
-moz-box-shadow:0 1px 2px rgba(0, 0, 0, 0.2);
box-shadow:0 1px 2px rgba(0, 0, 0, 0.2);
}
.options li {
padding:0 6px;
margin:0 0;
padding:0 10px;
}
.options li:hover {
background-color:#39f;
color:white;
}
JS
// Iterate over each select element
$('select').each(function () {
// Cache the number of options
var $this = $(this),
numberOfOptions = $(this).children('option').length;
// Hides the select element
$this.addClass('s-hidden');
// Wrap the select element in a div
$this.wrap('');
// Insert a styled div to sit over the top of the hidden select element
$this.after('');
// Cache the styled div
var $styledSelect = $this.next('div.styledSelect');
// Show the first select option in the styled div
$styledSelect.text($this.children('option').eq(0).text());
// Insert an unordered list after the styled div and also cache the list
var $list = $('
', {
'class': 'options'
}).insertAfter($styledSelect);
// Insert a list item into the unordered list for each select option
for (var i = 0; i < numberOfOptions; i++) {
$('', {
text: $this.children('option').eq(i).text(),
rel: $this.children('option').eq(i).val()
}).appendTo($list);
}
// Cache the list items
var $listItems = $list.children('li');
// Show the unordered list when the styled div is clicked (also hides it if the div is clicked again)
$styledSelect.click(function (e) {
e.stopPropagation();
$('div.styledSelect.active').each(function () {
$(this).removeClass('active').next('ul.options').hide();
});
$(this).toggleClass('active').next('ul.options').toggle();
});
// Hides the unordered list when a list item is clicked and updates the styled div to show the selected list item
// Updates the select element to have the value of the equivalent option
$listItems.click(function (e) {
e.stopPropagation();
$styledSelect.text($(this).text()).removeClass('active');
$this.val($(this).attr('rel'));
$list.hide();
/* alert($this.val()); Uncomment this for demonstration! */
});
// Hides the unordered list when clicking outside of it
$(document).click(function () {
$styledSelect.removeClass('active');
$list.hide();
});
});
19 ответов
Я думаю, что для этого нет конкретных рекомендаций по дизайну. Но некоторые принципы проектирования говорят о создании методов.
СУХОЙ (не повторяйте себя) является руководящим принципом, когда дело доходит до создания метода. Вы группируете подобную логику в одном методе, чтобы не дублировать их по всему коду и, таким образом, сделать обслуживание кошмаром.
Принцип единой ответственности является другим. Это говорит о том, что ваш класс или метод должен делать только одну вещь. Это должно сделать размер метода маленьким.
SLAP и DRY - хорошие принципы. Перейдите по этой ссылке http://tv.devexpress.com/SLAPrule.movie очень приятный разговор г-на Джулиана. [Похоже, что видео-сайт некоторое время не работает. Пожалуйста, проверьте позже]
Вы вводите новые методы, даже если их вызывают только один раз, чтобы ограничить максимальную цикломатическую сложность.
Вдобавок ко всему, я могу перечислить множество причин для извлечения методов и несколько, если таковые имеются, для их объединения.
- Очевидный, DRY, он же DIE . Я следовал этой философии, пока она не стала крутой аббревиатурой. Я не думаю, что когда-либо нужно, по любой причине, дублировать или копировать и вставлять код, независимо от того, насколько он короткий. Если вы это сделаете, вы завариваете кошмар.
- Ограничить цикломатическую сложность . Гораздо лучше иметь 3 понятных метода, чем один запутанный метод. Это правило и другие применимы, даже если новый извлеченный метод вызывается только один раз
- Извлечение единицы функциональности для модульного тестирования
- Чтобы все методы были видны в редакторах без прокрутки
Кстати, я мог бы предложить изменить язык. « Создание нового метода » звучит как добавление чего-либо к коду и его увеличение и усложнение. Но « извлечение метода » - это то, что действительно происходит, когда вы реорганизуете, как мы надеемся, превосходный дизайн. Предполагая, что вы все равно должны иметь эту функциональность, этот метод всегда был там, он был просто похоронен внутри другого ...
Создать метод для выполнения конкретной задачи. Если метод увеличивается в размере, это означает, что у него есть некоторые подзадачи, поэтому выделите (реорганизуйте) подзадачи в новый метод.
Большинство методов должны выполнять одну задачу.
Вы должны почти всегда создавать новый метод при повторении кода.
Он удаляет повторяющийся код и самодокументируется, если вы выбираете доброе имя.
Одна и та же строка кода, встречающаяся в двух местах, не слишком коротка, чтобы сделать метод из нее, если только эта строка не тривиальна и ее намерение не является очевидным.
В конечном счете, вы не хотите повторяться, согласно принципу СУХОЙ (который вы и несколько других людей уже упоминали). Это также зависит от языка, который вы используете. Многие объектно-ориентированные языки делают все эти методы общедоступными (например, Objective-C), поэтому вам нужно создавать только те функции, которые предназначены для вызова другими объектами. С другой стороны, многие языки, такие как Java, предоставляют частные функции, которые поддерживают концепцию группировки блоков кода в частные функции, которые на самом деле не предназначены для использования вне самого класса.
Когда вы начинаете ставить двойные пробелы между блоками кода, чтобы обозначить разные обязанности.
Потренируйтесь в модульном тестировании своего кода и разбивайте методы так, чтобы вы могли тестировать по одному заданию за раз. Это отличный способ сделать всю проблему менее субъективной, имея реальное внешнее ограничение, состоящее в возможности модульного тестирования каждой задачи.
Однажды я услышал, как кто-то сказал, что если метод / функция становится слишком большим, чтобы уместиться на одном экране без прокрутки, то его следует преобразовать в отдельные методы.
Это не всегда верно и нет смысла в рефракторинге для рефакторинга, но часто помогает держать вещи в перспективе.
Если ваши методы очень длинные, имеет смысл перегруппировать их в более мелкие фрагменты, даже если эти фрагменты больше нигде не используются. Это повысит ремонтопригодность и тестируемость. Кроме того, с этим подходом вы позволяете другим разработчикам более легко расширять ваш код на случай, если они захотят изменить определенные обязанности метода, например, перегружая его.
Что касается геттеров и сеттеров, то это зависит от того, какой язык вы используете. В некоторых языках это может быть довольно многословно. Лично я предоставляю геттеры и сеттеры только для открытых свойств и / или если изменение свойства связано с логикой, а не просто установкой / получением свойства.
В дополнение к превосходному ответу Гравитона , я рекомендую еще одно практическое правило, чтобы решить, когда создавать новый метод:
Всякий раз, когда вы чувствуете, что хотите написать комментарий к части кода, вместо этого переместите этот код в выделенную функцию. Дайте описательное имя для функции.
Я думаю, что это очень субъективный вопрос без реального ответа. Различные ситуации требуют разных решений, и не будет единого рецепта «когда создавать новый метод». Это зависит.
Метод должен делать одну вещь и делать это хорошо. Он не должен делать ничего более или менее того, что подразумевает его название. Метод CustomerSave также не должен нормализовать адрес клиента.
Метод должен касаться только одного «уровня» функциональности. Если в методе CustomerSave появляется более одной строки кода для каждого из следующих действий: открытие базы данных, регистрация изменений, проверка безопасности и т. Д., Тогда код работает на неправильном уровне, и должны быть созданы новые методы для работы с эти вещи в надлежащей детализации.
Метод обычно должен быть очень коротким. Только при особых обстоятельствах метод должен распространяться на более чем один экран. Если метод длиной в сто строк, то что-то очень, очень неправильно.
Кодекс не должен быть повторяющимся. Двойная функциональность должна быть помещена в метод.
Методы должны быть разработаны таким образом, чтобы можно было легко вносить типичные изменения. Если небольшое изменение необходимо внести в десятки мест, то это сигнализирует о повторяющемся коде, который должен быть размещен в одном методе.
Посмотрите Чистый код Роберта Мартина, который охватывает это (среди прочего)
Возможно, вы захотите извлечь метод, если:
- есть блок комментариев для чанка
- , который вы можете назвать намерением чанка
Интересный момент, хотя и не связанный с объектно-ориентированным программированием, сделан в руководстве по стилям кодирования linux :
Глава 4: Функции
Функции должны быть коротко и сладко, и делаю только одно. Они должны помещаться на один или два экрана текста (размер экрана ISO / ANSI составляет 80x24, как мы все знаем), и делать одно, и делать это хорошо.
Максимальная длина функции обратно пропорциональна сложности и уровню отступа этой функции. Таким образом, если у вас есть концептуально простая функция, которая представляет собой всего лишь одну длинную (но простую) инструкцию для случая, когда вам приходится делать множество мелких вещей для множества различных случаев, то нормально иметь более длинную функцию.
Однако, если у вас сложная функция, и вы подозреваете, что менее одаренный ученик первого года старшей школы может даже не понять, о чем эта функция, вам следует придерживаться максимальных пределов, тем более тесно. Используйте вспомогательные функции с описательными именами (вы можете попросить компилятор включить их в строку, если вы считаете, что это критично для производительности, и он, вероятно, справится с этим лучше, чем вы бы сделали).
Другой мерой функции является количество локальных переменных. Они не должны превышать 5-10, или вы делаете что-то не так. Переосмыслите функцию и разбейте ее на более мелкие части. Человеческий мозг, как правило, может легко отслеживать около 7 различных вещей, что угодно, и это запутывается. Вы знаете, что вы великолепны, но, возможно, вы хотели бы понять, что вы сделали через 2 недели.
Я считаю программирование искусством. Таким образом, я разделяю методы, когда считает правильным разделить их или написать новый.
Тем не менее, есть некоторые правила большого пальца (которые не отменяют мои инстинкты).
- Если вам нужно прокрутить экран, чтобы прочитать один метод, вам нужно разделить его
-
ЕСЛИ у вас есть deja vue (код, который вы пишете, кажется знакомым), вы, вероятно, повторяетесь Это означает, что вы должны использовать существующую функцию / метод, а не писать новую.
-
Не более двух глубоких конструкций
для (...) для (...) для (...) ПЛОХОЙ
-
Нет более одной петли подряд (одна за другой).
- Если вам нужно вернуть более одного типа данных (нулевой / ложной версии нет), вам нужно что-то разделить.
- Если вы запутались при чтении вашего метода - разбейте его
- Метод / функция должны отвечать за одну задачу.
- Самое очевидное - при написании новой функциональности: -)
Методы получения и установки ООП не являются, и чаще всего просто удваивают размер кода, но это бесполезно.
что касается книг: паттерны проектирования (Gamma, Vlissides, Johnson, Helm), книги Фаулера (рефакторинг, шаблоны архитектуры корпоративных приложений), книги Бека (разработка через тестирование на примере, шаблоны реализации) и т. Д.