Как отличить состав и самонастраивающиеся прецеденты

Scala имеет два инструмента для выражения композиции объекта: оригинальную концепцию самонаведения и известную тривиальную композицию. Я любопытно, в каких ситуациях я должен использовать это.

Существуют очевидные различия в их применимости. Самостоятельный тип требует использования признаков. Состав объекта позволяет изменять расширения во время выполнения с объявлением var.

Оставляя технические детали, я могу представить два показателя, чтобы помочь в классификации вариантов использования. Если какой-либо объект используется как комбинатор для сложной структуры, такой как дерево, или просто имеет несколько аналогичных типизированных частей (соотношение между 1 автомобилем и 4 колесами), то он должен использовать композицию. Существует крайний противоположный случай использования. Предположим, что одна черта становится слишком большой, чтобы четко ее наблюдать, и она раскололась. Вполне естественно, что для этого случая вы должны использовать self-types.

Эти правила не являются абсолютными. Вы можете сделать дополнительную работу для преобразования кода между этими методами. например вы можете заменить 4 состава колес на самонабор по продукту4. Вы можете использовать Cake[T <: MyType] {part : MyType} вместо Cake { this : MyType => } для зависимостей шаблона торта. Но оба случая кажутся противоречивыми и дают вам дополнительную работу.

Есть много случаев использования границ. Отношения "один-к-одному" очень сложно решить. Есть ли какое-то простое правило, чтобы решить, какая техника предпочтительнее?

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

Как я могу выбрать между ними? Какие намеки есть?

Update:

Обсудим следующий пример:

Шаблон адаптера. Какие преимущества у него есть как при наборе текста, так и в композиционном подходе?

Ответ 1

Ниже перечислены подсказки, основанные на эвристическом подходе (метод проб и ошибок решения проблемы, когда алгоритмический подход непрактичен) и не поддерживается какой-либо формулой (математическое обоснование).

*** Подсказки, данные здесь, должны оцениваться со ссылкой на сопровождающие подсказки, никакая подсказка не является идеальным правилом для различения композиций и самонастраивающихся прецедентов.

(Если следовать приведенным ниже советам, мне все равно или сосредоточиться на многословии или количестве строк ввода кода или программирования.)

состав (значение словаря): акт объединения частей или элементов для формирования целого (тривиальная композиция)

(значение словаря): отличительная характеристика или качество

Советы для тривиальной композиции (что может быть достигнуто с помощью механизма супер-подкласса или отношения ассоциации) (например, Car and Wheels):

  • Что можно считать дискретно (например, колеса)

  • Который может быть классифицирован далее (на основе разных критериев) (например, колеса - легкосплавное колесо, стальное колесо и т.д.)

  • Что можно добавить или удалить (Примечание: Когда мы говорим, что колесо остановлено, на самом деле скорость вращения колеса прекращается, когда мы говорим, что сердце остановлено, на самом деле пульсация сердца пульсации стала нулевой)

  • обычно применим к нескольким (во вселенной Некоторые транспортные средства и некоторые механизмы имеют колеса) (немногие могут быть 10-15 или миллионы также. Чтобы объяснить, давайте понимать утверждение: когда геолог говорит о времени и говорит некоторое время назад, это означает несколько миллионов лет назад, это зависит от фактического предмета)

Подсказки для типа Self (черта) (например, автомобиль и скорость):

  • Что является одномерным (не с точки зрения физики), может быть нанесено на цифровую строку (независимо от физической единицы) (например, скорость)

  • Невозможно классифицировать дальше (например, скорость) (или, по крайней мере, вы не будете классифицировать его дальше). Здесь, естественно, слово, используемое для передачи значения, которое следует классифицировать, должно зависеть от ваших собственных критериев и будет определенная возможность классифицировать его на миллионы подтипов. Возьмите движение, у вас могут быть миллионы движущихся поднаборов... как зигзагообразный ход, поворот и продвижение вперед,... (миллионная возможность с различными комбинациями перестановок).

  • Который может быть увеличен или уменьшен или остановлен (например, скорость, гнев, любовь и т.д.)

  • Что обычно видно/можно увидеть в очень отдаленных классах (например, скорость света, скорость земли, скорость бегуна)

  • как правило, применим ко многим (в большинстве случаев все (каждый) объект имеет скорость)

    Разработка программного обеспечения похожа на создание вашей собственной вселенной, и как создатель вы все определяете. Титма будет видна среди дистанционно расположенных классов в вашем домене (ваша собственная вселенная).

