delete the shopping basket).Ī second transformation would be to get rid of inheritance and consider the buyer/seller as specific behaviors of a 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. You may then have a Session class, that would have the common features and be specialized into Buyer_session and Seller_session. The first transformation to consider is that sessions would not inherit from an enterprise but be associated with an enterprise. This is the moment to remind the principle of preferring composition over inheritance. It may involve a user account or an enterprise, but it should not inherit from them. But this does not correspond to reality: a session is a session. 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. Moreover, your design is flawed due to an overuse of inheritance. 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. However such a change is not supported by most of the OOP programming languages. Changing the class of an object dynamically is possible in UML. Your design divides sessions classes into Buyer_session and Seller_session.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |