Почему мы создаем объекты, которые не имеют функциональности?

Question

Я вроде как новичок в oop, и я думал, что будет причиной создания объекта (например, банковского счета или адреса клиента), который не имеет никакой функции, кроме методов свойств для установки и получения данных? например, в реальном времени адрес клиента не является даже физическим объектом или даже банковским счетом в эти дни, поэтому почему ppl должен создать версию программного обеспечения этих объектов?

спасибо заранее

Answer 1

Причина в том, что они являются реальными вещами в мире, которые имеют свойства, и что мы взаимодействуем с. Вся идея, лежащая в основе oop, составляет модель мир как есть - с точки зрения свойств и взаимодействий. Таким образом, хотя адрес или банковский счет не обязательно является чем-то физически осязаемым, однако что-то существует, имеет свойства и что мы взаимодействуем с. Обычно мы хотим моделировать то, что можно рассматривать как более или менее независимые объекты, которые имеют свойства и которые мы взаимодействуем с.

Пример банковского счета: У банковского счета есть свойства: у него есть номер счета, баланс, владелец, список транзакций. И мы взаимодействуем с ним: мы делаем депозиты, делаем снятие денег и т. Д. Поэтому мы моделируем его как объект с этими свойствами и действиями (методами). Не позволяйте слову «объект» ограничивать ваше мышление только тем, что ощутимо. «Объект» может быть объектом, который имеет свойства и с которым вы можете взаимодействовать. Чтобы продлить это немного дальше, «владельцем» банковского счета также должен быть объект. Поскольку у владельца есть свойства: имя, адрес, номер телефона и т. Д. Банк может взаимодействовать с владельцем и наоборот.

Чтобы добавить и, возможно, быть более конкретным для вашего вопроса, почему мы создаем объекты, «которые [не имеют] функции, кроме методов свойств» ... Давайте отменим тот факт, что на данный момент банковский счет есть методы действия (депозит, вывод) в дополнение к методам собственности ... создание объекта «банковской учетной записи», который, допустим, действительно имел только методы свойств (для получения и установки свойств), все же дает нам объект, с которым мы можем взаимодействовать , Тогда у нас есть возможность, например, перевести банковский счет (как единое целое) от одного лица другому, или от одного филиала банка к другому. Это также дает нам возможность создать целую коллекцию банковских счетов (например, вектор или карту) для представления всех банковских счетов в конкретной отрасли или принадлежащих конкретному клиенту. НТН.

---

В ответ на ваш комментарий вопрос

... но на самом деле банк счета не депонировать/снимать деньги, это кассир банка (реальный человек или онлайн-банкинг ворота). ..

Я не уверен на 100%, я понимаю ваш комментарий, но сделаю снимок. В двух концепциях, которые мы также подчеркиваем: «абстракция» и «свободная связь» - абстракция скрывает детали реализации от частей программы, которые не нуждаются в ней; и свободная связь, означающая, что каждый класс стоит сам по себе, и ему не нужно много знать о других классах, поэтому, если один класс изменяется, то классы, которые используют или взаимодействуют с этим классом, также не нуждаются в изменении (кроме они хотят воспользоваться некоторыми новыми функциями, но если им все равно, все остается обратно совместимым).

Для примера вашего Teller или менеджера аккаунта иногда дизайн программы упрощается созданием такого класса, который управляет большей частью работы программы. Это, однако, должно быть сбалансировано с концепциями абстракции и свободной связи. Если вы дадите банковскому счету методы под названием makeDeposit() и makeWithdrawal(), то «любой» может внести депозит или снятие средств: клиент, кассир, атм и т. Д., И вам не нужно понимать детали о том, что происходит внутри класса BankAccount (например, поддерживая средний баланс и подсчитывая количество дней, чтобы получить проценты и т. д.). Если класс Teller владеет методом makeDesposit, то Teller должен понимать детали BankAccount, нарушая принципы абстракции и свободной связи (теллер тесно связан со Счета).

С другой стороны, если вы действительно чувствуете необходимость иметь класс Teller в своей программе, один из способов справиться с этим и сохранить абстракцию и ослабление связи - это сделать метод makeDeposit Teller просто перенаправлением работы на класс BankAccount (путем вызова makeDesposit на учетной записи). Это правда, что BankAccount фактически не делает депозиты, поэтому, возможно, это просто вопрос выбора лучшего имени для этого метода. Возможно, вызовите метод BankAccount «acceptDeposit()» или «hasDespositMadeToMe()». Это просто именование деталей. Однако реализация должна позволить клиенту вносить деньги в BankAccount без необходимости беспокоиться об обновлении внутренних данных этого банковского счета (например, о среднем балансе и дате депозита, количестве дней процентов за каждый средний остаток с течением времени и т. д.). Поэтому, так или иначе (или с одним или несколькими именами), сам BankAccount в идеале должен иметь способ для внесения и снятия денег. Таким образом, другим классам (включая Teller или AccountManager) не нужно беспокоиться о внутренностях BankAccount при внесении депозита. Назовите этот метод тем, что хотите. На самом деле, вы можете утверждать, что BankAccount и Teller оба do не делают депозиты, а только «принимают» их; и что в конечном итоге только заказчик производит депозиты. Опять же, просто называя. НТН.

Наконец, на родственном, но другой точки, имейте в виду, что идея состоит в том, чтобы модели в мире (не дублировать). Иногда, чтобы поддерживать простую программу, мы не обязательно моделируем каждую деталь мира; только те детали, которые необходимы для выполнения прецедентов, которые мы хотим, чтобы наша программа обрабатывала. (Так, например, мы можем оставить кассира и просто позволить клиенту непосредственно делать депозит или выходить без посредника). Все зависит от вариантов использования, которые мы должны использовать с нашей программой. В целом, проще, чем проще, если не просто сделать то, что мы хотим, чтобы программа не выполняла.