Якщо непорушні предмети хороші, чому люди продовжують створювати змінні предмети? [зачинено]

Якщо незмінні об'єкти¹ хороші, прості та пропонують переваги при одночасному програмуванні, чому програмісти продовжують створювати об'єкти, що змінюються²?

У мене є чотирирічний досвід роботи в програмуванні Java, і, як я це бачу, перше, що люди роблять після створення класу, - це генерувати геттери та сетери в IDE (таким чином роблячи його змінним). Чи є недостатня обізнаність чи ми можемо піти з використання змінних об'єктів у більшості сценаріїв?

^{¹ Незмінний об'єкт - це об'єкт, стан якого не може бути змінений після його створення.
² Змінюваний об'єкт - це об'єкт, який можна змінювати після його створення.}

Як об'єкти, що змінюються, так і непорушні мають свої переваги, плюси і мінуси.

Незмінні предмети дійсно полегшують життя у багатьох випадках. Вони особливо застосовні для типів значень, де об’єкти не мають ідентичності, тому їх можна легко замінити. І вони можуть зробити одночасне програмування способом більш безпечним та чистим (більшість сумнозвісних помилок, що знаходять одночасно, в кінцевому рахунку спричинені змінним станом, поділеним між потоками). Однак для великих та / або складних об'єктів створення нової копії об'єкта для кожної зміни може бути дуже дорогим та / або стомлюючим. А для об’єктів із чіткою ідентичністю зміна існуючих об'єктів набагато простіша та інтуїтивніша, ніж створення нової модифікованої копії.

Подумайте про ігрового персонажа. В іграх швидкість є першочерговим завданням, тому представлення ваших ігрових персонажів із змінними предметами, швидше за все, зробить вашу гру значно швидшою, ніж альтернативна реалізація, де нова копія ігрового персонажа створюється для кожної невеликої зміни.

Більше того, наше сприйняття реального світу неминуче засноване на змінних об'єктах. Коли ви заправляєте автомобіль паливом на АЗС, ви сприймаєте його як той самий об’єкт протягом усього часу (тобто його особистість зберігається, коли стан змінюється) - не так, як якщо старий автомобіль із порожнім баком замінили на новий поспіль Автомобільні екземпляри поступово все більше наповнюються. Отже, коли ми моделюємо деякий реальний домен у програмі, зазвичай простіше та легше реалізувати модель домену за допомогою змінних об'єктів для представлення реальних сутностей.

Окрім усіх цих законних причин, на жаль, найбільш вірогідною причиною, чому люди продовжують створювати змінні об’єкти, є інертність духу, також опір змінам. Зауважимо, що сьогодні більшість розробників пройшли підготовку ще до того, як незмінність (а також парадигма, що містить функціональне програмування) стала "модною" у своїй сфері впливу, і не оновлює свої знання про нові інструменти та методи нашої торгівлі - насправді багато хто з нас люди позитивно протистоять новим ідеям та процесам. "Я програмував так уже п ять років, і мене не хвилюють останні дурні примхи!"

Я думаю, що ви всі пропустили найочевиднішу відповідь. Більшість розробників створюють об'єкти, що змінюються, тому що змінюваність є типовим мовою в імперативних мовах. Більшість із нас мають кращі стосунки до свого часу, ніж постійно змінювати код подалі від налаштування за замовчуванням - правильніше чи ні. І незмінність - це не панацея більше, ніж будь-який інший підхід. Це робить деякі речі простішими, але робить інші набагато складнішими, як деякі відповіді вже вказували.

1. Тут є місце для змінності. Принципи дизайну, керовані доменом, дають чітке розуміння того, що має бути змінним, а що - незмінним. Якщо ви подумаєте про це, то зрозумієте, що недоцільно уявляти систему, в якій кожна зміна стану об'єкта вимагає руйнування та перекомпозиції його та кожного об'єкта, на який він посилається. За допомогою складних систем це може легко призвести до повного витирання та відновлення об'єктного графіка всієї системи

2. Більшість розробників не роблять нічого, коли вимоги до продуктивності є досить вагомими, що їм потрібно зосередитись на паралельності (або на багатьох інших питаннях, які поінформовані в цілому вважають доброю практикою).

3. Є деякі речі, які ви просто не можете зробити з незмінними об'єктами, наприклад, у двосторонніх відносинах. Після того, як ви встановите значення асоціації на одному об’єкті, воно змінюється ідентичність. Отже, ви встановлюєте нове значення для іншого об'єкта, і воно також змінюється. Проблема в тому, що посилання на перший об'єкт більше не є дійсним, оскільки створений новий екземпляр для представлення об'єкта з посиланням. Продовження цього лише призведе до нескінченних регресій. Я трохи прочитав тематичне дослідження, прочитавши ваше запитання, ось як це виглядає. Чи є у вас альтернативний підхід, який дозволяє таку функціональність, зберігаючи незмінність?

       public class ImmutablePerson { 
   
        public ImmutablePerson(string name, ImmutableEventList eventsToAttend)
        {
             this.name = name;
             this.eventsToAttend = eventsToAttend;
        }
        private string name;
        private ImmutableEventList eventsToAttend;
   
        public string Name { get { return this.name; } }
   
        public ImmutablePerson RSVP(ImmutableEvent immutableEvent){
            // the person is RSVPing an event, thus mutating the state 
            // of the eventsToAttend.  so we need a new person with a reference
            // to the new Event
            ImmutableEvent newEvent = immutableEvent.OnRSVPReceived(this);
            ImmutableEventList newEvents = this.eventsToAttend.Add(newEvent));
            var newSelf = new ImmutablePerson(name, newEvents);
            return newSelf;
        }
       }
   
       public class ImmutableEvent { 
        public ImmutableEvent(DateTime when, ImmutablePersonList peopleAttending, ImmutablePersonList peopleNotAttending){
            this.when = when;     
            this.peopleAttending = peopleAttending;
            this.peopleNotAttending = peopleNotAttending;
        }
        private DateTime when; 
        private ImmutablePersonList peopleAttending;
        private ImmutablePersonList peopleNotAttending;
        public ImmutableEvent OnReschedule(DateTime when){
              return new ImmutableEvent(when,peopleAttending,peopleNotAttending);
        }
        //  notice that this will be an infinite loop, because everytime one counterpart
        //  of the bidirectional relationship is added, its containing object changes
        //  meaning it must re construct a different version of itself to 
        //  represent the mutated state, the other one must update its
        //  reference thereby obsoleting the reference of the first object to it, and 
        //  necessitating recursion
        public ImmutableEvent OnRSVPReceived(ImmutablePerson immutablePerson){
              if(this.peopleAttending.Contains(immutablePerson)) return this;
              ImmutablePersonList attending = this.peopleAttending.Add(immutablePerson);
              ImmutablePersonList notAttending = this.peopleNotAttending.Contains( immutablePerson ) 
                                   ? peopleNotAttending.Remove(immutablePerson)
                                   : peopleNotAttending;
              return new ImmutableEvent(when, attending, notAttending);
        }
       }
       public class ImmutablePersonList
       {
         private ImmutablePerson[] immutablePeople;
         public ImmutablePersonList(ImmutablePerson[] immutablePeople){
             this.immutablePeople = immutablePeople;
         }
         public ImmutablePersonList Add(ImmutablePerson newPerson){
             if(this.Contains(newPerson)) return this;
             ImmutablePerson[] newPeople = new ImmutablePerson[immutablePeople.Length];
             for(var i=0;i<immutablePeople.Length;i++)
                 newPeople[i] = this.immutablePeople[i];
             newPeople[immutablePeople.Length] = newPerson;
         }
         public ImmutablePersonList Remove(ImmutablePerson newPerson){
             if(immutablePeople.IndexOf(newPerson) != -1)
             ImmutablePerson[] newPeople = new ImmutablePerson[immutablePeople.Length-2];
             bool hasPassedRemoval = false;
             for(var i=0;i<immutablePeople.Length;i++)
             {
                hasPassedRemoval = hasPassedRemoval || immutablePeople[i] == newPerson;
                newPeople[i] = this.immutablePeople[hasPassedRemoval ? i + 1 : i];
             }
             return new ImmutablePersonList(newPeople);
         }
         public bool Contains(ImmutablePerson immutablePerson){ 
            return this.immutablePeople.IndexOf(immutablePerson) != -1;
         } 
       }
       public class ImmutableEventList
       {
         private ImmutableEvent[] immutableEvents;
         public ImmutableEventList(ImmutableEvent[] immutableEvents){
             this.immutableEvents = immutableEvents;
         }
         public ImmutableEventList Add(ImmutableEvent newEvent){
             if(this.Contains(newEvent)) return this;
             ImmutableEvent[] newEvents= new ImmutableEvent[immutableEvents.Length];
             for(var i=0;i<immutableEvents.Length;i++)
                 newEvents[i] = this.immutableEvents[i];
             newEvents[immutableEvents.Length] = newEvent;
         }
         public ImmutableEventList Remove(ImmutableEvent newEvent){
             if(immutableEvents.IndexOf(newEvent) != -1)
             ImmutableEvent[] newEvents = new ImmutableEvent[immutableEvents.Length-2];
             bool hasPassedRemoval = false;
             for(var i=0;i<immutablePeople.Length;i++)
             {
                hasPassedRemoval = hasPassedRemoval || immutableEvents[i] == newEvent;
                newEvents[i] = this.immutableEvents[hasPassedRemoval ? i + 1 : i];
             }
             return new ImmutableEventList(newPeople);
         }
         public bool Contains(ImmutableEvent immutableEvent){ 
            return this.immutableEvent.IndexOf(immutableEvent) != -1;
         } 
       }
   

