You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am skeptical about the concept for lecture 6 (components, services, and frameworks). For me, this is the hardest lecture to give, and also the most confusing exercise class. (This is partially due to the exercise tasks, but also due to the corresponding lecture, which this issue is about.)
The lecture does not really introduce anything new. Components are an architecture-level instantiation of design patterns already earlier discussed in the lecture. In the exercise, I regularly struggle to delineate this clearly. Each of the implementation lectures clearly introduces a novel concept (2-regular language features, 3-cloning, 5-language-independent tools, 7-new language features), except for this lecture IMO.
What is the conceptual difference between components and (micro-)services? Yes, by moving components into network environments, some small things change. Yes, microservices are typically tied to a particular organization structure/philosophy. But these feel like nuances which can be explained on a single slide, not treated as "big" technical implementation techniques (which this part of the lecture series is about).
The lecture explains in great detail what components, services, and frameworks are. However, it is barely explained how this is connected to variability and SPLs. The lego images are unfortunately handwavy - I am not able to clearly explain how to implement an SPL based on components or services. I also do not know of any examples of such SPLs. Both concepts are barely mapped onto concrete code, in contrast to the other lectures.
What is the conceptual difference between components and frameworks? As far as I can tell, only preplanning and inversion of control. How does this justify that we need to write glue code for components and not for frameworks? A very regular use case of frameworks is the adaptation of existing component code - so glue code is necessary in that case. Vice versa, there are also standardized components, which do not require writing glue code at all to switch out. In general, I believe there is no clearcut distinction between components and frameworks, which makes it really hard to explain in the exercise. (Do we even need the term glue code? Isn't this just an instantiation of the adapter pattern?)
IMO, large parts of this lecture can be dropped without losing anything important. Of the three blocks, frameworks seem the least confusing (although they are still just applications of things discussed earlier in the lecture). (see #18)
Alternatively, we could improve the definitions of these concepts and give more concrete examples. To some degree, this could also be solved by moving lecture 6 into the ad hoc part of the lecture series, as I would not associate any of these techniques with the classical definition of the term SPL. (see #20)
The text was updated successfully, but these errors were encountered:
I am skeptical about the concept for lecture 6 (components, services, and frameworks). For me, this is the hardest lecture to give, and also the most confusing exercise class. (This is partially due to the exercise tasks, but also due to the corresponding lecture, which this issue is about.)
IMO, large parts of this lecture can be dropped without losing anything important. Of the three blocks, frameworks seem the least confusing (although they are still just applications of things discussed earlier in the lecture). (see #18)
Alternatively, we could improve the definitions of these concepts and give more concrete examples. To some degree, this could also be solved by moving lecture 6 into the ad hoc part of the lecture series, as I would not associate any of these techniques with the classical definition of the term SPL. (see #20)
The text was updated successfully, but these errors were encountered: