Це запах коду, якщо приватний метод викликає загальнодоступний?

Чи викликає запах коду загальнодоступний метод в приватному методі того ж об'єкта екземпляра?

Ніякого неприємного запаху. Це може знадобитися, чому ви підозрюєте, що це неправильно? Метод на атомному рівні - це незалежна сутність, яка виконує завдання. Поки він виконує завдання, кожен, хто має доступ до нього, може зателефонувати, щоб виконати завдання.

Кодовий запах? Так, не дуже поганий, але хороший показник того, що клас може мати занадто багато обов'язків.

Прийміть це як знак того, що клас може бути розбитий на різні об'єкти, приватні методи не повинні дійсно викликати публічні методи одного і того ж об'єкта, звичайно, в чистому дизайні ОО.

Звичайно, після того, як ви ознайомитесь з класом і причини виклику методу зрозумілі, це може бути цілком розумним використанням, як правило, ви очікуєте, що корисні методи класу будуть приватними, але якщо один досить корисний, щоб бути загальнодоступним та використовуватися іншими методами, я б, як правило, очікував, що ці методи також будуть публічними.

Як і у всіх запахах коду, це є мотивацією для подальшої перевірки коду, раціоналізації та, можливо, рефактора, але не є причиною тривоги.

Це може призвести до неприємних сюрпризів, якщо хтось, хто не прочитав вихідний код цього класу, намагається підкласифікувати його і замінити відкритий метод. Чи справді це справді хвилює, очевидно, залежить від вашої ситуації. Можливо, вам варто подумати про те, щоб зробити загальнодоступним метод або навіть підсумковий клас.

Я не думаю, що ми можемо генералізувати.

Все дуже сильно залежить від контексту.

Можливо, скажімо, метод публічної корисності в класі, який використовують інші класи, а також якийсь приватний метод того ж класу.

Ні. Що ще слід зробити в цьому випадку? Зробити приватний метод загальнодоступним чи публічний метод приватним? Скопіювати-Вставити код із загальнодоступного методу в приватний?

НІ , тут неприємного запаху.

якщо ми реалізуємо інтерфейс черги зі списком, чи неприємний запах просто викликати належні функції списку, щоб легко досягти реалізації черги?

якщо у вас є щось, і ви хочете перетворити це на щось інше (наприклад, обгортку), тоді його неприємний запах, його повторне використання коду з дизайнерським малюнком, що діє на рівні функцій (це функція об'єкт?)

Я знаю, що це стара публікація, але це щось, про що я дискутував на роботі. Я "вважаю" це кодовим запахом, і не можу зрозуміти, чому б вам хотілося це робити. Якщо приватний метод повинен викликати загальнодоступний метод, то зміст публічного методу слід приймати і розміщувати в приватному методі, який потім можуть викликати обидва методи. Чому?

1. Загальнодоступний метод може містити тести, які не потрібні, коли ваш внутрішній код виконуватиметься. Він може отримати UserObj і, наприклад, перевірити дозволи користувача.

2. Після публічного дзвінка у вас може виникнути вимога заблокувати об'єкт, якщо ви користуєтеся потоком, так що внутрішньо, ви не хочете передзвонити до публічного методу.

3. На мою думку, більше шансів ввести кругові помилки та нескінченні петлі та поза винятками пам’яті.

4. Простий і просто, поганий дизайн і "ледачий". Публічні методи забезпечують доступ до зовнішнього світу. Немає підстав ходити на вулицю, коли ти вже знаходиться всередині.

Уявіть навпаки. Ви користуєтеся приватним методом і вам потрібна функціональність у відкритому методі Що робити, якщо ви не змогли викликати цей публічний метод із приватного. Що б ти зробив?

• Створити дублікат приватного методу? Ні
• Створити спеціальний публічний метод на випадок? Ні
• Викликати спеціальний приватний метод, який може викликати загальнодоступні методи? Ні
• Якийсь супер, який може це зробити? Ні

Відповідь чітко полягає в тому, що, коли ви хочете функціонувати в загальнодоступному методі, ви повинні мати можливість викликати цей метод з методів цього класу або з інших класів.

У своєму коді я часто створюю ледачі навантажувачі, тобто об'єкт ініціалізується під час першого запиту, а потім повторно використовує той самий інстанційний об'єкт. Однак об'єкт, інстанційний за допомогою ледачого навантаження, означає, що він не обов'язково може бути інстанційним у будь-якій заданій точці. Замість того, щоб обернути голову навколо послідовності дзвінків, щоб я знав, що цей об'єкт вже інстанціюється або повторюється той самий код ледачого навантаження в іншому методі, я просто викликаю ледачий завантажувач, коли мені потрібен цей об'єкт.

Так само як ви можете використовувати публічні методи розумним чином, ви також можете використовувати їх неправильно. Прикладом цього може бути публічний метод, який обробляє його параметри перед тим, як викликати інший приватний метод. Було б помилкою називати цей публічний метод випадково просто тому, що у вас однакові параметри. Помилка є тонкою, але це помилка дизайну більше, ніж усе інше, і вимагає, щоб ви навчилися керувати параметрами внутрішнього методу, а не параметрами публічного методу.

Отже, щоб відповісти на ваше запитання, звичайно, це не поганий код, якщо ви правильно його використовуєте.

Питання, яке вам потрібно задати собі, це чому ваш клас має таку ж потребу, як і клієнти вашого класу? Зазвичай клас має дуже різні потреби від своїх клієнтів. Так що так, це ознака того, що у вас є будь-яке

(a) викрити щось публічно, що повинно бути приватним; або

(b) поведінка класу недостатньо вузька (продумайте принцип єдиної відповідальності).