Слабая связь по сравнению с сокрытием информации и простотой [закрытого] изменения
передать в e функцию и использовать
e.stopPropagation ();
<div onClick={() => props.onClick(MenuSection.Default)} > <div <span><InfoIcon /></span> Some info</div> <div>More Info</div> <div>Even more Info</div> <div onClick={(e) => e.stopPropagation();props.onClick(MenuSection.NotDefault)}><InfoIcon /></div> </div>Но я бы также переместил встроенную функцию onClick из метод render и ссылка на него с помощью this.nameOfClickMethod, nameOfClickMethod, конечно же, будет названо по вашему выбору.
10 ответов
Проблемы, которые я вижу с Вашим аргументом номер 2,
Вы предполагаете, что каждое необходимое значение прибывает из экземпляра Сотрудника. Это ни в коем случае не всегда верно. Например, скажите, что необходимо полагать, что финансовое положение компании вычисляет, сколько 'бонусный праздник' дает любому сотруднику. Вы добавили бы информацию о финансовом положении к классу сотрудника, чтобы не изменять подпись?
изменение подписи не обязательно "тяжелее", особенно так в эти дни инструментов, которые выделят каждое место вызова при щелчке кнопки.
И основная проблема с Вашим аргументом номер 1 состоит в том, что он просто не повреждает инкапсуляцию, как все остальные сказали. Вы показываете, что, не, как, который является тем, о чем инкапсуляция.
В конечном счете победы слабой связи. От высокой связи до низкого существуют различные классы связи:
- Содержание, связывающееся (высоко): Один модуль изменяет или полагается на внутренние работы другого модуля
- Связанность общей среды: два модуля совместно используют те же глобальные данные (например, глобальная переменная). Изменение совместно используемого ресурса подразумевает изменение всех модулей с помощью него.
- Внешняя связанность: два модуля совместно используют внешне наложенный формат данных, протокол связи или интерфейс устройства.
- Связь управления: один модуль, управляющий логикой другого, путем передачи его информация о том, что сделать (например, передав флаг what-do).
- Связь штампа (Структурированная данными связь): когда модули совместно используют составную структуру данных и используют только часть ее, возможно другая часть (например, передача целой записи на функцию, для которой только нужно одно поле ее).
- Связь данных: когда модули обмениваются данными через, например, параметры. Каждая данная величина является элементарной частью, и это единственные данные, которые совместно используются (например, передача целого числа к функции, которая вычисляет квадратный корень).
- Сообщение, связывающееся (низко): Модули не зависят друг от друга, вместо этого они используют открытый интерфейс для обмена сообщениями без параметров (или события, посмотрите Передачу сообщений).
- Никакая связь: Модули не связываются вообще друг с другом.
Передача в Employee связь Штампа, которая более связана, чем связь Данных. Если Вы действительно думаете о простоте модификации, слабая связь лучше, потому что у Вас есть меньше для волнения о нежелательных побочных эффектах. Предположим, что Вы хотите изменить структуру Employee класс. Теперь необходимо проверить фактическую реализацию праздничной функции, чтобы удостовериться, что она не повреждает математику.
Лучший наиболее отделенный путь состоит в том, чтобы определить интерфейс IHolidayable, но это - излишество для этой ситуации.
1) Обеспечение параметров не повреждает инкапсуляцию. Это просто показывает, что эти параметры используются для вычисления праздников. "КАК" все еще скрыт в методе.
2) Праздничный метод не должен быть частью класса Сотрудника.
int holidays(Employee emp)
В этом случае только сотрудник может использовать рассматриваемую функцию...
Это не повреждает инкапсуляцию. Повреждение инкапсуляции показало бы внутренние методы, которые это использует для вычисления праздников. Обеспечение стартовых параметров - то, что определяет API.
API мог быть улучшен для разрешения таких изменений - однако, большинство подходов предлагает, чтобы Вы разработали для соответствия требованиям, в настоящее время имеют а не к по дизайну для непредвиденных изменений (дизайн для изменения, но не пытайтесь предсказать изменение). Лучше реализовать то, в чем Вы нуждаетесь теперь и осуществляете рефакторинг позже при необходимости.
По-моему, лучше планировать изменение путем отделения и инкапсуляции максимально как можно больше так, чтобы рефакторинг мог быть сделан максимально легко. Попытка предсказать заранее каждый возможный сценарий заканчивается с чрезмерно увеличенной в размерах сверхразработанной системой.
Я сказал бы, что одно из главных преимуществ слабой связи является простотой изменения. Слабо связанные типы могут измениться друг независимо от друга так, я не понимаю Ваш "по сравнению с" в вопросе.
Кроме того, я не сказал бы, что Вы повреждаете инкапсуляцию путем обеспечения параметров для метода. Можно реализовать a Sum(int a, int b) так или иначе Вы хотите - но необходимо сказать мне (как пользователь) об ожидании двух чисел.
В отличие от некоторых других сообщений я соглашаюсь с Вами, что это повреждает инкапсуляцию. Не инкапсуляция класса, но понятия вычисления праздников. Если Вы хотите измениться, как это вычисление, работы в будущем, и все еще избегают плотного соединения, я предложил бы делать Сотрудника интерфейсом. Если это все еще слишком сильно связывается Сотруднику, потому что Вы думаете, что праздники, возможно, должны были бы быть вычислены для других вещей, то у Вас мог быть интерфейс GetsHolidays, которому наследовался Сотрудник.
Конечно, насколько включенный решение, которое Вы выбираете, должен зависеть от того, как серьезный Вы полагаете, что проблемы связи и инкапсуляции. Я считал бы обоих исходными решениями быть приемлемым во многих ситуациях, сохранить это простым, если это возможно.
Лучший наиболее отделенный путь состоит в том, чтобы определить интерфейс IHolidayable
Этот вид общего оператора действительно раздражает меня. Просто, потому что Вы используете интерфейс, НЕ означает, что Вы автоматически отделяете что-либо. Если Ваш класс сотрудника реализует интерфейс для вычисления праздников, любой код, который называет метод, все еще называет тот же метод. В худшем случае код вызова сделает это прямым доступом к объекту сотрудника, не ссылку интерфейса IHolidayable, в этом случае Вы только сделали ситуацию хуже (потому что существует теперь также более тонкая связь между интерфейсом и любыми классами, которые реализуют его).
Интерфейсы могут действительно помочь с отделением, но они автоматически не делают так, и даже когда они делают, они - не обязательно лучшее решение, чем краткий обзор (или некоторый другой предок) класс.
Это вопрос намерений. Стеки и очереди часто реализуются с помощью массивов и списков, но добавление и удаление элементов более строго определено.
-121--1267640-SDK был выпущен; это первый раз, когда Android SDK следует за выпуском устройства под управлением этой версии.
-121--3732660- Для меня «правильный» ответ сводится к определению высокоуровневого или низкоуровневого API при создании этой функции. Низкоуровневый API ставит гибкость выше удобства для любого конкретного случая и аргументирует int праздники (Дата записи даты, Число продаж)
. Высокоуровневый API предназначен для выполнения одной задачи с максимально возможным удобством для клиента. Это означает, что для int праздников (emp сотрудника) требуется меньший размер шаблона на стороне вызывающего абонента (извлечение даты и продаж из класса Employee) и является менее подробным.
int holidays (IHolidayInfo obj)
Возможно, есть такой способ. В этом случае любой объект, реализующий IHolidayInfo, сможет использовать функцию "holidays". Просто альтернатива.