Using Interfaces in the Goldilocks zone in AL and Business Central

Поділитися
Вставка
  • Опубліковано 4 гру 2024

КОМЕНТАРІ • 8

  • @davidhofschneider7842
    @davidhofschneider7842 Місяць тому +1

    Hi Erik, some good arguments on i nterfaces and why they matter in app source apps. But they also matter in PTE apps in my opinion. Using interfaces helps to write more readable code (more structured code) and it helps a lot if you want to do unit testing. And dont forget that customer neeeds can change over time and interfaces come quite handy after some time

    • @BlackTigerAP
      @BlackTigerAP Місяць тому +1

      Interfaces don't have much use even in the word where they came from. Readable code have nothing to do with interfaces, which actually can make code even unreadable.
      Interfaces are good only when you need to call later(!) something "unknown", but in BC world it happens extremely rarely.
      Also it's a very bad idea to create something "super-duper-universal-which- even-my-grandgrandkids-will-use" using interfaces. I will end up with some huge unstable monster which nobody will understand. AL is the world of small "1 shot - 1 kill" tasks which are stable, fast and simple.

    • @cptnraptor
      @cptnraptor Місяць тому +1

      Interfaces help with the S part of SOLID principles of OOP; MyFunctionToDoX() can *just* do X, the code is not concerned with specific implementations of a particular part of "doing X".
      MakeSandwich() will assemble the outer bread (or bread substitute) and the filling; sure, right now the customer only cares about cheese sandwiches, but to make your app reusable you may want to scope for ham sandwiches, for stuffed pitas, or for naked sandwiches.
      MakeSandwich(IStructuralComponent, IFillingComponent) is far more extensible than MakeCheeseSandwich()

  • @NinjaTux_
    @NinjaTux_ Місяць тому

    Hi Erik, thanks for the nice video again. I think Vjeko or (Waldo?) made a good point that interfaces will help you alot with testability and test automation. Think about mocking an API for example and that's for either PTE apps or appsource apps.
    You have mentioned, you're implementing an AWS integration. Have you figured out a way to calculate the signature of the authentication header purely in BC. In my experience this is not possible because you cannot chain HMAC functions or atleast the byte representation of it in BC. I would love to see a video about it.

  • @cptnraptor
    @cptnraptor Місяць тому

    As a PTE dev, NO, ALL THE RULES.
    I try as damn hard as I can to comply with the App Source rules, because sure, my modules are PTE right now, but who knows, my modules may be in demand on App Source in future, and if I can comply with App Source Cop as much as possible, it reduces the number of issues I will have to deal with should that come to pass.
    Even if my modules don't end up on App Source, following stricter development rules makes for more robust code, more readable, more maintainable, and most importantly, most extensible.

    • @Hougaard
      @Hougaard  Місяць тому +1

      I think your comment falls under my "your milage might vary" :) I do know customers who have chosen a different partner because even the simplest request becomes a project ... aka too expensive.

  • @rajdeulkar5997
    @rajdeulkar5997 Місяць тому

    Hi Eric can I get your email...??

    • @Hougaard
      @Hougaard  Місяць тому +2

      Use the email at the bottom of Hougaard.com