Hybris is intended to be fully extensible, so creating classes or methods that cannot be extended is not sensible. You’ll get problems with:
- Extending functionality;
- Testing. It’s hard to substitute in sub-classes;
SAP recommends avoid using private methods, because it is not sensible. They recommend use only public and protected methods. But from my point of view that’s too much.
Of course all fields must be private and accessed via public or protected accessor methods.
Static methods cannot be overridden so SAP recommends avoid them if at all possible.
SAP Documentation says that static methods of utility/helper classes should only provide very simple common functions that will not need to be extended/tested.
I will use only an interface to inject and not a concrete class.
SAP Documentation says that we have to use the Spring XML configuration, except for controller classes.
Using the Spring annotation configuration files means you can’t change the configuration without modifying source code files. And don’t forget that the Hybris build time can be dramatically long in some projects.
SAP Documentation says that we have avoid using static block, because static initialisation blocks are run at class loading time and that is typically before all platform services are up and running.
One exception - coding very low-level functionality in the core platform itself.
AddOn is a type of extension that allows you to add front-end files in your own AddOn instead of modifying the storefront extension directly. Also, it allows you to avoid the need for the manual merging of files after upgrading the Accelerator codebase. AddOns can serve as a library of self-contained, reusable components for your future projects. How to use addon? Simply put your front-end files in Addon extensions. Don’t put business logic and resources in Addon extensions.
- Facades should be very extensible and easy to extend.
- Write comments only for public and protected methods with complex logic. Comments should be clear and describe why the functionality is working a certain way.
- Choose the right place. If an extension has been created specifically for facades (example: alibabafacades), place the interfaces of facades in the root package of the extension:For small features place the interfaces of facades in a package called facades under the root package of the extension:
package com.alibabafacades;If an extension contains several facades for different features, use sub-packages to group the facades by feature.
- Use a prefix “Default” for Default implementations of facades:
OrderFacade - DefaultOrderFacade
CustomerFacade - DefaultCustomerFacade
PromotionFacade - DefaultPromotionFacade
- Put the implementation of facades in an impl package under the facade package:
- Define DTO beans in
<property name="id" type="String"/>
<property name="message" type="String"/>
<property name="url" type="String"/>
<property name="type" type="com.alibaba.core.promotion.RewardType"/>
- Use Convertors and Populators for converting hybris model objects into DTO instead of using hard coding.
- Put populator classes in populator or convertors.populators package directly under the root package of the extension or under the package for the current domain.
public class RewardPopulator implements Populator<RewardModel, RewardData>
Created based on official documentation
Follow me in the group in telegram