How OOP is mistreated in Angular

[Armenvardanyan95]

In this article, we focus on discussing the issues that developers face with object oriented programming, and some misconceptions/malpractices that exist withing the Angular community about OOP.

Read the article here.

[vdlindk]

Hello Armen,

First of all thanks form the great article. Ik do have one remark regarding 'a specific service for a component'. Ik use this (anti)-pattern a lot. I use it for every container , but I make sure it is provided at the container itself. With this approach my container-component has a clear specification, while the implementation of this specification is nicely encapsulated in a service. I agree that from an OOP point of vue that this service and component are strongly coupled (I place them in the same folder), but this pattern introduces in my opinion some nice advantages regarding the maintenance and testability of your application.

[Armenvardanyan95]

Thanks for appreciation!

About your remark: but what if you need the data from service A in component B? Do you replicate the code (violating DRY) or do you move that logic to another Service C and inject C in A and B? And if the latter is true, does it not even furthr worsen the strong coupling now introducing coupling between A component and B component too?

[maxkoretskyi]

@vdlindk do you mean you have something like this:

my.component.ts
my.service.ts

@Component({
   providers: [MyService]
})

If so, I personally don't see any problem with this. You basically move all the business logic to the service, while presentation logic stays in the component. That's how we did it in AngularJS when we put business logic into controllers. That's a good approach to start development. Later, when you'll have many services like this, you can try to refactor your code to merge services into more general units with logic like Armen suggests in his article.

[titusfx]

I agree with @vdlindk in that remark. Sometimes is a huge the component, not because you make bad split decisions but because is having too much code ( For events, or either other particularities of the Web environment and the management of the component). Also makes your code more readable if you set good names of functions. Your component is clean (even when is complex).

If the case of @Armenvardanyan95 happens, that means that you need to create 3 services, one with CommonBehaviour, and other two that has this common behaviour by the mean you require in your context.

It's a common fact, that you need to split a service in new ones. That means, that you are understanding better your domain. Most of the time, you know your domain, but when you spent more time developing, you realize new patterns and do a new split. Is a Fact, is the Main reason that you are always getting updates (e.g. in Angular). Sometimes the split is obvious, sometimes it is not. Depends on your current knowledge of the domain and the relation that you can make with different pieces. Sometimes is so deep your knowledge, and you make a new split people get hard time to understand, how to different pieces can come together on some behaviour.

In any case, IMHO, it will always happen, which is independently of a Component have a Class for him self or not.

[maxkoretskyi]

@titusfx

but when you spent more time developing, you realize new patterns and do a new split. Is a Fact, is the Main reason that you are always getting updates (e.g. in Angular). Sometimes the split is obvious, sometimes it is not. Depends on your current knowledge of the domain and the relation that you can make with different pieces. Sometimes is so deep your knowledge, and you make a new split people get hard time to understand, how to different pieces can come together on some behaviou

Indeed! I'm a follower of the "bad abstraction are worse than no abstraction at all" approach to development. This basically means localizing logic into a service or component until you clearly see how it should be refactored/split into multiple abstractions. It's always easier to split a class, then restructure multiple classes. My rule of a thumb, the less I know about the domain, the less abstractions I tend to use when starting out. The same goes for state management libs or rxjs.

[ezzabuzaid]

Nice article!

Regarding Using classes everywhere, I believe this is more of a mapping issue rather than interface vs class. the developer should map the returned data to the appropriate type before using it. and sometimes the returned data fields cannot be used as they are, for instance, due to naming convention, so the developer has to map them.

[talamaska]

I tend to use mostly interfaces, not classes for data mapping. If I need to massage the data, then probably I might consider it. But i don't really like to see too much new Data() all over the place.