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
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.
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()
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.
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.
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.
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
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.
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()
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.
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.
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.
Hi Eric can I get your email...??
Use the email at the bottom of Hougaard.com