Take on not so obvious problem caused by type safety

Question

Take on not so obvious problem caused by type safety <https medium com markonovakovic types are coupling the hidden cost of type safe programming 7e05f7a3fb02>

Bryan Buschmann · Answer

Why isn t CarFactory a below the line implementation detail

Bryan Buschmann · Answer

It feels like you ve added something concrete to an interface with this example

Bryan Buschmann · Answer

And if you re making changes to the interface itself then yes you ve changed the contract and you need to redeploy

efemoney · Answer

Wonder how any of the concerns you mentioned changes with a type unsafe language

todd.ginsberg · Answer

gt Type safety is coupling I d word that as Type safety is explicit coupling whereas Non type safe is implicit coupling The coupling is there either way

Hanno · Answer

Hope you appreciate honest feedback this is one of the worst takes i have read in a long time What you call coupling is semantic coupling that wont magically disappear only because you remove the types Your factory first exposes a limited input range an enum a known set of values which means there is no parsing No input validation needed No error type result or whatever You then lessen the specification accepting arbitrary Strings introducing possibility the factory doesnt understand the input value and giving the user of the api absolutely no clue what valid input could be A better design would be to keep the factory like it was introduce a cartype parser and put all the parsing stuff there without changing the core of your design You are completely free to do that with modules as well I also Wonder how unit test would help in any way with the aspects i exposed Hopefully i am Not completely off track and Not getting what your points are Bonus in a type system more mighty a factory could as Well by Part of the interfaces For example c abstract static interface methods or typeclasses pattern

Marko Novakovic · Answer

< Bryan Buschmann> gt Why isn t CarFactory a below the line implementation detail than it would be in same module as the implementation and the derivatives that breaks independent deployability right

Marko Novakovic · Answer

< Bryan Buschmann> and yes if you make change you need to redeploy using and used components very rarely get deployed separately but you still want independent deployability

Bryan Buschmann · Answer

An interface for CarFactory could live above the line But if you re writing code that creates an instance of a thing that s an implementation detail So if your CarFactory implementation is creating instances of implementations it s not a contract or a description it s an implementation

Bryan Buschmann · Answer

So yes if you change an implementation you have to deploy an implementation

Marko Novakovic · Answer

yes but you don t have to deploy the abstraction or App component as it is in the example

Bryan Buschmann · Answer

Except you put your implementation details into your abstraction so it s not exactly abstract anymore

Bryan Buschmann · Answer

As was said earlier this isn t an issue of type checking

Marko Novakovic · Answer

< todd ginsberg> true at the end of the day there has to be coupling there is coupling by mere fact that you are using something difference is just in how strong that coupling is I wanted to show how type safety can break independent deployability in this example dynamic typing wouldn t prevent you do independently deploy you would be at risk during runtime but you could deploy for me unit tests and TDD solve those risks

Marko Novakovic · Answer

< Hanno> gt Hope you appreciate honest feedback of course thank you gt What you call coupling is semantic coupling that wont magically disappear only because you remove the types as I said above there absolutely has to be coupling you are using something that s coupling types just add another layer to it that doesn t exist in type unsafe languages this was tailored example to showcase that exact thing this is not particularly good factory implementation it s rather oversimplified and bad but it conveys the point it s too simple so problem is spotted easily point is still there regardless of better ways to implement it gt Hopefully i am Not completely off track and Not getting what your points are explained above you are not wrong but you kind of missed the point the thing with unit tests and TDD is that they provide safety you can write unit tests that make sure that correct `String` in this case is passed to the factory they will not prevent you from creating non existing implementation but you can t create non existing implementation with types either difference is that with `String` it will crash on runtime and with type safe approach it will not compile unit tests can have same function as compiler in this case

Marko Novakovic · Answer

< efemoney> you would be able to deploy you would be at risk of runtime crashes but you would deploy

Bryan Buschmann · Answer

Why would you want to manually write unit tests for something that s already tested for you as soon you pass your code changes to your IDE

Bryan Buschmann · Answer

Also why would you knowingly ship broken code

Bryan Buschmann · Answer

Just because you can doesn t mean you should

Marko Novakovic · Answer

gt Also why would you knowingly ship broken code who said it s broken why is it broken what I said that mentions shipping broken code

Marko Novakovic · Answer

even though you are right in some points you are completely missing the point the fact that there is better implementation doesn t remove the problem my example is bad and oversimplified because it s not meant to show you how to write good factories but to showcase particular problem

Marko Novakovic · Answer

< Bryan Buschmann> and I am not going to sell you whole TDD methodology and benefits of unit tests you either practise it and understand my point or you don t

Marko Novakovic · Answer

and you are always free do disagree

Bryan Buschmann · Answer

The fastest red green loop that I know of is proper compiler support in an IDE I don t need to write any unit tests for static analysis That would be the point of the compiler and type checking

Damien O&apos;Hara · Answer

this is an interface design issue rather than a type safety issue since you ve designed an interface that only works with predefined car types you can t add car types in implementation if you need this capability then the interface is poorly designed for your problem space if you don t then there is no problem

Damien O&apos;Hara · Answer

I do think this article reflects a confusion about type safety that I have found common among people coming from a dynamic background static type safety is not about artificially constraining your program design to eliminate all dynamic behavior it s about using types to accurately model those aspects of your system that are statically guaranteeable making cars by a dynamic type value is not inherently un type safe if the dynamism is required by design

franztesca · Answer

Relevant <https youtu be SIr7mcnVy98|https youtu be SIr7mcnVy98>