Public vs Private

Question

Ниже приведен код Java, который я использовал как практику для класса. У меня есть класс с именем SavingsAccount. Он имеет балансовые и процентные переменные. Тем не менее, я установил их для публики, но если я хочу рассматривать учетные записи отдельно, мне нужно сделать их частными и иметь методы «get/set» для этих переменных? Могу ли я просто уйти от него, имея переменные? Остальные коды имеют методы, которые вычисляют с использованием этих переменных.

public class SavingsAccount { //This class has three different variables that define it 
    public double balance; //Double for account balance 
    public static double annualInterestRate; //Class method for interest rate 
    public final int ACCOUNT_NUMBER; //Constant int for keeping track of accounts 


public SavingsAccount (int ACCOUNT_NUMBER, double balance) { //Constructor that takes down account number and balance to keep track of 
     this.ACCOUNT_NUMBER = ACCOUNT_NUMBER; 
     this.balance = balance; 
    } 

Answer 1

Однако, я поставил их на публику, но если я хочу, чтобы обработать счета индивидуально, мне нужно, чтобы сделать их частными и имеет «Get/Set» методов для этих переменных?

Во-первых, каждый экземпляр вашего класса рассматривается как отдельный SavingAccount.

SavingAccount acct1 = new SavingAccount(....); //represents one Saveing account 
SavingAccount acct2 = new SavingAccount(....); //represents another Saveing account 

На самом деле не имеет значения, если ваши атрибуты отмечены как public, так и private. обычно, если вы хотите инкапсулировать свой класс, вы делаете свои атрибуты частными и используете общедоступные методы getter/setter, чтобы другие объекты не могли напрямую обращаться к вашему атрибуту. они смогут получить доступ к ним только через getter/seters.

Answer 2

Сво хорошая идея, чтобы сделать поля для частных Encapsulation данных. Инкапсуляция данных - это практика ограничения и контроля доступа к полям для предотвращения нежелательных действий программистов. Если вы этого не сделаете, программист может получить доступ или изменить переменную в экземпляре неконтролируемым способом, который может нарушить работу. Другими словами, контроль доступа к переменным затрудняет нарушение и ввод ошибок.

В принципе, ваши классы должны работать как «черный ящик». Извне другой программист не может видеть и не заботится о том, как работают внутренние (то есть частные поля). Вы можете взаимодействовать только с этим полем, используя явно объявленные операции (т. Е. Общедоступные методы). При необходимости эти операции будут манипулировать внутренними элементами.

Конечно, вы можете делать все, что хотите.

Answer 3

Если вы определяете переменные public, они напрямую доступны/устанавливаются.
Если вы определяете их как частные, вам нужны геттеры и сеттеры.

Управление доступом желательно, объявите их приватными.

Answer 4

Вы, конечно, может иметь переменные как общественности, но есть много людей, которые здесь будут охотиться тебя за это ...
Это вопрос encapsulation в парадигме ОО. Как правило, объекты не должны мешать друг другу.

Answer 5

Его хорошо сделать частным. Скажем, я обращаюсь к вашему классу и устанавливаю значения, как показано ниже.

SavingsAccount sa = новый SavingsAccount (12345,25000);

теперь я могу установить свой баланс с помощью объекта непосредственно, как следует ниже:

sa.balance = -300;

sa.ACCOUNT_NUMBER = 6789;

В вашем классе нет безопасности. Это важная концепция в ООП, называемая инкапсуляцией данных.

Answer 6

Если вы не выполняете какую-либо проверку при установке значений (т. Е. Баланс не является отрицательным), используйте, если это возможно, public.

Создание и сборщик для атрибута, который возвращает или присваивает значение, без дополнительной логики фактически предоставляет ваш атрибут как public и обеспечивает ненужный беспорядок в коде (с точки зрения удобочитаемости). Использование открытых атрибутов делает код более чистым.

Пример 1:

* Вы хотите, чтобы зарегистрироваться, чтобы только иметь положительный баланс. Вам нужно будет выполнить проверку, чтобы определить, назначаете ли вы ее отрицательное значение КАЖДЫЙ раз, когда вы назначаете ей значение.

Лучшее место для этого было бы в методе сеттера. Это избавит вас от неприятностей, связанных с необходимостью положить много ошибок if(newBalance < 0).

Для обеспечения того факта, что вы хотите только положительные значения баланса, вы делаете атрибут private. Это ограничивает программистов, которые могут захотеть присвоить отрицательное значение атрибуту balance (*). Чтобы снова получить значение, сохраненное в атрибуте баланса, вам нужно будет добавить получателя для частного значения.

У вас теперь есть «какой-то» атрибут public, на котором вы применяете ограничения (не будучи установленными как отрицательные).

Пример 2:

Вы хотите, чтобы делать заметки на каждом счете. В вашем классе будет атрибут String notes;.

Если нет ограничений, которые вы хотите применить, лучше всего использовать модификатор public.

Рассмотрим, какие из следующих фрагментов кода чище:

accountA.setNotes(accountB.getNotes()); 

или

accountA.notes = accountB.notes; 

Они оба скопировать notes с одного счета на другой, но последний легче читать.

Answer 7

Всегда рекомендуется устанавливать некоторые поля private вместо public.
Потому что, используя надлежащие методы для доступа к ним, обеспечивается четкий код и меньше ошибок.
Просто подумайте о себе, кто-то хочет узнать номер вашего счета, чтобы дать вам подарок в виде наличных денег.
Что вы предпочтете либо Человек, который вас спрашивает, и получите ваш A/C. Нет или вы публично объявляете свой номер A/C, и человек получает сам A/C No., не сообщив вам.
Первый, кажется, делает это private и использует методы get/set.
Второй, похоже, делает это public.

Answer 8

Я думаю, что можно указать два отдельных случая, в которых вы хотите, и где вы не хотите использовать публичные поля.

Первый - это когда вы используете неизменяемые структуры данных. Я полностью убежден, что неизменные структуры данных - это то, к чему вы хотите стремиться. Плюсы и минусы неизменяемых структур можно найти в другом месте; в отношении публичных полей неизменные структуры предлагают очевидную вещь - сделать все поля общедоступными. Ну, структура неизменна, поэтому вы можете читать только значения. В этом случае геттеры совершенно не нужны и только загромождают ваш код.

И, во-вторых, очевидно, что когда вы используете изменяемые структуры. В этом случае использование геттеров и сеттеров оправдано; вполне возможно, что вы ставите какую-то логику в сеттерах, а инкапсуляция полей данных здесь обязательна: вы действительно не хотите, чтобы кто-то случайно менял ваши данные. Однако я считаю, что изменчивые ДТО являются злыми, и их следует избегать; единственная причина, по которой я вижу их использование, - это совместимость с некоторыми API, такими как Hibernate.

Вы также должны скрывать поля, когда они содержат внутреннее состояние, в котором вы не хотите, чтобы кто-либо имел доступ. Это относится к классам, реализующим какое-либо поведение (услуги, DAO и т. Д.). В этом случае вы обычно не хотите даже создавать геттеры и сеттеры.

Итак, вкратце, я бы посоветовал использовать неизменяемые объекты с открытыми полями как ваши DTO и сделать классы поведения, которые работают на этих DTO как можно более закрытыми.