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