Hello Ben,
I think the purpose of this exercise was to practice expecially
things like encapsulation and thinking in classes.
So I think it's not a big deal to have a setter and a method to
check if the passwords are matching.
Roelof,
There are still ways to avoid that. For example, consider a method such as Customer>>addAccountWithPassword: and Account>>#changePasswordFrom:to:. No need for setters and getters and no exposure to unauthorized password changes.
[Of course, this doesn't handle the "I've forgotten my password" scenario, but Account>>#changePasswordTo:usingAuthorizationToken: might.]
I think the exercise is more about APIs than it is about every little detail of an exercise reflecting best practices in the corresponding real world scenario. But, understanding that there are those issues is crucial, as we see almost daily with news of security breaches.
I don't think anyone would argue that completing this exercise should suddenly make you qualified to develop a banking application. :-)
Roelof
Op 19-8-2019 om 18:35 schreef Ben Coman:
Thanks
all for the answers.
As I see it , it impossible to store the password in the
bankaccount object and make safe code to use it,
So some one give me a stupid assignment.
That would seem to depend on the purpose of the
assignment.
�� a. To produce production ready code that managed
someone's real life money,
�� b. Provide a vehicle to reason about typical
implementation issues, in which case did you learn anything
from the exercise?
cheers -ben