Как стать автором
Обновить

Комментарии 14

> Почему в результате умножения 3-х яблок и 4-х корзин, получается 12 яблок, а не 12 корзин, или 12 яблоко-корзин?

не надо людей путать корзинами. здесь правило общее, а не какое-то исключение.
Умножаются 4 (корзины) на 3 (яблока-в-корзине) получается 12 корзина * яблоко / корзина = 12 яблок
А не яблоко-корзины
НЛО прилетело и опубликовало эту надпись здесь
Все это будет, но через статью. Сначала разберемся с простыми кейсами: типами и классами, затем с существительными и глаголами, и лишь потом про числа.
3 Ампера * 4 Вольта = 3 Ампера * 4 (Ампера*Ом) = 12 Ампер-квадрат*Ом = 12 Вт.

Эх. Раскладываем единицы измерения:
Ампер * Вольт = А*Дж/Кл = А*(Н*м)/(А*сек) = Н*м/сек = ((кг*м/сек^2)*м)/сек = кг*м^2/сек^3
НЛО прилетело и опубликовало эту надпись здесь
За что обожаю систему СИ, так это за множество возможных интерпретаций казалось бы давно знакомых понятий.
Верно. Но в школе нам объясняли именно так: яблоки умножались на корзины.
Например, есть мнение, что класс в ООП – это модель множества. Но увы, — это модель типа объектов, но не модель множества.

А ведь, пожалуй, это пример нарушения принципа Single Responsibility.
Класс это — тип объектов. Но некоторые особенности класса (например, возможность определения статического поля, доступного для объектов — экземпляров класса) позволяют, пусть и с ограничениями, использовать его для моделирования множества объектов.
Налицо смешение в одной сущности двух обязанностей.


И если в базовой конструкции ООП допускается эта ошибка, становится понятным, почему, несмотря на то, что в мире ООП много говорят о базовых принципах — SOLID, на практике не соблюдают эти принципы:
с одной стороны, в фундаментальных конструкциях есть изъяны (что уже само по себе!),
с другой — несмотря на то, что эти изъяны можно обойти, само их наличие провоцирует прикладных программистов нарушать базовые принципы (если на более серьезном уровне можно нарушать, то и на прикладном уровне можно).

Например, есть мнение, что класс в ООП – это модель множества.

Это мнение только автора статьи.


Но некоторые особенности класса (например, возможность определения статического поля, доступного для объектов — экземпляров класса) позволяют, использовать его для моделирования множества объектов.

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

Мнение о том, что класс в ООП — это модель множества, не мое.
Я лишь пересказываю те мнения, которые я встречаю.
Например, класс в ООП почему-то упорно именуют объектом, например, чашкой, а не типом объектов, а объект почему-то упорно называют «экземпляром этой чашки», а не «чашкой».

Не надо пропускать слова, тогда и не будет путаницы. Класс чашек именуется "класс Чашка", а не просто "Чашка". Сами объекты (чашки) именуются "экземплярами класса Чашка".

Если надо указать на объект класса чашек, надо сказать: элемент класса чашек, а не экземпляр

Элемент может быть у множества, а не у типа.

Экземпляры класса чашка по определению русского языка — есть классы чашек, а не чашки.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.