Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hey people! I hope you’re doing great 💡 I don’t know if this topic was already raised (I am pr

Options
Chemaclass
Chemaclass Tech Lead Spryker Solution Partner Posts: 213 🧑🏻‍🚀 - Cadet
edited June 2021 in Slack General

Hey people! I hope you’re doing great 💡

I don’t know if this topic was already raised (I am pretty sure it was already mention by someone), but I would like to put it on the table. It’s about Value Objects (VO). Let’s consider a real and useful example: The Sku. Wouldn’t be nice to have an Sku Value Object which can ensure the consistency of its value at the time when it’s being used or expected?

Currently we are using primitive data (int, float, string), or other Transfer Objects, in all Transfers, but wouldn’t be nice to use VO for some values instead of the raw type? I think the Sku is a nice example:

final class Sku 
{
    private string $sku;

    public static function fromString(string $sku): self
    {
        Assert::notEmpty($sku); // or whatever assertion logic that you want to have

        return new self($sku);
    }

    public function asString(): string
    {
        return $this->sku;
    }
}

I was thinking, as something that could be customised by the end client, similar as we can define the Transfers (and generate them out of the box based on some custom xml configuration). Usually a Sku must be in a certain length and never being empty, so such rules/assertions could be customised 🤔 Of course, this Sku is just an opportunity example of a simple VO that could be applied to some other (more complex) VOs.

The clear benefits of this proposal/idea is that you can expect certain types in your functions that depend on specific VO and not simply raw types. I think this would be an awesome step to improve the user experience with Transfers Objects. What do you think?

Comments

  • Ahmed Sabaa
    Ahmed Sabaa Senior Application Architect @Spryker Sprykee Posts: 54 🧑🏻‍🚀 - Cadet
    Options

    I think it’s a great idea, although I am not sure about the immutability aspect of it while working on Spryker projects. Part of the coolness (and headache) of transfer objects is that they are actually mutable and allow side effects even (nightmare or feature?). It allows for a lot of flexibility especially when developing a lot of things in core. Now should we have VOs allowed in Transfer object definition and let projects run away with it? Absolutely! It might be a great way to ensure some sort of sanity on project level. But those VOs will probably not appear on core level. Just FYI, we currently have such support for VOs of Spryker’s internal implementation of https://github.com/spryker/decimal-object. I am not sure how extendible it is to enable other kinds of VOs though

  • UKHD8KTMF
    UKHD8KTMF Posts: 393 🧑🏻‍🚀 - Cadet
    Options

    Also as transfer objects are serialized from/to JSON when we can ZED from client we need to make sure that we do not break this.

  • UKHD8KTMF
    UKHD8KTMF Posts: 393 🧑🏻‍🚀 - Cadet
    Options

    You can also make your own transfer objects by extending AbstractTransfer or existing transfer.

  • Ahmed Sabaa
    Ahmed Sabaa Senior Application Architect @Spryker Sprykee Posts: 54 🧑🏻‍🚀 - Cadet
    Options

    If you’d like to introduce such things in your project, maybe take a look at \Spryker\Zed\Transfer\Business\Model\Generator\ClassDefinition::SUPPORTED_VALUE_OBJECTS . Just keep in mind that overwriting Transfer module on project level just for this particular feature might stop you from gaining access to future Spryker bugfixes/features in the Transfer module!