Я читав "суто функціональні структури даних", і це дало мені зрозуміти, що існує досить багато структур даних, які набагато простіше реалізувати за допомогою змінних об'єктів.

Щоб реалізувати двійкове дерево пошуку, вам потрібно буде щоразу повертати нове дерево: вашому новому дереву доведеться зробити копію кожного зміненого вузла (немодифіковані гілки поділяються). Для вашої функції вставки це не так вже й погано, але для мене речі стали досить неефективними, коли я почав працювати над видаленням та повторним балансом.

Інша річ, яку потрібно усвідомити, - це те, що ви можете піти роки писати об'єктно-орієнтований код, і ніколи насправді не усвідомлювати, наскільки страшним може бути загальний стан, що змінюється, якщо ваш код не працює таким чином, що викриває проблеми з одночасністю.

З моєї точки зору, це недостатня обізнаність. Якщо ви подивитеся на інші відомі мови JVM (Scala, Clojure), змінні об'єкти рідко бачать у коді, і тому люди починають використовувати їх у сценаріях, коли однієї нитки недостатньо.

Зараз я вивчаю Clojure і маю невеликий досвід роботи в Scala (4 роки + також на Java), і ваш стиль кодування змінюється через усвідомлення стану.

Я думаю, що основний фактор, що сприяє, був ігнорований: Java Beans сильно покладаються на певний стиль мутування об'єктів, і (особливо з урахуванням джерела) досить багато людей, здається, сприймають це як (або навіть той ) канонічний приклад того, як усі Java слід писати.

Кожна корпоративна система Java, над якою я працював у своїй кар’єрі, використовує або Hibernate, або API API Persistent (JPA). Hibernate та JPA по суті диктують, що ваша система використовує об'єкти, що змінюються, оскільки вся їх передумова полягає в тому, щоб вони виявляли та зберігали зміни у ваших об'єктах даних. Для багатьох проектів простота розвитку, яку приносить сплячка, є більш переконливою, ніж переваги незмінних об'єктів.

