Вот интересно, сколько русскоязычных из них. А отзовитесь кто-нибудь, из тех кто в этом работает профессионально. Не встречал просто ни разу за годы работы...
Full Throttle — была первой игрой которую мы вдвоем с братом проходили. Одна из самых запоминающихся игр по сюжету. До сих пор собаку и бои на трассе вспоминаем иногда.
Экземпляр Заказ. К нему прикреплен экземпляр Цена, к которому прикреплен экземпляр Скидка, внутри которого метод расчета (возможно ленивый) непосредственного значения скидки. Где именно отвалилась S?
А вот если методы существуют отдельно в разных утилитных классах или сервисах — тогда это уже не объекты в полном смысле, а структуры данных. И получаем анемичную модель, со всеми вытекающими. Уж тогда лучше переходить на функциональное программирование
Мы говорим про скидку. Скидка на что? — на заказ. При этом никто не мешает методу расчета в составе заказа обращаться к другим объектам — например к Журналу заказов, к объекту Доставка и т.п. Давайте не будем устраивать из кода кашу. Никто не говорит что все данные должны быть внутри объекта. Надо все-таки отличать концепцию «объект — это данные и методы работы с этими данными» от «объект — это сущность реального мира». Стараюсь где только можно придерживаться второй концепции.
Конкретно по вашему примеру: в жизни скидка бывает связана с заказом. Нет заказа — нет и скидки. И надо стараться быть «ближе к реальности». Данные заказа однозначно понадобятся для расчета скидки. А вот данные клиента — не факт. Может быть такая ситуация, что большая часть данных для расчета окажутся как раз в классе Клиент (например, скидка покупателям старше 60 лет, плюс куча данных по его бонусам, принадлежности в разным группам и т.п.). Но все равно метод расчета скидки должен быть внутри Заказа (возможно не в самом классе Заказ, а еще в одном классе, связанным с заказом).
Как по мне первый язык должен быть в детском возрасте еще. Честно не могу себе представить себя за джавой как первым языком. Я вот только после Оберона понял насколько много всего лишнего на самом деле в мире ИТ и насколько наш код раздут. Теперь есть, с чем сравнивать. Никита Липский говорил так: «Короче, суть этой басни такова, что в промышленном мире программирования пока не найдено «золотое сечение». B Оберон система — это просто маленький пример, стоящий с обратной стороны, показывающий, что все может быть по другому, чем вы привыкли.»
Сам язык Оберон — результат десятилетий исследований Н.Вирта. Именно поэтому он почти не меняется (сравните с историей создания JS). Компилятор — да — его можно бесконечно улучшать (как впрочем почти любого языка). И вы не поверите — но Обероном пользуются. Когда в ТЗ написаны жесткие требования по безопасности компилятора (например, технологическое оборудование опасных производств), жесткие требования к низлежащему программному обеспечению (операционной системе например) — в котором по требованию не должно быть ничего лишнего (ни одной неиспользуемой функции в коде ни на одном слое!) — то интересно как Вы поступите в этом случае? Возьмете обычную ОС и будете все неиспользуемое выпиливать? Ваша программа должна будет работать на голом железе. А если еще железо редкое? Тут выбор настолько резко ограничивается, что Оберон тут очень даже кстати — его компилятор можно самому доработать под железяку. А если Вы вообще не программист — а инженер? И надо программировать «железо»? И хотелось бы что-то более высокоуровневое без опасности «порезаться бритвой»?
хм… пока дети вырастут и окончат универ, то мейнстрим будет совсем другой. И зачем забивать им голову каким-нибудь тяжелым языком (тем более js слепленным за очень короткий срок), если есть языки, спецификация которых занимает несколько страниц, в котором весь текст кода компилятора и операционной системы влазит в одну книжку, да и то в приложении, с «горячей» заменой модулей. Ну не знаю…
он настолько прост что быть «мертвым» ему не грозит никак. Когда делали Go — то многое из него взяли — но прежде всего простоту. Можете тоже его онлайн попробовать — https://online.oberon.org
Вот интересно, сколько русскоязычных из них. А отзовитесь кто-нибудь, из тех кто в этом работает профессионально. Не встречал просто ни разу за годы работы...
Кстати, есть интересное решение https://parol.martinrue.com/ по преобразованию текста в речь на языке эсперанто. Разработчик его реализовал с помощью библиотеки для другого языка: https://github.com/martinrue
А вот если методы существуют отдельно в разных утилитных классах или сервисах — тогда это уже не объекты в полном смысле, а структуры данных. И получаем анемичную модель, со всеми вытекающими. Уж тогда лучше переходить на функциональное программирование