objektorienterade principer

En klass ska bara ha ett jobb. Savingsaccount låter som det representerar en kunds konto, uträkningarna bör därför ligga separerade från dessa. Savingsaccount ska endast hålla reda på kontonr, vilken kund det tillhör, räntan på kontot, saldo, bonusar etc.

Vet inte hur det ser ut i Java, men i C# hade du kunnat göra en statisk klass som heter typ AccountCalculations, där du definerar dina metoder och tar emot ett(eller flera) konton som parameter och returerar ett värde.

Sen i din business-logic klass och metod för att stänga ett konto anropar du det vid en validerad stängning (namn kan du få se över ),

var remainingValue = AccountCalculations.CloseCustomerAccountsReturns(Customer.SavingAccounts);

Alternativt att det är abstraherat till ett interface och att din business klass endast refererar det, t.ex. IAccountCalculator sen sätter du upp det med dependency injection. Då blir det mycket enklare att skriva tester för logiken. Men det är nog överkurs i detta fall.

Om det är en skoluppgift och du är begränsad till dessa tre klasser tänker jag ungefär såhär:
Banklogic (borde vara BankLogic för övrigt) -
Jag beskriver vad en bank kan göra

Customer -
Jag beskriver vad en customer har för egenskaper (eller vad en customer är)

SavingsAccount (CamelCase här också) -
Jag beskriver vad ett sparkonto har för egenskaper

Uppsättningen får mig att tänka på MVC (Model View Controller) designmönstret.
I det så har du en model som håller information om objekten, controller som manipulerar objekten, och slutligen view som presenterar objektet.

Hoppas det skapar någon förståelse!

Det beror på situationen, om close ska vara en metod på Account så innebär det att Account ska hålla reda på sitt saldo och även funktionalitet för hur det ska stängas. Låter väl lite märkligt att ett konto kan stänga sig själv?

En klass ska bara ha ett jobb, Account lär vara en POCO som fylls via en databas och representerar en kunds konto. Uträkningar och principer kring stängning sker via affärslogikslagret för applikationen inte direkt i ditt domain objekt.

Om t.ex. en stängning också ska skicka ett mail/sms som bekräftelse till kunden, ska denna logik också ligga i account.close()?
Även om det refererar till abstraktioner så känns det som att account just nu gör mycket mer än vad ett account ska göra.

Snarare bör ett servicelager anropas, där kontonummer, tillsammans med den behöriga kundens ID (efter authenticering) utför ärendet.

AccountService.CloseAccount(account);

Detta i sin tur kommer validera stängningen och anropa datalagret och eventuella SMS / Emailstjänster.
Då har du fått bort all logik från account och account representerar istället bara information om just det kontot, som det bör göra.

Det där är endast ett väldigt basic exempel som är en introduktion till klasser för en nybörjare.
I verkligheten skriver du alltid till en databas så det finns ingen mening att en insättning ska se i klassen BankAccount.

BankAccount ska bara vara en simpel POCO som representerar ett konto.
Tycker du att BankAccount ska referera ditt datalager för att sätta in datan? Läs på om clean architecture.

Att Stream har en Close är helt logiskt, då du har en öppen socket och låser en fil och behöver stänga läsningen och disposa ditt objekt.

Du ber ju inte ditt konto att stänga sig, du kontaktar banken och ber dem stänga ditt konto.
Men läser du en bok så väljer du själv när du slutar läsa och stänger boken.