[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Junilu Lacar wrote:I would not jump to any conclusions regarding mocks in this case. The code OP has shown does not give us enough context.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Junilu Lacar wrote:I'll test the interaction between the service and the Authorizer later, if I even need to do that."
Rj Ewing wrote:just realized all the test say unAuthorized/Authorized, should be unAuthenticated/Authenticated
Rj Ewing wrote:I'm going to make it a priority to read through some of the books you've suggested to me in the past. I think I need to become more versed in TDD.
Junilu Lacar wrote:I don't even know how to read what the significance of the APP_ROOT parameter is.
Junilu Lacar wrote:Tests should be more explicit about how classes become related.
Junilu Lacar wrote:A direct causal relationship can be readily seen in that test code: In order for isGranted() to return true, you first have to call grant().
Junilu Lacar wrote:If you were TDD'ing in a pair or group, a good discussion with your mates might have made this clear.
Junilu Lacar wrote:
Rj Ewing wrote:just realized all the test say unAuthorized/Authorized, should be unAuthenticated/Authenticated
In that case, is there even a need to involve a project entity to check authentication?
Rj Ewing wrote:Currently in my design, the ProjectService doesn't handle the authorizing. This is all done in the Controller. My ProjectService is an abstraction layer where any db communication happens (between and other *Service classes and with the ProjectRepository). However, to determine if the user is a member of a project, I need to call the ProjectService as I need db access.
You can see the tests I've wrote below... I think my testing skills are lacking a bit
Junilu Lacar wrote:
All this raises a series of questions. Why is authorizing done in the Controller? Did you mean initiated/coordinated instead? Authorizing seems more like a responsibility of something like ProjectAuthorizer, doesn't it? Why does a Service layer object like ProjectService have to be called to get to DB information about project authorization? Shouldn't information about authorization go through something like an AuthorizationRepository instead? Do you need to call the ProjectService because it makes more sense to go through a ProjectService or because the design just happens to be like that right now? Would the design make more sense if we cut the ProjectService out of the picture, at least when it comes to authorization of the user?
Junilu Lacar wrote:The tests suggest you should work on understanding design principles and recognizing design smells more.
Rj Ewing wrote:If the user knows what projects it is a member of, and the project know which users are member, I think this would be a code smell, based on DRY or duplicate knowledge. Is that correct?
I read through the 4 rules of simple design today. It was interesting. Some of it I've heard before, however I definitely need to keep referencing the design patterns until they become engrained. Do you have suggestions on ways to better understand common design patterns? I was thinking it might be helpful to create a checklist that I could constantly refer to while coding until they become second nature.
Junilu Lacar wrote:
I'd have to examine some code to say for sure but it might. In these cases, it's usually a good idea to factor that knowledge out to something that falls under what Peter Coad calls a Moment-Interval Archetype in his writings about Modeling in Color.[\quote]
I'll have to read about the Moment-Interval Archetype.
Junilu Lacar wrote:Also, there's a big difference between design patterns and design principles; make sure you know what the difference is.
Ya, I meant principles. I would think I would be better off getting the principles down first, then start looking at patterns.
Rj Ewing wrote:I agree that it doesn't make sense for the project to know about the authorization of the user, but why would it not know about which members are users of the project? It seems like it would make more sense for the project to know what it members are, and not the authorizer. The authorizer would just need to use the member information, along with other information to grant authorization to a user.
Junilu Lacar wrote:Would it be better to separate the concern of authorization into a Security Module for instance, where a ProjectAuthorizer resides and presides over decisions that have to do with project and user relationships as it pertains to securing the application? If you do that, the Project and User classes can focus on the relationships and behaviors that are directly related to the problem domain.
Junilu Lacar wrote:I'd have to examine some code to say for sure but it might. In these cases, it's usually a good idea to factor that knowledge out to something that falls under what Peter Coad calls a Moment-Interval Archetype in his writings about Modeling in Color.
Rj Ewing wrote:Then would it be a good idea to have only the Project be aware of it members and the User is not aware of their Projects?
Junilu Lacar wrote:Does that make sense?
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |