Пояснение необходимо для подхода «Спроси, не говори»

Question

Я занимаюсь курсом по шаблонам в разработке программного обеспечения, и здесь я пытаюсь понять хороший и плохой способ проектирования, связанный с «сцеплением» и «сплоченность». Я не мог понять концепцию, описанную на следующем рисунке. Пример кода, показанного на изображении, неоднозначен для меня, поэтому я не могу точно понять, что именно «Спросите, не говорите!» подход означает! Не могли бы вы получить что-нибудь из изображения? Если да, пожалуйста, объясните!

Благодаря

Answer 1

С первой реализации клиент код класса высоко в сочетании с реализацией, так как тот факт, что список студента осуществляется с SortedList какой-то утечка. Как только класс используется из сотен других мест, изменение его внутренней реализации от SortedList к чему-то другому становится трудным или невозможным. Вторая реализация скрывает детали реализации, что приводит к ослаблению связи.

Я считаю, что этот принцип более известен как the law of Demeter. Я никогда не слышал, чтобы это описывалось как «спросить, не говорите».

Answer 2

Мы понятия не имеем, что такое тума, но это нормально; это не имеет значения. Важно то, как вы взаимодействуете с ним (какие у него методы). Для иллюстративных целей предположим, что опухоль относится к типу X.

В плохом примере нам нужно получить SortedList от tum и начать работу с SortedList. Это плохо, потому что вы сильно сцепляетесь с типом X с SortedList. В будущем вы можете не захотеть использовать SortedList (или его подкласс). Если вы измените X, чтобы использовать массив, базу данных, веб-сервер или что-то еще, у вас будет много потенциальных проблем:

1. Вы должны изменить код в любом месте, где вы добавляете ученика. Для небольшого проекта это может быть всего лишь несколько мест. Для более крупных проектов это можно использовать в сотнях мест и может стать головной болью для изменения.
2. Если вы раскрываете тип X в качестве библиотеки для использования другими пользователями, любой, кто использует X, должен будет обновить свой код. Люди, использующие вашу библиотеку, могут быть очень расстроены, если им приходится обновлять свой код во многих местах.
3. Скажем, SortedList изменения и методы добавлены или удалены (вряд ли с SortedList, но возможно, если это был другой класс, который вы сделали). Вам нужно будет обновлять каждое место, добавляя ученика, даже если вы только меняете структуру данных о том, как учатся студенты.

В лучшем примере addStudentToLecture (...) скрывает детали реализации. Он может использовать SortedList, иначе это может быть что-то другое. Любой, кто хочет добавить ученика к курсу, не должен знать, как использовать SortedList, и реализация addStudentToLecture (...) может измениться без изменения кода вызова.

Answer 3

В первом (или плохом) примере вы сообщите что делать.

Вы излагаете детали того, как добавить ученика к лекции. Несколько вещей не так с этим. tum возвращает внутреннюю деталь реализации как изменяемый объект. Клиент может возиться с ним, возможно, нарушая инварианты класса tum. Возможно, это самый большой недостаток. Кроме того, вы также зависеть от деталей о том, как получить список учащихся и о том, как добавить ученика. Если какая-либо из этих деталей изменится, ваш код разбивается ...

Во втором вы не сообщаете как это сделать. Вы вместо этого спроситеtum, чтобы выполнить эту работу за вас, но вы не укажете подробности, как это сделать. Это также означает, что, если какая-либо из этих деталей реализации изменится, ваш код все еще в порядке; реализация tum может измениться независимо.

Надеюсь, это поможет.