Hello,

Thanks for these nice words.

i do not think after this one im a qualified developer , I still have to learn a lot.

Roelof





Op 19-8-2019 om 19:54 schreef Richard Sargent:

On Mon, Aug 19, 2019 at 9:40 AM Roelof Wobben <r.wob...@home.nl> wrote:
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:


On Mon, 19 Aug 2019 at 22:19, Roelof Wobben <r.wob...@home.nl> wrote:
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



Reply via email to