Очевидно, що об'єкти, що змінюються, існують набагато довше, ніж у сплячому режимі, тому сплячий режим, ймовірно, не є первісною причиною популярності об'єктів, що змінюються. Можливо, популярність мінливих предметів дозволила сплячці процвітати.

Але сьогодні, якщо багато молодших програмістів ріжуть зуби на корпоративних системах, використовуючи Hibernate або інший ORM, тоді, імовірно, вони підберуть звичку використовувати об'єкти, що змінюються. Такі структури, як сплячий режим, можуть посилити популярність об'єктів, що змінюються.

Основний момент, який ще не згадується, - це те, що стан об'єкта, який може бути змінним, дає змогу ідентичність об'єкта, яка інкапсулює цей стан, незмінна.

Багато програм створені для моделювання реальних речей, які за своєю суттю змінюються. Припустимо, що о 12:51, деяка змінна AllTrucksмістить посилання на об'єкт № 451, що є коренем структури даних, яка вказує, який вантаж міститься у всі вантажні машини флоту в цей момент (12:51 ранку), а який - змінний BobsTruckможе бути використаний для отримання посилання на об'єкт №24601 вказує на об'єкт, який вказує, який вантаж міститься в вантажівці Боба в цей момент (12:51 ранку). О 12:52 ранку деякі вантажівки (включаючи Боба) завантажуються та вивантажуються, а структури даних оновлюються так, що AllTrucksтепер буде посилатися на структуру даних, яка вказує, що вантаж знаходиться у всіх вантажівок станом на 12:52 ранку.

Що має статися BobsTruck?

Якщо властивість «вантажу» кожного об'єкта вантажівки буде непорушною, то об’єкт №24601 назавжди буде представляти стан, який мав вантажівка Боба о 12:51 ранку. Якщо BobsTruckмає пряме посилання на об’єкт №24601, то, якщо код, який оновлення AllTrucksтакож не оновлюється BobsTruck, він перестане представляти поточний стан вантажівки Боба. Далі зауважте, що якщо BobsTruckне зберігається в якійсь формі об'єкта, що змінюється, єдиний спосіб, коли код, який оновлення AllTrucksміг би оновити, був би, якщо код був явно запрограмований для цього.

Якщо хтось хоче мати можливість BobsTruckспостерігати за станом вантажівки Боба, зберігаючи всі непорушні об'єкти, може BobsTruckбути незмінна функція, яка, зважаючи на значення, яке AllTrucksмає або було в будь-який конкретний час, призведе до стану вантажівки Боба на того часу. Можна навіть мати, щоб він виконував пару незмінних функцій - одна з яких була б, як вище, а друга з яких приймала б посилання на стан флоту та новий стан вантажівки, а також повертала посилання на новий стан флоту, який відповідає старому, за винятком того, що вантажівка Боба мала б новий стан.

На жаль, використання такої функції кожного разу, коли хочеться отримати доступ до штату вантажівка Боба, може стати досить дратівливою і громіздкою. Альтернативним підходом було б сказати, що об'єкт №24601 завжди і назавжди (доки хтось має на нього посилання) буде представляти поточний стан вантажівки Боба. Код, який бажає неодноразово отримувати доступ до поточного стану вантажівки Боба, не повинен був би виконувати деяку трудомістку функцію кожного разу - він може просто виконувати функцію пошуку один раз, щоб дізнатися, що об’єкт №24601 - вантажівка Боба, а потім просто отримати доступ до цього об'єкта будь-коли, коли він хоче побачити сучасний стан вантажівки Боба.

