In an ideal world every abstraction is pure. We don’t live in an ideal world (yet) though. Abstractions can be hard. They can cause frustration and people to give up on them or wait for the perfect solution.
In my experience, often the right thing to do is wait for the perfect abstraction but I think in a lot of cases it is right to go ahead and do the abstraction. You can always replace it or refactor it if need be but I think the key is not over doing it if not sure – keep it simple.
You want a good return on your investment and you dont want to make a brittle abstraction which limits peoples options down the line or causes tears and frustration.
Also, as with everything you should talk to people and get advice before creating your monster.
My commute for the last four years has been split into 3 parts, walk, train the tube/bus or walk.
Was a nice evening so walked the last part this evening, photos…
There can be a lot of confusion at times about these terms. Part of the reason for this I believe is that there are a lot of different descriptions floating around – just google. Also all 3 are very much related and their names and functions overlap. I guess you are also getting deep into the belly of the beast so there is a little complexity there.
Here is what they mean to me.
Inversion of Control is a generic term, meaning rather than having the application call the framework, the framework calls into the application. To my mind that is all it means really, perhaps the difficulty is visualising this in your head. Part of this might be because there are so many different ways – this is why you can be forgiven for sticking to DI. None the less, IoC is a collection of different solutions to the same problem, including Dependency Injection (DI), Factory Pattern, Strategy Pattern, Service Locator and perhaps others.
Service locator is a little controversial and considered to be an anti pattern by some – I don't know about Strategy Pattern.
Dependency Injection simply means that a class has deferred and is a type of IoC. Responsibility of obtaining or providing its own dependencies; instead that responsibility resides with whatever wants to create an instance (there might be a better description out there than this). This can be constructor, interface or property injection. We tend to do a lot of constructor injection. Interface injection leads us to the DIP.
The Dependency Inversion Principle is about abstractions and has two parts (borrowed from elsewhere):
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend upon details. Details should depend upon abstractions.
DIP is more of a natural fit with static languages but in my opinion is often desirable irregardless. DIP does add complexity in itself though and might not be worth it in smaller scale applications (micro-services) in organisations or legacy code / code that does not change a lot.
DIP seems to be considered less desirable and actually stirs strong, (I would say unnecessary) feeling and emotion in Node. This is because Node is dynamic (difficult to implement – is easier with Typecript) and projects tend to lean towards Microservices (not worth the complexity).
Can go deeper into the principle here: https://martinfowler.com/articles/dipInTheWild.html
A final point is that IoC Containers such as (DryIoc above) tend to facilitate all 3 and looser coupling of your code. As I said before, it can be a confusing topic of conversation but I think is a great thing for a few people to discuss together.
The tree that doesn’t bend will break
This is true but it is also true that sometimes you need to hold tough.
A straight forward example I encountered recently in a common lib I use at work.
The library is reasonably new and a work in progress I guess but the code has been in production for a while and the task was actually to merge the library with another ironicaly enough (side note: I read before that as opposed to the related principle Seperation of Concerns, Single Responsibility does not encourage over seperation). There is very little structure or code in both repos as is, the code to be merged was a utils library and the the other repo was a broader sdk. So I guess it did make sense to merge the two.
I didn't want to complete the merge without dealing with a broadly named class called 'utils'. I had problems with the name anyway as the lib already had utils in the name. I have heard it said many times before that if you can't think of a good name for a class then you should probably consider splitting it up. This was particularly true here – and so I did. The utils class essentially contained file upload and file download functionality. The code in itself had been ported from one language to another and so I would consider it a little hairy. It was essentially an untidied grouping of functions relating to the two purposes already mentioned.
One thing I didn't do was group the File download and upload functionality into a files module – I left them with other utils such as a retry calculator and page counter. As I said before the code base is quite small and I didn't want to over engineer. Also I am aware that I work with others who are less keen on abrstactions and so I don't want to step on toes or be rude. Thats important too!
I have probably said it before but will say again … WordPress is great. I spend most of my day writing and reviewing code at work and is nice to be able to write in words for a change.
Word press is built with PHP – I know PHP has it's critics and sure there is a lot of hacked together PHP scripts out there but I am sure there are is a lot of good code also. WordPress is it's real success story (sorry not a facebooker) in my opinion.
In the past I have dug into the code base and found it a little hairy (used to OOP) – this was years ago though. I don't know what it looks like now, and whatever about the code base the ui seems to be orgainzed very well.
WordPress is just so flexible and straight forward and is great fun. Not sure about using it for businesses to be honest – have been there before and I think eventually you out grow it. Small businesses should be fine!
This article is quite old now but feels like there is some good advice in here:
In my experience, pull requests can serve multiple purposes. The principal use is a peer review before merge but I think you can use them as points of conversation or discussion also and I don't think this is done often enough.
Also I think it is really important to convey respect and be nice.
In the past these two had very little in common, however I thought I’d briefly compare as they are increasingly used together and becoming quite similar in places.
One of the biggest differences in the two is that c# relies on threading to support concurrency whereas node js does not, although threads are used under the hood.
One of the biggest challenges I encountered recently was with array / collection mapping and filtering. Linq is the way to do it in C# whereas js gives you a few different options – lodash is what is used in my place of work. They are similar but a little different. I won’t go into detail here.
There are many more similarities and differences these are but a few….