How we deal with our customers

Today I want to talk about the customer abstraction of our beloved software module. When we first started we were not sure if we should decorate or extend the member class. We started with extending the member class because it appeared the must straightforward to us, as we always think in classes. With "Customer extends Member" we implemented a lot of additional functions to the Customer class. A Customer had a shopping cart, addresses and many extra attributes. During a hallway test we realized that an admin, which was merely of class "Member", did not have this extra relations and attributes and had not the same frontend experience as a customer. For us this was easy to comprehend, but our further customer would not understand that. So we decorated the Member class with the generally needed relations and attributes and then extended it three times: "BusinessCustomer", "RegularCustomer" and "AnonymousCustomer".

Till today these classes do not have much individual functionality, but some methods use the class name to separate customer classes. But it is easy to guess that sooner or later those separate class will be needed more and more.

A customer that registers to a SilverCart installation will land in an optin-group. After verifying his email address his account will be moved to a new group, and the customer will have access to his private area and is able to shop.

A visitor can also choose not to register and shop anonymously, which goes along with some more fields to fill out in the checkout. If a user is not logged in and puts something into the shopping cart, an anonymous customer will be created and automatically will be logged in. Now a cart does exists and will be related to this newly "registered" person. This customer will get a login token as any logged in silverstripe user and can visit the installation the following days, and the shopping cart will still be there.