Ваши комментарии
Sorry, it won't be accessible until launch, since the whole course is being rebuilt from scratch.
你好！
抱歉，这本书还没有印刷发行。 我计划将来发布硬拷贝版本，但我仍不确定何时会确切实现。 目前，您只能购买数字版本，该版本提供PDF，ePub，Mobi和KFX格式。 购买后，您就可以访问该电子书。
Здравствуйте, Марина!
Да, TypeScript будет в новой редакции курса. Вы сможете перепройти курс на любом доступном языке (пока что их планируется 5: Java, C#, PHP, TypeScript, Python). Но пока что не могу сориентировать по датам выхода, осталось ещё довольно много работы.
Здравствуйте!
Это более близко к книжному формату + интерактивные примеры.
Yeah, that's correct (with a minor correction):
Professor is dependent on Course
Professor is dependent on Student
Hi!
Sorry, it's not yet finished.
Hi!
If first & last names are used internally, that doesn't mean that they would be temporary. Imagine a local variable in a method, say you keep some intermediary value in that variable between the method start and finish. If you convert that variable into a field, that would be a 100% temporary field. Of course, there's no reason to make such a conversion intentionally. However, such a field may be created after several iterations of changes to a method, for example, when the field value becomes no longer relevant in other methods of the class.
Сервис поддержки клиентов работает на платформе UserEcho
Здравствуйте!
Прошу прощения за задержку с ответом! Давайте я попробую расставить точки над «і» и убрать все неточности. Сперва, что касается этого абзаца:
“Агрегация — это специализированная разновидность ассоциации, которая описывает отношения один-ко-многим, многие-ко-многим, часть-целое между несколькими объектами, тогда как ассоциация устанавливает связь только между двумя объектами.”
Думаю, я совершил ошибку, формулируя конец абзаца таким образом. В последней редакции книги я уберу окончание этого абзаца. Я добавил этот фрагмент с целью продемонстрировать смысловую разницу между двумя типами связей, не найдя мысленно примеров множественной ассоциации. Сейчас задался вопросом и нашёл (пример).
Итак, если все три типа отношений — ассоциация, агрегация и композиция — могут быть базово реализованы полем в классе. Как понять что перед вами?
Перед тем как отвечу, хочу сказать, что обычно такой вопрос не возникает, когда вы смотрите на код. Обычно, код создаётся на основании UML диаграммы или другой спецификации, в которой указан тип связи, а не наоборот. Тип связи определяется при проектировании класса, а код пишется уже позже. К примеру, вы получаете на входе спецификацию, в которой кто-то потрудился нарисовать UML-диаграмму, видите там "композицию" и понимаете, что вам нужно сделать "контейнер с управлением жизненным циклом компонентов". Возможно, определение типа связи пост-фактум, как-то может помочь при обсуждении кода, если спеки утеряны или устарели.
Итак, как понять что перед вами, если у вас есть класс, в нём поле-ссылка на другой класс?
1. По-умолчанию, мы думаем что это ассоциация, но делаем несколько проверок, которые могут уточнить тип связи.
2. Если мы можем с определённостью сказать, что один класс выступает контейнером, а второй компонентом, то эту связь можно считать агрегацией. Как это понять? В большинстве случаев, это очевидно. Вы видите класс PageCollection и класс Page – явный контейнер-коллекция и явный для него компонент. В менее очевидных случаях, пытаетесь понять, есть ли между классами здесь отношение часть-целое. При этом, как "часть", так и "целое" могут вполне нормально существовать в программе сами по себе (пустой список страниц vs страница в отрыве от списка). Если определить не выходит, то двигаетесь к следующему шагу, может он это прояснит.
3. Если ли в "контейнере" (класс, который содержит ссылку) мы нашли код управления жизненным циклом компонента, то это связь-композиция.
Надеюсь, этот ответ прояснит для вас вопрос с отношениями. Если что, задавайте вопросы :)