Зауважте, що функціональний підхід не позбавлений переваг в однопотоковому середовищі або в багатопотоковому середовищі, де потоки здебільшого просто спостерігатимуть дані, а не змінюватимуть їх. Будь-яка нитка спостерігача, яка копіює посилання на об'єкт, що міститься вAllTrucksа потім вивчає представлені таким чином стани вантажівки, побачить стан усіх вантажних автомобілів станом на той момент, коли він схопив посилання. Кожен раз, коли нитка спостерігача хоче побачити новіші дані, вона може просто знову захопити посилання. З іншого боку, наявність усього штату флоту, представленого одним незмінним об'єктом, виключає можливість одночасного оновлення двох потоків різних вантажних автомобілів, оскільки кожен потік, якщо залишити його на власні пристрої, створював би новий об'єкт "стан флоту", який включає новий стан своєї вантажівки та старі штати кожного іншого. Правильність може бути гарантована, якщо кожен потік використовує CompareExchangeдля оновлення AllTrucksлише те, що він не змінився і відповідає на помилкуCompareExchangeшляхом регенерації об'єкта стану та повторної операції, але якщо одночасна операція запису намагається більше ніж один потік, продуктивність, як правило, буде гіршою, ніж якщо б усі записи були виконані на одному потоці; чим більше ниток намагаються проводити такі одночасні операції, тим гірше буде отримати продуктивність.

Якщо окремі об'єкти вантажних автомобілів є змінними, але мають незмінні ідентичності , багатопотоковий сценарій стає більш чистим. На будь-якому вантажівці одночасно може працювати лише одна нитка, але нитки, що працюють на різних вантажних автомобілях, можуть робити це без втручання. Хоча існують способи, які можна наслідувати такій поведінці навіть при використанні незмінних об'єктів (наприклад, можна визначити об'єкти "AllTrucks", щоб встановлення стану вантажівки, що належить до XXX, до SSS, просто вимагало б створити об'єкт, який сказав "Станом на [Час]", стан вантажівки, що належить до [XXX], зараз є [SSS]; стан всього іншого - [стара цінність AllTrucks] ". Створення такого об'єкта було б досить швидким, що навіть за наявності суперечкиCompareExchangeпетля не займе багато часу. З іншого боку, використання такої структури даних суттєво збільшить час, необхідний для пошуку вантажівки конкретної людини. Використання змінних об'єктів з незмінною ідентичністю дозволяє уникнути цієї проблеми.

Немає правильного чи неправильного, просто залежить, що ви віддаєте перевагу. Є причина, чому деякі люди віддають перевагу мовам, які надають перевагу одній парадигмі над іншою, а одна модель даних над іншою. Це просто залежить від ваших уподобань та того, чого ви хочете досягти (і вміти легко використовувати обидва підходи, не відчужуючи важких фанатів тієї чи іншої сторони - це святий грааль, який деякі мови шукають).

Я думаю, що найкращий і найшвидший спосіб відповісти на ваше запитання - це перейти до плюсів і мінусів непорушності проти змінності .

Перевірте це повідомлення в блозі: http://www.yegor256.com/2014/06/09/objects-should-be-immutable.html . Він підсумовує, чому незмінні предмети краще, ніж змінні. Ось короткий список аргументів:

• незмінні об'єкти простіші для побудови, тестування та використання
• справді незмінні об'єкти завжди безпечні для ниток
• вони допомагають уникнути часової зв’язки
• їх використання не має побічних ефектів (відсутні захисні копії)
• Проблема мутаційності особистості уникається
• вони завжди мають атомну атомність
• їх набагато простіше кешувати

Наскільки я розумію, люди використовують змінні об'єкти, оскільки вони все ще змішують ООП з імперативними процедурними програмуваннями.

У Java незмінним об'єктам потрібен конструктор, який буде приймати всі властивості об'єкта (або конструктор створює їх з інших аргументів або за замовчуванням). Ці властивості мають бути позначені остаточними .

З цим є чотири проблеми, пов'язані з прив'язкою даних :

1. Метадані відображення Java Constructors не містять імен аргументів.
2. Конструктори Java (і методи) не мають іменованих параметрів (їх також називають мітками), тому це стає заплутаним у багатьох параметрах.
3. При успадкуванні іншого незмінного об'єкта повинен бути названий належний порядок конструкторів. Це може бути досить складним, якщо просто відмовитись і залишити одне з полів не остаточним.
4. Більшість технологій прив'язки (наприклад, Spring MVC Data Binding, Hibernate тощо) працюватимуть лише з конструкторами за замовчуванням без аргументів (це було тому, що анотації існували не завжди).

Ви можете пом'якшити №1 та №2, використовуючи примітки, як-от @ConstructorPropertiesі створити інший об'єкт, що змінюється, для будівельника (як правило, вільно) для створення незмінного об'єкта.

Я здивований, що ніхто не згадав про переваги оптимізації продуктивності. Залежно від мови компілятор може зробити купу оптимізацій під час роботи з незмінними даними, оскільки знає, що дані ніколи не зміняться. Всілякі речі пропускаються, що дає величезні переваги від продуктивності.

Також непорушні об'єкти майже усувають весь клас державних помилок.

Він не такий великий, як має бути, тому що його складніше, не стосується кожної мови, і більшість людей навчали імперативному кодуванню.

Також я виявив, що більшість програмістів задоволені своєю скринькою і часто стійкі до нових ідей, які вони не повністю розуміють. Взагалі люди не люблять змін.

Також пам’ятайте, що стан більшості програмістів поганий. Більшість програм, які робляться в дикій природі, жахливі і спричинені нерозумінням та політикою.

Чому люди використовують будь-яку потужну функцію? Чому люди використовують метапрограмування, лінь чи динамічне введення тексту? Відповідь - зручність. Стан, що змінюється, такий простий. Це так просто оновити на місці, а поріг розміру проекту, коли незмінний стан є більш продуктивним для роботи, ніж стан, що змінюється, досить високий, тому вибір не відкидає вас на деякий час.

Мови програмування призначені для виконання комп'ютерами. Усі важливі складові комп'ютерів - процесор, оперативна пам’ять, кеш, диски - змінні. Коли вони не є (BIOS), вони справді непорушні, і ви також не можете створювати нові незмінні об'єкти.

Отже, будь-яка мова програмування, побудований поверх незмінних об'єктів, страждає від розриву у поданні в його реалізації. А для ранніх мов, таких як C, це було великим каменем спотикання.

Без змінних об'єктів у вас немає стану. Справді, це гарна річ, якщо ви можете керувати нею, і якщо є якийсь шанс, що на об'єкт може бути посилається більше, ніж на один потік. Але програма буде досить нудною. Багато програмного забезпечення, зокрема веб-серверів, уникають відповідальності за об'єкти, що змінюються, шляхом вимкнення мутабельності в базах даних, операційних системах, системних бібліотеках і т.д. розвиток доступний. Але незмінність все ще є.

Загалом, у вас є три типи класів: звичайні класи, які не є безпечними для потоків, і їх слід ретельно охороняти та захищати; незмінні класи, якими можна вільно користуватися; і змінні класи, безпечні для потоків, які можна вільно використовувати, але які слід писати з особливою обережністю. Перший тип - це клопіткий, найгірші - ті, що вважаються третім. Звичайно, перший тип - це прості в написанні.

Я зазвичай закінчую безліч звичайних, змінних занять, за якими мені доводиться дуже уважно спостерігати. У ситуації з декількома потоками необхідна синхронізація сповільнює все, навіть коли я можу уникнути смертоносних обіймів. Тому я звичайно роблю незмінні копії класу, що змінюється, і передаю їх тому, хто може ним користуватися. Нова незмінна копія потрібна щоразу, коли оригінальний мутує, тому я думаю, що часом у мене може бути сто копій оригіналу. Я повністю залежний від збору сміття.

Підсумовуючи, об'єкти, що не змінюються для потоків, що змінюються, добре, якщо ви не використовуєте декілька потоків. (Але багатопоточність читається скрізь - будьте обережні!) Їх можна безпечно використовувати інакше, якщо ви обмежите їх локальними змінними або суворо їх синхронізуєте. Якщо ви можете їх уникнути, використовуючи перевірений код інших людей (БД, системні дзвінки тощо), зробіть це. Якщо ви можете використовувати незмінний клас, зробіть це. І я думаю , загалом люди або не знають про багатопотокові проблеми, або їх (розумно) жахлять і використовують усілякі хитрощі, щоб уникнути багатопоточності (а точніше, покладаючи на це відповідальність за інше).

Як PS, я відчуваю, що геттери і сетери Java виходять з рук. Перевірте це .

Багато людей мали гарні відповіді, тому я хочу зазначити те, що ви торкнулися, що було дуже спостережливим і надзвичайно правдивим і ніде не згадувалося тут.

Автоматичне створення сетерів та геттерів - це жахлива, жахлива ідея, але це перший спосіб, коли процесуально налаштовані люди намагаються примусити ОО до себе. Налаштування та геттери разом із властивостями повинні створюватися лише тоді, коли ви виявите, що вам потрібні, а не за замовчуванням

Насправді, хоча вам потрібні регулярні користувачі, єдиний спосіб, коли сеттери або властивості для запису повинні колись існувати у вашому коді, - це через модель конструктора, де вони закриваються після того, як об'єкт буде повністю ініційований.

Багато класів можна змінювати після створення, що добре, він просто не повинен мати його властивостями безпосередньо маніпулювати - натомість слід попросити маніпулювати його властивостями за допомогою викликів методів із фактичною діловою логікою в них (Так, сетер майже однаковий річ як безпосередньо маніпулювання майном)

Тепер це дійсно не стосується коду / мов стилю "Сценарій", а лише до коду, який ви створюєте для когось іншого, і очікуйте, що інші читатимуть багато разів протягом багатьох років. Мені довелося почати робити це розмежування останнім часом, тому що мені так подобається возитися з Гроови, і в цілях є величезна різниця.

Об'єкти, що змінюються, використовуються, коли після встановлення об'єкта потрібно встановити кратні значення.

У вас не повинно бути конструктора з, скажімо, шістьма параметрами. Натомість ви модифікуєте об'єкт методами встановлення.

Прикладом цього може бути об’єкт Report, у якому встановлені шрифти, орієнтація тощо.

Коротше кажучи: мутанти корисні, коли у вас є багато стану для встановлення об'єкта, і не було б практичним мати дуже довгий підпис конструктора.

EDIT: Шаблон Builder можна використовувати для побудови всього стану об’єкта.

Я думаю, що використання змінних об'єктів випливає з імперативного мислення: ви обчислюєте результат, змінюючи вміст змінних змінних поетапно (обчислення побічним ефектом).

Якщо ви думаєте функціонально, ви хочете мати незмінний стан і представляти наступні стани системи, застосовуючи функції та створюючи нові значення зі старих.

Функціональний підхід може бути більш чистим і надійним, але він може бути дуже неефективним через копіювання, так що ви хочете повернутися до спільної структури даних, яку ви поступово змінюєте.

Компроміс, який я вважаю найбільш розумним: Почніть з незмінних об'єктів, а потім перейдіть до змінних, якщо ваша реалізація недостатньо швидка. З цієї точки зору, систематичне використання змінних об'єктів з самого початку можна вважати якоюсь передчасною оптимізацією : ви вибираєте більш ефективну (але також складнішу для розуміння та налагодження) реалізацію з самого початку.

Отже, чому багато програмістів використовують змінні об’єкти? ІМХО з двох причин:

1. Багато програмістів навчилися програмувати за допомогою імперативної (процедурної або об’єктно-орієнтованої) парадигми, тому незмінність є їх основним підходом до визначення обчислень, тобто вони не знають, коли і як використовувати незмінність, оскільки вони не знайомі з нею.
2. Багато програмістів переживають про продуктивність занадто рано, тоді як часто більш ефективно спочатку зосередитися на написанні функціонально правильної програми, а потім спробувати знайти вузькі місця та оптимізувати її.

Я знаю, що ви запитуєте про Java, але я весь час використовую змінний vs незмінний у target-c. Існує незмінний масив NSArray та змінний масив NSMutableArray. Це два різні класи, написані спеціально оптимізованим способом для точного використання. Якщо мені потрібно створити масив і ніколи не змінювати його вміст, я б використав NSArray, який є меншим об'єктом і набагато швидше в тому, що він робить, порівняно з змінним масивом.

Отже, якщо ви створюєте об'єкт Person, який є незмінним, тоді вам потрібен лише конструктор і getters, таким чином об'єкт буде меншим і використовуватиме менше пам'яті, що, в свою чергу, зробить вашу програму фактично швидшою. Якщо вам потрібно змінити об'єкт після створення, то об'єкт, що змінюється Person, буде кращим, щоб він міг змінювати значення замість створення нового об'єкта.

Отже: залежно від того, що ви плануєте робити з об'єктом, вибір мутабельних та незмінних може призвести до величезних змін, що стосується продуктивності.

На додаток до багатьох інших причин, наведених тут, проблема полягає в тому, що основні мови недостатньо підтримують незмінність. Принаймні, ви накладаєте штраф за незмінність тим, що вам потрібно додати додаткові ключові слова, такі як const або final, і вам доведеться використовувати нерозбірливі конструктори з багатьма, багатьма аргументами або кодами, тривалими моделями розробника.

Це набагато простіше в мовах, зроблених з незмінністю на увазі. Розглянемо цей фрагмент Scala для визначення особи класу, необов'язково з названими аргументами та створення копії зі зміненим атрибутом:

case class Person(id: String, firstName: String, lastName: String)

val joe = Person("123", "Joe", "Doe")
val spouse = Person(id = "124", firstName = "Mary", lastName = "Moe")
val joeMarried = joe.copy(lastName = "Doe-Moe")

Отже, якщо ви хочете, щоб розробники перейняли незмінність, це одна з причин, чому ви можете розглянути можливість переходу на більш сучасну мову програмування.

Незмінне означає, що ви не можете змінити значення, а змінне означає, що ви можете змінити значення, якщо ви думаєте з точки зору примітивів та об'єктів. Об'єкти відрізняються від примітивів на Java тим, що вони побудовані за типами. Примітиви побудовані у таких типах, як int, boolean та void.

Дуже багато людей думають, що примітиви та змінні об'єктів, які мають перед собою остаточний модифікатор, незмінні, однак, це не зовсім так. Отже, остаточне майже не означає незмінного для змінних. Перевірте це посилання на зразок коду:

public abstract class FinalBase {

    private final int variable; // Unset

    /* if final really means immutable than
     * I shouldn't be able to set the variable
     * but I can.
     */
    public FinalBase(int variable) { 
        this.variable = variable;
    }

    public int getVariable() {
        return variable;
    }

    public abstract void method();
}

// This is not fully necessary for this example
// but helps you see how to set the final value 
// in a sub class.
public class FinalSubclass extends FinalBase {

    public FinalSubclass(int variable) {
        super(variable);
    }

    @Override
    public void method() {
        System.out.println( getVariable() );
    }

    @Override
    public int getVariable() {

        return super.getVariable();
    }

    public static void main(String[] args) {
        FinalSubclass subclass = new FinalSubclass(10);
        subclass.method();
    }
}

Я думаю, що вагомою причиною було б моделювати "реальні" "змінні" об'єкти ", як інтерфейсні вікна. Я смутно пам'ятаю, як прочитав, що ООП був винайдений, коли хтось намагався написати програмне забезпечення для управління деякими вантажними портами.

Java, у багатьох випадках, мандатує об'єкти, що змінюються, наприклад, коли ви хочете порахувати або повернути щось відвідувачеві або запущеному, вам потрібні остаточні змінні, навіть без багатопотокової читання.