Defining class methods in the "deeper levels" of a class

I would like to be able to define class A in such a way that the command A=A.B.Method will be able to modify properties A.PropA and A.B.PropB. The closest I've gotten is by defining B2 as it's own class, and defining a property of A as "B=B2", but I have to use the command A.B=A.B.Method, and I'm not able to modify properties of A. It seems like I may be able to accomplish this or something similar using superclasses and/or object handles or maybe anonymous function handles, but I'm new to defining MATLAB classes and to OOP in general so I can't quite figure it out.

Answer 1

[Jeff Miller]

A toy example might be needed to make it clearer what you are after, but I guess you want a class A which has as two of its properties a variable PropA and an object B.

If that's right, then it wouldn't be good OOP to have a call to B modify PropA, even if that is possible.

It would be better to make PropA a function (of A) that simply calls the function of B (call it "GiveMePropA") that returns the value you want PropA to have. If GiveMePropA is expensive to compute, you might just have A call it whenever needed and store its value.

[Philip M]

I would like to create class Budget which contains properties like Bills, Loans, BankAccounts, etc. which would each be defined as their own class. For example, Bills would have properties Name, PaymentAmount, and DueDay that would each contain information about different bills. DIfferent methods would need to exist to create and modify those properties, and those methods would differ between classes. Bills would have New to create new bills, Modify to modify existing bills, etc. and class Loans would also have methods New and Modify, but would also have something like NewStatement to add a new statement into the record of a given loan. Budget would also have methods like Transfer that aren't specific to any of those subclasses, and properties like Equity that would calculate a value based on the information within the subclass properties. I would then have a long running Ledger file that would contain a list of method calls which would be updated as transfers occur, accounts are added and removed, etc.

The main priorities I'm going for in implementing this are:

1. Top prioritiy is for the Ledger entries to be as simple as possible. If I have to make a mess behind the scenes as a tradeoff then so be it.
2. Second priority is for the class definition of Budget to be a simple as possible. Each subclass will have it's own methods, New, Modify, Delete, NewStatement, etc. and I'd like for those methods to be defined in each subclass rather than in Budget. If I need properties and/or methods within Budget to call the subclass methods then that's ok, but I would like to avoid having a unique property/method in Budget for every single subclass method if possible.

I have some ideas based on your response I'm going to try to run with, but like I said I'm new to OOP so if there's some better method for doing all this that I'm missing then please feel free to let me know.

[Jeff Miller]

Kowabunga that sounds complicated--certainly well beyond any OOP I've done. Is your idea to have an abstract Ledger class and then descend Bills, Loans, etc from that, so that the Budget class is just a list of Ledger objects?

[Philip M]

I was thinking the Ledger would be a .m file, but what I'm ultimately trying to accomplish is for all the budgeting and financial information to be contained in a single object. The Budget object will be the top of the heiarchy though, so maybe Ledger would be a property of that? I'm not sure, I'll have to put some thought into it. I'm also doing this as practice for learning how to use OOP in MATLAB, so I'll probably just try some different things and see what I like best.

EDIT: Actually, I guess the root of what I was trying to do was to organize the methods of Budget a little better. So instead of having methods Budget.NewBill, Budget.ModifyBill, Budget.NewLoan, Budget.NewLoanStatement, etc. I would rather group those methods and instead call them using Budget.Bill.New, Budget.Bill.Modify, Budget.Loan.New, Budget.Loan.NewStatement, etc. Bill and Loan don't necessarily have to be their own classes, that just seemed like the most practical way to do it at first. I would actually prefer to only define one class, Budget, if possible.