Actually,.. there's a mix of two different things.
1) Should we use "Specialized Business Collections"? - Yes, please. Do it whenever you can. Do not use strip PHP associative arrays, do not use Java standard collection interfaces like List<>, Map<>, Set<> etc.
2) Should we reimplement something? ;) Probably, not. Please do not reimplement TreeMap or ArrayList without really good reason for that.
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
1) The most valuable benefit - it's extending your dsl. The same purpose like Value Objects in DDD - we can use UUID anywhere, but we want to wrap it with some WalletId class. I want to clearly distinguish in my code both list of strings - Dictionary and MyNames. I do not think anybody will appreciate something like List < Map < String, Map < Integer, String>>> :))
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
Extension should be made when protocol is different.
Dictionary and MyNames might be primitive obsession code smell. But this is the case when we need specialized behaviour. The quest is to find this behavior
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
I tend to generalize it a bit - the only important thing is the Domain. So, if we have somewhere in our domain "MyNames" thing - we should reflect it in our code. Even if it will be just one line, like
public interface MyNames extends List {}
(of course, it's better to have
public interface MyNames extends List {} )
Protocol extension could come after that, but not have to. The better code should looks like domain expert speech, and there's no lists of strings ;).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Actually,.. there's a mix of two different things.
1) Should we use "Specialized Business Collections"? - Yes, please. Do it whenever you can. Do not use strip PHP associative arrays, do not use Java standard collection interfaces like List<>, Map<>, Set<> etc.
2) Should we reimplement something? ;) Probably, not. Please do not reimplement TreeMap or ArrayList without really good reason for that.
IMHO
1) Not, why?
Specialized Collection do not bring additional benefits unless we have strong evidence.
2) Until we find differential responsibilities
1) The most valuable benefit - it's extending your dsl. The same purpose like Value Objects in DDD - we can use UUID anywhere, but we want to wrap it with some WalletId class. I want to clearly distinguish in my code both list of strings - Dictionary and MyNames. I do not think anybody will appreciate something like List < Map < String, Map < Integer, String>>> :))
Extension should be made when protocol is different.
Dictionary and MyNames might be primitive obsession code smell. But this is the case when we need specialized behaviour. The quest is to find this behavior
Pardon, don't get it. What protocol do you mean?
Protocol is the set of functions an object understands, AKA behavior
Is the only important thing we need to know in order to program
Aha, thanks.
I tend to generalize it a bit - the only important thing is the Domain. So, if we have somewhere in our domain "MyNames" thing - we should reflect it in our code. Even if it will be just one line, like
public interface MyNames extends List {}
(of course, it's better to have
public interface MyNames extends List {} )
Protocol extension could come after that, but not have to. The better code should looks like domain expert speech, and there's no lists of strings ;).