Истинное определение неизменности?
документация по этому вопросу на самом деле безумно проста
Пример того, как читать сжатый файл:
import gzip
f = gzip.open('file.txt.gz', 'rb')
file_content = f.read()
f.close()
Пример того, как создать сжатый файл GZIP:
import gzip
content = "Lots of content here"
f = gzip.open('file.txt.gz', 'wb')
f.write(content)
f.close()
Пример того, как GZIP сжимает существующий файл:
import gzip
f_in = open('file.txt', 'rb')
f_out = gzip.open('file.txt.gz', 'wb')
f_out.writelines(f_in)
f_out.close()
f_in.close()
https://docs.python.org/2/library/gzip.html
Вот и вся документация. , ,
9 ответов
Если значения не являются общедоступными и не могут быть изменены, тогда этого достаточно?
Нет, потому что вам нужен доступ для чтения.
Можно ли изменить значения внутри типа, а не заказчиком типа?
Нет, потому что это все еще мутация.
Или их можно установить только внутри конструктора?
Динь динь динь! С дополнительной точкой зрения, неизменные типы часто имеют методы, которые создают и возвращают новые экземпляры, а также часто имеют дополнительные конструкторы, помеченные internal специально для использования этими методами.
Как я могу гарантировать, что тип равен 100 % immutable?
В .Net сложно получить такую гарантию, потому что вы можете использовать отражение для изменения (мутации) закрытых членов.
В предыдущих плакатах уже говорилось, что вы должны присваивать значения своим полям в конструкторе, а затем держать их подальше от них. Но иногда легче сказать, чем сделать. Допустим, ваш неизменяемый объект предоставляет свойство типа List . Можно ли изменить этот список? А если нет, то как вы будете это контролировать?
Эрик Липперт написал в своем блоге серию сообщений о неизменяемости в C #, которые могут вас заинтересовать: вы найдете первую часть здесь .
Вот определение неизменяемости из Википедии ( ссылка )
«В объектно-ориентированном и функциональном программировании неизменяемый объект - это объект, состояние которого не может быть изменено после того, как он был создан »
По сути, после того, как объект создан, ни одно из его свойств не может быть изменено. Примером является класс String. После создания объекта String его нельзя изменить. Любая операция, выполняемая с ним, фактически создает новый объект String.
Там много вопросов. Я постараюсь ответить на каждый из них индивидуально:
«Мне интересно, как определяется неизменность?» - Прямо со страницы Википедии (и совершенно точного / краткого определения)
Неизменяемый объект - это объект, состояние которого не может быть изменено после его создания
«Если значения не отображаются как общедоступный, поэтому не может быть изменен, тогда этого достаточно? " - Не совсем. Он не может быть изменен в каким-либо образом , поэтому вы должны убедиться, что методы / функции не изменяют состояние объекта, и при выполнении операций всегда возвращать новый экземпляр.
«Могут ли значения быть изменены внутри типа, а не заказчиком типа?» - Технически может » t может быть изменен либо внутри, либо потребителем данного типа. На практике существуют такие типы, как
System.String(ссылочный тип в данном случае), которые можно считать изменяемыми почти для всех практических целей, хотя и не в теории.«Или можно только установить их. внутри конструктора? " - Да, теоретически это единственное место, где можно установить состояние (переменные).
«Если да, то в случаях двойной инициализации (использование ключевого слова this в структурах и т. Д.) Все еще в порядке для неизменяемых типов? " - Да, это все еще прекрасно, потому что все это часть процесса инициализации (создания), и экземпляр не возвращается до его завершения.
«Как я могу гарантировать, что тип на 100% неизменен?» - Следующие условия должны гарантировать это. (Кто-нибудь, пожалуйста, укажите, если я m отсутствует один.)
- Не выставлять никаких переменных. Все они должны быть
закрытыми(недопустимо дажеprotected, поскольку производные классы могут затем изменять состояние). - Не разрешайте никаким методам экземпляра изменять состояние (переменные) . Это следует делать только в конструкторе, в то время как методы должны создавать новые экземпляры с использованием определенного конструктора, если они требуют возврата «измененного» объекта.
- Все члены, которые открываются (как доступные только для чтения), или объекты, возвращаемые методами должны сами быть неизменяемыми.
Примечание: вы не можете гарантировать неизменность производных типов, поскольку они могут определять новые переменные. Это причина отмечать любой тип, который вам нужен
- Не выставлять никаких переменных. Все они должны быть
Я узнал, что неизменяемость - это когда вы устанавливаете все в конструкторе и не можете изменять его позже в течение жизненного цикла объекта.
Определение неизменяемости можно найти в Google .
Пример:
неизменяемый - буквально, не может изменяться.
www.filosofia.net/materiales/rec/glosaen.htm
С точки зрения неизменяемых структур данных типичное определение - запись-один раз-чтение-много, другими словами, как вы говорите, однажды созданное, его нельзя изменить
Есть некоторые случаи, которые находятся в серой зоне. Например, строки .NET считаются неизменяемыми, поскольку они не могут быть изменены, однако StringBuilder внутренне изменяет объект String.
Неизменяемый объект - это, по сути, класс, который заставляет себя быть окончательным из своего собственного кода. Как только он появится, ничего изменить нельзя. Насколько мне известно, все настраивается в конструкторе и все. Я не понимаю, как иначе что-то могло быть неизменным.
There's unfortunately no immutable keywords in c#/vb.net, though it has been debated, but if there's no autoproperties and all fields are declared with the readonly (readonly fields can only bet assigned in the constructor) modfier and that all fields is declared of an immutable type you will have assured your self immutability.
Я никогда не использовал Java, но с тех пор, как я прочитал
- Почему в C # нет спецификаций исключений?
- Нужны ли для Java проверенные исключения?
- Проблема с проверенными исключениями
Я совершенно уверен, что мне не нравятся проверенные исключения (в текущей реализации).
Два основных упомянутых момента заключаются в следующем.
Версионность
Андерс Хейлсберг: Начнем с управления версиями, потому что проблемы там довольно легко увидеть. Скажем, я создаю метод foo, который объявляет, что он генерирует исключения A, B и C. Во второй версии foo я хочу добавить кучу функций, и теперь foo может генерировать исключение D. Это критическое изменение для меня. добавьте D в предложение throws этого метода, потому что существующий вызывающий этого метода почти наверняка не обработает это исключение.
Добавление нового исключения в предложение throws в новой версии приводит к нарушению клиентского кода. Это похоже на добавление метода в интерфейс. После публикации интерфейса он остается неизменным для всех практических целей, потому что в любой его реализации могут быть методы, которые вы хотите добавить в следующую версию. Поэтому вместо этого вам нужно создать новый интерфейс. Точно так же с исключениями вам придется либо создать совершенно новый метод с именем foo2, который генерирует больше исключений, либо вам придется перехватить исключение D в новом foo и преобразовать D в A, B или C.
Масштабируемость
Андерс Хейлсберг: Проблема масштабируемости в некоторой степени связана с проблемой версии. В небольших, проверенные исключения очень заманчивы. На небольшом примере вы можете показать, что действительно проверили, что вы поймали FileNotFoundException, и разве это не здорово? Что ж, это нормально, когда вы просто вызываете один API. Проблема начинается, когда вы начинаете строить большие системы, в которых вы разговариваете с четырьмя или пятью различными подсистемами. Каждая подсистема выдает от четырех до десяти исключений. Теперь, каждый раз, когда вы поднимаетесь по лестнице агрегации, у вас под вами появляется экспоненциальная иерархия исключений, с которыми вам приходится иметь дело. В итоге вам придется объявить 40 исключений, которые вы можете выбросить. И как только вы объедините это с другой подсистемой, у вас будет 80 исключений в вашем предложении throws. Он просто выходит из-под контроля.
В целом отмеченные исключения становятся таким раздражающим фактором, что люди полностью обходят эту функцию. Либо они говорят «бросает исключение» везде; или - и я не могу сказать вам, сколько раз я это видел - они говорят: «Попробуй, да да да да да, неуправляемые ресурсы. Следовательно, нет необходимости утилизировать какие-либо из них как но я думаю, что было бы разрешено кэшировать хэш-код для экземпляра, поэтому хеш вычисляется только при первом вызове
GetHashCode (). Обратите внимание, что, насколько мне известно, классSystem.Stringделает это , а не , но я думаю, что он может и по-прежнему считаться неизменным. Конечно, любое из этих изменений должно быть обработано потокобезопасным способом (в соответствии с ненаблюдаемым аспектом изменений).Если честно, я не могу придумать многих причин, по которым кто-то может захотеть или нуждаются в такой «невидимой изменчивости».