Обратите внимание, что я не видел ни одного конкретного слова (здесь, аналога для черты) на любом языке (я знаю очень мало) для части, которая используется для тривиальной композиции.

Дальнейшее объяснение:

Чтобы получить ответ, вам нужно найти где-то глубоко в философии ориентированной на классы или объектно-ориентированной афоры разработки программного обеспечения, и нужно понимать ум и логику создателей языков программирования, таких как java и scala (или многие другие), которые внедряли ориентированную на классы или объектно-ориентированную парадигму в пределах этого языка.

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

Я считаю, что когда мы создаем класс, мы хотим воплотить реальный мир в программное обеспечение. Класс становится представлением чего-то из реального мира, может быть, это автомобиль, человек, звезда, сон, мысль или воображение и т.д.

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

Когда кто-то скажет "Скорость", у вас не будет четкой картины его... нет формы... нет цвета... но вы можете связать ее с какой-либо движущейся (относительной) частью во вселенной. Это характерная черта. Скорость не является частью чего-либо. Он может быть там, или он не может быть там. Он может быть нанесен на одну строку (в любом направлении + или -). Трудно классифицировать "Скорость". Скорость, подобная вещам, соответствует признаку.

По-моему,

Если мы возьмем Car как класс (Object), характеристики "Speed", как характеристики, должны стать чертой в scala. И "Колесо", как части, компоненты должны входить как "Тривиальная композиция". Характеристики "скорости" не будут иметь естественной классификации, где "Колеса" могут иметь много классов, и они сами являются независимыми объектами (в действительности).

Если мы возьмем Человека как класс (Oject), "Гнев, плач, смех и т.д." как поведение должно идти как черта и "руки, ноги, мозг, сердце и т.д." должны входить как "Тривиальная композиция", поскольку они сами являются независимыми объектами (на самом деле).

Если мы думаем о названии, то это может быть дано чему угодно и любому, т.е. наша ближайшая звезда имеет имя "Солнце", самая высокая гора имеет имя "Гималаи", моя собака имеет название "Рокки", у реки есть имя "Амазонка".... "Имя" является признаком и не следует рассматривать для "Тривиальной композиции".

Если мы думаем о сердце, у животных есть сердце в их роли. Он должен рассматриваться для "тривиальной композиции", а не как черта.

Что такое класс?

Класс - это описание или синяя печать конкретного объекта.

Что такое объект?

Объект - это реальность, которая может быть описана определением класса.

(Яйцо или курица? Кто пришел первым?) Я считаю, что сначала инженер-программист думает об объектах, а затем (чтобы описать их или сделать их) (из плана) определяет класс. (Обратите внимание, что в объектно-ориентированном моделировании и дизайне - класс и объект дополняют друг друга.) ( "Яйцо или курица? Кто пришел первым?" Для сосуществования класса и объекта и не имеет никакого отношения к знаменитому Кругу-Затмению Проблема (http://en.wikipedia.org/wiki/Circle-ellipse_problem), поскольку позже она связана с наследованием или политипом подтипа.)

интерфейс: вещь, позволяющая эффективно и эффективно выполнять отдельные и иногда несовместимые элементы

Разработка программного обеспечения похожа на создание вашей собственной вселенной, и как создатель вы все определяете. Композиция должна быть предпочтительной по сравнению с Наследованием. ( "Банда четырех моделей" )