This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

If roles should be implemented with interfaces, how assign them dynamically in webapp

 
Jochen Szostek
Ranch Hand
Posts: 42
Android Google Web Toolkit Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, I read that inheritance defines what you are and interfaces define what roles you have.

But if you want to create a webapp where users can have different roles, those roles sometimes should be assignable (dynamically) during runtime.
E.g. when a user adds a role to his profile.

In my case if users have more roles they should contain more info (have additional records).

But since implementing interfaces is something that has to be done during compile time it seems that I have to implement all possible roles (interfaces) in my user object, and just leave the unused role dependent records blank. But this seems quite inefficient to me.

What would be the most suitable approach for this situation?

Thanks a lot in advance and have a nice day!

Jochen
 
Ulf Dittmer
Rancher
Pie
Posts: 42966
73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I read that inheritance defines what you are and interfaces define what roles you have.

Without further context, this statement doesn't make sense to me. Can you point us to the source, or give examples of the kinds of interfaces involved?

It also doesn't seem to be true. User names, password and roles are often represented as strings; for example, that's how web app security sees it (see this for how one implementation -Tomcat- deals with that).

It's true that the Java security infrastructure is based on interfaces (as opposed to concrete classes) - have a look at the java.security.* and javax.security.* packages, which are full of interfaces. But those interfaces are generic, and rarely need to be tailored for a particular implementation. Maybe that's what the statement meant?
 
Jochen Szostek
Ranch Hand
Posts: 42
Android Google Web Toolkit Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ulf Dittmer:

Without further context, this statement doesn't make sense to me. Can you point us to the source, or give examples of the kinds of interfaces involved?

It also doesn't seem to be true. User names, password and roles are often represented as strings; for example, that's how web app security sees it (see this for how one implementation -Tomcat- deals with that).

It's true that the Java security infrastructure is based on interfaces (as opposed to concrete classes) - have a look at the java.security.* and javax.security.* packages, which are full of interfaces. But those interfaces are generic, and rarely need to be tailored for a particular implementation. Maybe that's what the statement meant?



Thanks a lot for the fast reply!

Well I'm thinking about roles that are not specifically related to security / access levels. I want to make users able to add roles as being profiles.

E.g. users can add a dj or (music)producer profile to their user profile.


And the statement I used was derived (hopefully correct) from:

On page 118 (Chapter 2: Object Orientation) of the "SCJP for Java 5 study guide" (by Bert Bates and Cathy Sierra) you can find this sentence:

"But remember that subclassing defines who and what you are, whereas implementing defines a role you can play or a hat you can wear, despite how different you might be from some other class implementing the same interface (but from a different inheritance tree)."

Thanks again for the help. Really appreciate it.

Greets,

Jochen
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



An instance of OnlineStore is a Store. It can serve in the "role" of a StoreFront as well.



The sf object is a Store and also plays the "role" of a StoreFront.
 
Ulf Dittmer
Rancher
Pie
Posts: 42966
73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that statement tries to explain the difference between subclasses and interface -which of them might be used in what circumstance-, and is not a statement about roles in a security context.
 
Jelle Klap
Bartender
Posts: 1951
7
Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jochen Szostek:

And the statement I used was derived (hopefully correct) from:

On page 118 (Chapter 2: Object Orientation) of the "SCJP for Java 5 study guide" (by Bert Bates and Cathy Sierra) you can find this sentence:

"But remember that subclassing defines who and what you are, whereas implementing defines a role you can play or a hat you can wear, despite how different you might be from some other class implementing the same interface (but from a different inheritance tree)."


You took this sentence completely out of context I'm affraid
It has no bearing whatsoever on information security.

Edit: Too slow.
[ August 14, 2008: Message edited by: Jelle Klap ]
 
Jochen Szostek
Ranch Hand
Posts: 42
Android Google Web Toolkit Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So I guess that if a user can add multiple profiles/roles to his user profile, it should not be implemented as interfaces because they can't be assigned during runtime?

I was already programming the structure of the user object with a collection that can contain profile/role objects for that user, but the sentence I quoted confused me because I interpreted it as "roles should be implemented as interfaces".

Thanks again and greets,

Jochen
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That sentence is referring to the roles the objects play in the system, not to user roles - both ArrayList and LinkedList can play the role of a List.
 
Ulf Dittmer
Rancher
Pie
Posts: 42966
73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So I guess that if a user can add multiple profiles/roles to his user profile, it should not be implemented as interfaces because they can't be assigned during runtime?

Modeling roles as interfaces might still be OK if the set of roles is fixed, and doesn't change over time. But if new roles are added (not to a user - to the system as a whole), you'd have to add a new interface. That would get tiresome quickly.

So the question is not so much whether a user gets assigned a different set of roles, but whether the system allows completely new roles to be introduced. If it does, modeling them through interfaces isn't a good idea.
 
Jochen Szostek
Ranch Hand
Posts: 42
Android Google Web Toolkit Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aha. Now it's all clear to me.



Really appreciate all the help.

Greets,

Jochen
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic