Я вижу преимущества создания неизменных объектов в моей программе. Когда я действительно глубоко задумываюсь над хорошим дизайном для своего приложения, я часто, естественно, считаю, что многие из моих объектов неизменяемы. Часто приходит момент, когда я хочу, чтобы все мои объекты были неизменными.
Этот вопрос касается той же идеи, но ни один ответ не говорит о том, что является хорошим подходом к неизменности и когда на самом деле его использовать. Есть ли хорошие шаблоны дизайна? Общая идея, по-видимому, заключается в том, чтобы «сделать объекты неизменяемыми, если вам абсолютно не нужно их менять», что на практике бесполезно.
Мой опыт показывает, что неизменность все больше и больше приводит мой код к функциональной парадигме, и такое развитие всегда происходит:
- Я начинаю нуждаться в постоянных (в функциональном смысле) структурах данных, таких как списки, карты и т. Д.
- Работать с перекрестными ссылками крайне неудобно (например, узел дерева ссылается на своих потомков, а дети ссылаются на своих родителей), что вообще не позволяет использовать перекрестные ссылки, что снова делает мои структуры данных и код более функциональными.
- Наследование перестает иметь смысл, и вместо этого я начинаю использовать композицию.
- Все основные идеи ООП, такие как инкапсуляция, начинают разрушаться, и мои объекты начинают выглядеть как функции.
На данный момент я практически ничего не использую из парадигмы ООП и могу просто переключиться на чисто функциональный язык. Таким образом, мой вопрос: существует ли последовательный подход к хорошему неизменяемому дизайну ООП или всегда так, что, когда вы берете неизменную идею в полную силу, вы всегда заканчиваете программированием на функциональном языке, больше не нуждающемся в мире ООП? Существуют ли хорошие рекомендации для определения того, какие классы должны быть неизменяемыми, а какие должны быть изменяемыми, чтобы ООП не развалилось?
Просто для удобства приведу пример. Давайте иметь ChessBoardкак неизменную коллекцию неизменных шахматных фигур (расширение абстрактного классаPiece). С точки зрения ООП фигура отвечает за генерацию действительных ходов из своей позиции на доске. Но чтобы генерировать ходы, фигура должна иметь ссылку на свою доску, а доска должна иметь ссылку на свои фигуры. Ну, есть несколько хитростей для создания этих неизменяемых перекрестных ссылок в зависимости от вашего языка ООП, но ими сложно управлять, лучше не иметь части, чтобы ссылаться на свою доску. Но тогда фигура не может генерировать свои ходы, поскольку она не знает состояния доски. Тогда кусок становится просто структурой данных, содержащей тип куска и его положение. Затем вы можете использовать полиморфную функцию для генерации ходов для всех видов фигур. Это вполне достижимо в функциональном программировании, но почти невозможно в ООП без проверок типов во время выполнения и других плохих практик ООП ... Тогда
Ответы:
Не понимаю, почему нет. Я делал это в течение многих лет, прежде чем Java 8 все равно заработала. Вы когда-нибудь слышали о струнах? Хороший и неизменный с самого начала.
Все это время было нужно. Признать недействительными мои итераторы, потому что вы мутировали коллекцию, пока я ее читал, просто грубо.
Циркулярные ссылки - это особый вид ада. Неизменность не спасет вас от этого.
Ну, вот я с тобой, но не вижу, что это имеет отношение к неизменности. Причина, по которой мне нравится композиция, не в том, что я люблю шаблон динамической стратегии, а в том, что он позволяет мне изменить уровень абстракции.
Страшно подумать, какова ваша идея «ООП, как инкапсуляция». Если в нем участвуют геттеры и сеттеры, просто прекратите вызывать эту инкапсуляцию, потому что это не так. Это никогда не было. Это ручное Аспектно-ориентированное Программирование. Шанс проверить и место для установки точки останова - это хорошо, но это не инкапсуляция. Инкапсуляция сохраняет мое право не знать и не заботиться о том, что происходит внутри.
Ваши объекты должны выглядеть как функции. Они мешки функций. Это набор функций, которые движутся вместе и переопределяют себя вместе.
Функциональное программирование в настоящее время популярно, и люди теряют некоторые заблуждения относительно ООП. Не позволяйте этому сбить вас с толку, полагая, что это конец ООП. Функционал и ООП могут прекрасно жить вместе.
Функциональное программирование формально о назначениях.
ООП формально относится к указателям на функции.
Действительно, что это. Дикстра сказал нам, что
gotoэто вредно, поэтому мы получили формальное представление об этом и создали структурированное программирование. Точно так же, эти две парадигмы предназначены для нахождения способов добиться цели, избегая при этом ловушек, возникающих при выполнении этих неприятных вещей случайно.Позволь мне показать тебе что-то:
f n (x)
Это функция. На самом деле это континуум функций:
f 1 (x)
f 2 (x)
...
f n (x)
Угадайте, как мы выражаем это на языках ООП?
n.f(x)Этот маленький
nвыбор выбирает, какая реализацияfиспользуется, И он решает, какими являются некоторые из констант, используемых в этой функции (что откровенно означает то же самое). Например:f 1 (x) = x + 1
f 2 (x) = x + 2
Это то же самое, что обеспечивают замыкания. Там, где замыкания ссылаются на окружающую область, методы объекта ссылаются на их состояние экземпляра. Объекты могут сделать замыкания лучше. Закрытие - это одиночная функция, возвращенная из другой функции. Конструктор возвращает ссылку на целый пакет функций:
g 1 (x) = x 2 + 1
g 2 (x) = x 2 + 2
Да, вы уже догадались:
n.g(x)f и g - функции, которые изменяются вместе и перемещаются вместе. Поэтому мы сунем их в одну сумку. Это то, что на самом деле является объектом. Сохранение
nпостоянной (неизменной) просто означает, что легче предсказать, что они будут делать, когда вы их называете.Теперь это просто структура. То, как я думаю об ООП, - это куча мелочей, которые говорят о других мелочах. Надеюсь на небольшую избранную группу мелочей. Когда я пишу код, я представляю себя как объект. Я смотрю на вещи с точки зрения объекта. И я стараюсь быть ленивым, чтобы не перегружать объект. Я принимаю простые сообщения, немного работаю над ними и рассылаю простые сообщения только моим лучшим друзьям. Когда я закончу с этим объектом, я прыгаю в другой и смотрю на вещи с его точки зрения.
Карты классовой ответственности были первыми, кто научил меня так думать. Чувак, я тогда был в замешательстве из-за них, но, черт побери, они не актуальны сегодня.
Arg! Опять с ненужными круговыми ссылками.
Как насчет: A
ChessBoardDataStructureпревращает XY шнуры в части ссылки. У этих частей есть метод, который берет x, y и конкретный элементChessBoardDataStructureи превращает его в коллекцию новых марокChessBoardDataStructure. Затем сует это в то, что может выбрать лучший ход. ТеперьChessBoardDataStructureмогут быть неизменными, как и куски. Таким образом, у вас в памяти только одна белая пешка. Есть только несколько ссылок на него в правильных xy местах. Объектно-ориентированный, функциональный и неизменный.Подожди, мы уже не говорили о шахматах?
источник
На мой взгляд, наиболее полезные концепции, введенные ООП в основное русло:
Все эти преимущества также могут быть реализованы без традиционных деталей реализации, таких как наследование или даже классы. Первоначальная идея Алана Кея о «объектно-ориентированной системе» использовала «сообщения» вместо «методов» и была ближе к Эрлангу, чем, например, C ++. Посмотрите на Go, который покончил со многими традиционными деталями реализации ООП, но все еще чувствует себя достаточно объектно-ориентированным.
Если вы используете неизменяемые объекты, вы все равно можете использовать большинство традиционных вкусностей ООП: интерфейсы, динамическая диспетчеризация, инкапсуляция. Вам не нужны сеттеры, и часто даже не нужны геттеры для более простых объектов. Вы также можете воспользоваться преимуществами неизменности: вы всегда уверены, что объект не изменился за это время, нет защитного копирования, нет гонок данных, и методы легко сделать чистыми.
Посмотрите, как Scala пытается объединить неизменяемость и подходы FP с ООП. По общему признанию это не самый простой и изящный язык. Это практически практически успешно, хотя. Кроме того, взгляните на Kotlin, который предоставляет множество инструментов и подходов для подобного микса.
Обычная проблема, связанная с попыткой использовать другой подход, нежели тот, о котором думали создатели языка N лет назад, - это «несоответствие импеданса» стандартной библиотеке. OTOH и Java, и .NET экосистемы в настоящее время имеют разумную поддержку стандартных библиотек для неизменных структур данных; Конечно, сторонние библиотеки также существуют.
источник