Would this class relationship be correct?

Question

I am currently studying about classes, more specifically class/UML relationship and I am doing it in C#. I would like to know if this code I wrote below is the most suitable or if there is a different and more efficient way to do it.

It is a very simple program that relates the classes: Bank, Current Account, Savings Account and Client (I apologize for the size of the code in the example);

using static System.Console;

public class Cliente
{
    private string nome;
    private float saldo;

    public Cliente(string nome)
    {
        this.nome=nome;
        saldo=0;
    }

    public string GetNome()
    {
        return nome;
    }

    public float GetSaldo()
    {
        return saldo;
    }

    public void SetSaldo(float atualizar_saldo)
    {
        saldo+=atualizar_saldo;
    }
}

public class ContaCorrente
{
    private Cliente cliente;

    public void AbrirConta()
    {
        cliente = new Cliente("João");

        cliente.SetSaldo(50.0f);
    }

    public void FecharConta()
    {
        cliente = null;
    }

    public void Sacar(float valor)
    {
        cliente.SetSaldo(valor);
    }

    public void Depositar(float valor)
    {
        cliente.SetSaldo(valor);
    }

    public Cliente GetCliente()
    {
        return cliente;
    }
}

public class ContaPoupança()
{
    private Cliente cliente;

    public void AbrirConta()
    {
        cliente = new Cliente("Maria");

        cliente.SetSaldo(100.0f);
    }

    public void FecharConta()
    {
        cliente = null;
    }

    public void Sacar(float valor)
    {
        cliente.SetSaldo(valor);
    }

    public void Depositar(float valor)
    {
        cliente.SetSaldo(valor);
    }

    public Cliente GetCliente()
    {
        return cliente;
    }
}

public class Banco
{
    private ContaCorrente conta_corrente;
    private ContaPoupança conta_poupança;

    public void IniciarContaCorrente()
    {
        conta_corrente = new ContaCorrente();

        conta_corrente.AbrirConta();
    }

    public void IniciarContaPoupança()
    {
        conta_poupança = new ContaPoupança();

        conta_poupança.AbrirConta();
    }

    public void InformaçõesDaConta()
    {
        WriteLine($"Nome do Cliente Conta Corrente: {conta_corrente.GetCliente().GetNome()}");
        WriteLine($"Saldo em sua Conta: {conta_corrente.GetCliente().GetSaldo()}");

        WriteLine($"Nome do Cliente Conta Poupança: {conta_poupança.GetCliente().GetNome()}");
        WriteLine($"Saldo em sua Conta: {conta_poupança.GetCliente().GetSaldo()}");
    }
}

public class MainProgram
{
    public static void Main(string[] args)
    {

        Banco banco = new Banco();
        
        banco.IniciarContaCorrente();
        banco.IniciarContaPoupança();

        banco.InformaçõesDaConta();

    }
}

My goal in this code was to test if it would work as I hoped it would, also better understand how relationships between classes work and how they should be done.

Answer 1

Programming involves fully understanding the problem and the techniques used. No precise information about the problem can’t be sure if it’s right or wrong. Decorate formulas to do, surely it’s wrong.

UML is probably learning some things the wrong way (for example will learn speak attribute where there is a field in real language), because it is a very conceptual form, I say this by looking at the code. At the same time there is no correct conceptualization for the above, that is, without accurate information we have to declare something fundamentally wrong.

Object orientation is more about understanding the problem and creating objects that make sense of this problem than memorizing language mechanisms, especially abstract languages like UML. And again, to create right objects you need to have complete understanding of the real problem, concrete, not an artificial problem.

OO depends on giving proper names to things, classify correctly.

float is not the correct type for monetary values.

C# has property and should use them properly, almost everyone uses getters/setters on automatic and misses (the link is just to start studying the subject). You should not allow updating a balance directly, just to give an example. GetCLiente() Sounds like the bureaucratic way to do it.

I wanted to talk to you about builder, but the class today is so meaningless it wouldn’t do any good, but it looks like it’s gonna use it the wrong way.

It doesn’t make sense to open an account with a name and a fixed amount, it might just be to start, but doing at least the right class contract is important to know if she and her relationships are right.

It seems to make less sense to nullify a field. The question is whether it should be null. In a modern version of language it is right not to accept until the domain demands it. You should seek another solution.

Classes tend to need some other auxiliary methods that are not part of the domain, but I’m not even going into it because the basics need to be tidied up.

Looks like you’d need an abstract class called Conta to serve as a basis for the other two concrete accounts. But it’s what I said, only with more concrete information to know if it’s to do it.

I can’t imagine how a customer can have balance. Who has this is the account.

Banco seems like a completely incoherent class, doesn’t seem like it should have that name or even if it should have everything in it. There may be a class to model a bank but it would be something very different from that.

If you’re gonna do something realistic, a bank is more complex than that. If you’re going to do something artificial that only you know, then everything in your head is right, and has little or zero value for real learning.

If you want to know about the customer account it may be more difficult with this model, but I can’t say it’s dead.

There are many basic mistakes to move forward with this. It seems like you are wanting to learn how to decorate a house when you have not yet learned how to lay a brick. I’d change the way you’re learning.