https://kotlinlang.org logo
Join Slack
Powered by
Take on not so obvious problem caused by type-safe...
# feed
m
👎🏾 2
đź‘Ž 15
👎🏼 1
b
Why isn't CarFactory a below the line implementation detail?
It feels like you've added something concrete to an interface with this example.
And if you're making changes to the interface itself, then yes, you've changed the contract and you need to "redeploy".
âž• 1
e
Wonder how any of the concerns you mentioned changes with a type unsafe language.
t
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.
âž• 3
âś… 6
h
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.
m
@Bryan Buschmann
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?
@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
b
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.
So... yes, if you change an implementation, you have to deploy an implementation.
m
yes but you don’t have to deploy the abstraction or App component as it is in the example
b
Except you put your implementation details into your abstraction, so it's not exactly abstract anymore.
As was said earlier... this isn't an issue of type checking.
m
@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
@Hanno
Hope you appreciate honest feedback
of course, thank you.
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.
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
@efemoney you would be able to deploy. you would be at risk of runtime crashes but you would deploy
b
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?
âž• 1
Also, why would you knowingly ship broken code?
Just because you can doesn't mean you should.
m
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
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
@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
and you are always free do disagree
b
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.
âž• 6
d
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
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
âž• 3
f
Relevant

https://youtu.be/SIr7mcnVy98â–ľ

5 Views
Open in Slack
PreviousNext
Powered by