Can my class diagram handle switching between buyer and seller roles for logged-in customers?

Question

I'm having a problem expressing two different sessions in a class diagram:

On e-commerce website we must provide one account for the customer that allows him to sign-up as a seller and buyer at the same time, if he's logged in he can switch from buyer to seller without logging out. now the problem is I already made a conception of this in this class diagram, but I'm not sure if this model makes it possible later to switch with a button! If it is right please explain the process of switching in the background, does the object seller stops being used and the object buyer starts to be used and that's all? I'm not asking about back-end details but does this model guarantee to not have chaos in database tables? Thank you

I tried to express sessions for same account in class diagram by inheriting two subclasses from class 'Entreprise' that contains customer informations.

I had a problem downloading the diagram image file! @qwerty_so — Rima Benmerzoug, May 20 '23 at 17:59
Look into "prefer composition over inheritance" which is likely your issue. Your question would need to be re-opened before anyone can answer. — qwerty_so, May 20 '23 at 19:14
That's done by votes from the community. There are already 2 of 3 votes. Meanwhile look at https://stackoverflow.com/questions/62209348/composition-vs-inheritance I guess the answerer would also write an answer here... — qwerty_so, May 20 '23 at 21:43

score 3 · Accepted Answer · answered May 21 '23 at 13:19

3

Your design divides sessions classes into Buyer_session and Seller_session. Changing the class of an object dynamically is possible in UML. However such a change is not supported by most of the OOP programming languages. This means that in practice your design would not allow to keep the same session, but would require that you destroy one and create a new one.

Moreover, your design is flawed due to an overuse of inheritance. Your diagrams says sthat a Buyer_session and Seller_session both are some kind of Enterprise, and that an Enterprise is some kind of User. But this does not correspond to reality: a session is a session. It may involve a user account or an enterprise, but it should not inherit from them.

This is the moment to remind the principle of preferring composition over inheritance. In your case:

The first transformation to consider is that sessions would not inherit from an enterprise but be associated with an enterprise. You may then have a Session class, that would have the common features and be specialized into Buyer_session and Seller_session. The session kill and create would work, especially as the delting a session would probably require to take a decision on going operations (e.g. delete the shopping basket).
A second transformation would be to get rid of inheritance and consider the buyer/seller as specific behaviors of a session. Typically, you'd use something like the state design pattern.
A third more fundamental transformation is to differentiate the session that connects a user to the system, from the views and the transactions that may be performed during the connection. Personally I'd opt for this kind of approach, but it's a more fundamental change compared to your initial design, and the way you address the requirements.

answered May 21 '23 at 13:19

Christophe

68,716
7
72
138

I inhereted Entreprise (company) from User, to allow to allow the user after signing up and login with email registering his company (Entreprise), Also to not repeat (email, phone, password) attributes and (logout() method) , because Company inherits them, is that correct? The goal is to give the ability to first user to sign up with email, then to register himself as a company in this B2B ecommerce website,. – Rima Benmerzoug May 24 '23 at 08:18
I have another question about that: giving User one single attribute of both email and phone while Company may have a list of emails and phones, Company inherits that single attribute, so when a user create a company, an object Company is going to have same attributes values of email and phone but added to lists, is it a correct way? – Rima Benmerzoug May 24 '23 at 08:21
Now for the sessions, I think it should be a composition rather than inheritance, because when an object Company is destroyed its sessions must also be deleted, so a company in this website can be both seller and buyer, is composition the right case? @Christophe – Rima Benmerzoug May 24 '23 at 08:47
@RimaBenmerzoug Inheritance is not correct if it's just to easily get some information or to perform some related registrations. What would happen for exemple if you have two users from the same company? In your model you'd have 3 different Enterprise objects. For this kind of relationship, you'd better use a simple association. This allows to have 1 company, and 3 users, and the user could access company information without duplication. Use inheritance only is you could always use an object of inheriting class instead of an object of the inherited class. – Christophe May 24 '23 at 18:14
1

For the second question, it's the problem. Letting company inherit from user, means that a company object has all the company attributes/operations in addition to all the attributes and operations of the user. The issue it that you'd need a different company object for every user. – Christophe May 24 '23 at 18:18
Inheritance means "Is a". A car is a vehicle. So it'd be ok to have Car inherit from Vehicle. But a company is not a user. It's just that a user may relate to a company. – Christophe May 24 '23 at 18:20

Can my class diagram handle switching between buyer and seller roles for logged-in customers?

1 Answers1