I'm new to java programming and my project is about banking management system where customers withdraw, deposit and even check balances depending on the types of account. I just need explanation of how Account class, SavingsAccout class, CheckingAccount class can be together in a single file. Please throw me bones, genius!

public class Account{

}
class SavingsAccount{

}
class CheckingAccount{

}

this should work in one file

Bambillo:
I'm new to java programming and my project is about banking management system where customers withdraw, deposit and even check balances depending on the types of account. I just need explanation of how Account class, SavingsAccout class, CheckingAccount class can be together in a single file. Please throw me bones, genius!

jamesunum:
public class Account{
} class SavingsAccount{
} class CheckingAccount{
}
this should work in one file

Ok. Let me try this and will get back.

The first problem should be the WHY and not the HOW. HOW can easily be googled, so i wont be doing you justice by just telling you how (FYI the concept is called inner classes in Java). So allow me touch on the WHY before the HOW. PS: They don't need to be in the same file, it always better to separate your concerns in Java parlance.

That said, I'm going to try to be as practical as possible without dwelling too much about specifics. For more details i suggest you do an initial read on OOP and then more specifically OOP in java.

You know like they say in OOP "Every thing is an Object". Focus on your problem, if everything is an object, then all the types of account should be objects, meaning they will all require a class. All the classes have things in common apart from just being an type account. Lets say, for each of them:
- All account types are created by providing an initial amount.
- They should be able to carry out the following actions..say for example deposit and withdraw only.
- Also, each class should be able to keep track of their balance
- Finally, lets assume the only difference between checking and savings account is the limit on withdrawal. In checking account your minimum balance is 10k, so this needs to be ensure when opening the account and during withdrawal for checking accounts.

In OOP since they all have basic functionalities that they share, it implies that they should share a base class or an interface. But because we want to share some of the core functionalities (specifically codes) amongst all the account types we'll go for an abstract class(meaning the class cannot be instantiated on its own unless inherited)

So we''ll create a class called Account and implement everything the accounts have in common within and make the required functions that they carry out differently abstract:

abstract public class Account{

// **similarity - Each class should be able to keep track of their balance
// ** secondly we make it protected so child classes can access it and use it for withdrawal
Protected double balance

// **similarity - All account types are created by providing an initial amount. So we can implement it in the Base constructor.
public Account(float initialDeposit){
balance = initialDeposit;

}

// To satisfy Encapsulation in OOP we provide a getter to the account
// Notice how we've provided only a public getter and no setter
// we dont want people tampering with the balance from outside, so we
// keep it internal
public float getBalance(){
retrun this.balance;
}

// **similarity - The protocol for deposit is the same
// for that reason we implement it it the base class
public void deposit(float amount){

balance += amount
}

// This is specific to account types so we make it abstract:
// - First it ensures that all account types implement it
// - It allows all account types to implement them the way the want
abstract public void withdrawal(float amount);
}

I need some feedback, so I'm going to stop here for now. Just to make sure you understand so far. When I get a response I'll go further.

I made an app like that but its command line based.
I had a main class for calling the object, and another account class where methods like checkacc, validateacc, debitacc, creditacc etc are.

cool

see my signature

kudaisi:
The first problem should be the WHY and not the HOW. HOW can easily be googled, so i wont be doing you justice by just telling you how (FYI the concept is called inner classes in Java). So allow me touch on the WHY before the HOW. PS: They don't need to be in the same file, it always better to separate your concerns in Java parlance.

That said, I'm going to try to be as practical as possible without dwelling too much about specifics. For more details i suggest you do an initial read on OOP and then more specifically OOP in java.

You know like they say in OOP "Every thing is an Object". Focus on your problem, if everything is an object, then all the types of account should be objects, meaning they will all require a class. All the classes have things in common apart from just being an type account. Lets say, for each of them:
- All account types are created by providing an initial amount.
- They should be able to carry out the following actions..say for example deposit and withdraw only.
- Also, each class should be able to keep track of their balance
- Finally, lets assume the only difference between checking and savings account is the limit on withdrawal. In checking account your minimum balance is 10k, so this needs to be ensure when opening the account and during withdrawal for checking accounts.

In OOP since they all have basic functionalities that they share, it implies that they should share a base class or an interface. But because we want to share some of the core functionalities (specifically codes) amongst all the account types we'll go for an abstract class(meaning the class cannot be instantiated on its own unless inherited)

So we''ll create a class called Account and implement everything the accounts have in common within and make the required functions that they carry out differently abstract:

abstract public class Account{

// **similarity - Each class should be able to keep track of their balance
// ** secondly we make it protected so child classes can access it and use it for withdrawal
Protected double balance

// **similarity - All account types are created by providing an initial amount. So we can implement it in the Base constructor.
public Account(float initialDeposit){
balance = initialDeposit;

}

// To satisfy Encapsulation in OOP we provide a getter to the account
// Notice how we've provided only a public getter and no setter
// we dont want people tampering with the balance from outside, so we
// keep it internal
public float getBalance(){
retrun this.balance;
}

// **similarity - The protocol for deposit is the same
// for that reason we implement it it the base class
public void deposit(float amount){

balance += amount
}

// This is specific to account types so we make it abstract:
// - First it ensures that all account types implement it
// - It allows all account types to implement them the way the want
abstract public void withdrawal(float amount);
}

I need some feedback, so I'm going to stop here for now. Just to make sure you understand so far. When I get a response I'll go further.

Kudaisi, you really made my day! You must be a genius!!. Your explanation is succinct and unambiguous. Are you in Abuja? 08030696621 is my number....we can chat,bro. Thank you.

kudaisi:
The first problem should be the WHY and not the HOW. HOW can easily be googled, so i wont be doing you justice by just telling you how (FYI the concept is called inner classes in Java). So allow me touch on the WHY before the HOW. PS: They don't need to be in the same file, it always better to separate your concerns in Java parlance.

That said, I'm going to try to be as practical as possible without dwelling too much about specifics. For more details i suggest you do an initial read on OOP and then more specifically OOP in java.

You know like they say in OOP "Every thing is an Object". Focus on your problem, if everything is an object, then all the types of account should be objects, meaning they will all require a class. All the classes have things in common apart from just being an type account. Lets say, for each of them:
- All account types are created by providing an initial amount.
- They should be able to carry out the following actions..say for example deposit and withdraw only.
- Also, each class should be able to keep track of their balance
- Finally, lets assume the only difference between checking and savings account is the limit on withdrawal. In checking account your minimum balance is 10k, so this needs to be ensure when opening the account and during withdrawal for checking accounts.

In OOP since they all have basic functionalities that they share, it implies that they should share a base class or an interface. But because we want to share some of the core functionalities (specifically codes) amongst all the account types we'll go for an abstract class(meaning the class cannot be instantiated on its own unless inherited)

So we''ll create a class called Account and implement everything the accounts have in common within and make the required functions that they carry out differently abstract:

abstract public class Account{

// **similarity - Each class should be able to keep track of their balance
// ** secondly we make it protected so child classes can access it and use it for withdrawal
Protected double balance

// **similarity - All account types are created by providing an initial amount. So we can implement it in the Base constructor.
public Account(float initialDeposit){
balance = initialDeposit;

}

// To satisfy Encapsulation in OOP we provide a getter to the account
// Notice how we've provided only a public getter and no setter
// we dont want people tampering with the balance from outside, so we
// keep it internal
public float getBalance(){
retrun this.balance;
}

// **similarity - The protocol for deposit is the same
// for that reason we implement it it the base class
public void deposit(float amount){

balance += amount
}

// This is specific to account types so we make it abstract:
// - First it ensures that all account types implement it
// - It allows all account types to implement them the way the want
abstract public void withdrawal(float amount);
}

I need some feedback, so I'm going to stop here for now. Just to make sure you understand so far. When I get a response I'll go further.

I swear I also need your number, mine is 08104422662

Bambillo:


Kudaisi, you really made my day! You must be a genius!!. Your explanation is succinct and unambiguous. Are you in Abuja? 08030696621 is my number....we can chat,bro. Thank you.

Glad you think so of me. Unfortunately, I'm in Lagos. But, hey! everybody is online these days. I'll check on you.

SilverG33k:


I swear I also need your number, mine is 08104422662

I'll call bro.

@kudaisi, you made valid point but took it beyond the scope of OP's question.

@Bambillo, the first reply is valid one. Just add the member classes or 'inner classes' after the public class but don't modify them with the keyword "public".

Member classes are good for situations where u want to create smaller classes that are only used by the public class within that file. I use it to create temporary objects also.

While at it also remember to implement error handling for users who enter wrong information. E.g they enter a string instead of an integer or float. That would be in your method main. In c# it would be something like:

Write("Please enter deposit amount: ";
If( int.tryParse(ReadLine(), out int deposit){
depositMethod(deposit);
}else{
Write(" Invalid entry. Please enter a numerical amount: ";
}

So write the Java equivalent of that etc...

Hope it's helpful

kaypompee:
While at it also remember to implement error handling for users who enter wrong information. E.g they enter a string instead of an integer or float. That would be in your method main. In c# it would be something like:

Write("Please enter deposit amount: ";
If( int.tryParse(ReadLine(), out int deposit){
depositMethod(deposit);
}else{
Write(" Invalid entry. Please enter a numerical amount: ";
}

So write the Java equivalent of that etc...

Hope it's helpful

That is validation.
Java has good validation and exception support.