Escape from the Planet of the Collections by Stuart Marks, Maurice Naftalin

แชร์
ฝัง
  • เผยแพร่เมื่อ 24 พ.ย. 2024

ความคิดเห็น • 15

  • @shadeblackwolf1508
    @shadeblackwolf1508 หลายเดือนก่อน +4

    This talk really explains the value in the L of solid: subclasses should not create problems the user of the base class doesn't expect.

  • @rydmerlin
    @rydmerlin 15 วันที่ผ่านมา

    No use of guarded clauses but just if then else everywhere. The question was suggesting the invariant of preserving the first element could be preserved by using a sublist of the backing list and directing all the methods to that. Why can’t you have a FakeBook class which only the two fields and have Books equals method only check those two fields when the parameter is an instance of FakeBook? Also when you return early you don’t need an else clause.

  • @maorhamami8106
    @maorhamami8106 หลายเดือนก่อน +4

    its time that java will split the interface into "Mutable" and "Immutable" like kotlin/scala do. its impossible in the moment to see that the "Set" that return from "edges" is immutable and will break on runtime...

    • @lukeusherwood2525
      @lukeusherwood2525 หลายเดือนก่อน

      Honestly Guava's ImmutableCollection strikes the best compromise. It's not perfect, but it is compatible and it lets you pass around (via types) the information about what collections are definitely immutable and can be safely assumed as such. Production code that always prefers `ImmutableList.of` instead of`List.of`, etc is nice to work with. Comes with other nice benefits (like predictable iteration order of ImmutableSet - creating a win-win situation when you want the best of both a List and a Set.). See Javadoc of ImmutableCollection for details.

  • @PavelRappo
    @PavelRappo หลายเดือนก่อน +3

    The slide at 1:26:18 should be like this instead:
    var treeSet = new TreeSet(String.CASE_INSENSITIVE_ORDER);
    treeSet.addAll(Set.of("A", "b"));

    • @s888marks
      @s888marks หลายเดือนก่อน +1

      Yes, that's correct.

  • @rydmerlin
    @rydmerlin 15 วันที่ผ่านมา

    If it’s this difficult and risky why then aren’t the classes final?

  • @shadeblackwolf1508
    @shadeblackwolf1508 หลายเดือนก่อน

    This may sound crazy, but i'd like collections to be able to return a "read only" view of themselves. This would mean the container can still write to it and update it, and receivers will still receive these updates, but they cannot push state the other way.

    • @fredoverflow
      @fredoverflow หลายเดือนก่อน

      You mean like java.util.Collections.unmodifiableList(original) or something else?

    • @shadeblackwolf1508
      @shadeblackwolf1508 หลายเดือนก่อน

      @@fredoverflow does the list that creates update if the source list update?

    • @fredoverflow
      @fredoverflow หลายเดือนก่อน

      @@shadeblackwolf1508 Yes, all later changes to the original list will reflect in the unmodifiable view.

  • @PavelRappo
    @PavelRappo หลายเดือนก่อน

    Is there a typo at 2:05:53? ConcurrentHashMap does not seem to have the longSize() method, at least in JDK 23. What it does have though is the long sumCount() method, but it has package access and thus is unavailable to clients.

    • @Anbu_Sampath
      @Anbu_Sampath หลายเดือนก่อน

      may be mappingCount() method.

    • @s888marks
      @s888marks หลายเดือนก่อน +2

      @@Anbu_Sampath Yes, thanks, I meant mappingCount() instead of longSize().

  • @DenisFalqueto
    @DenisFalqueto หลายเดือนก่อน +2

    Great lesson on why object orientation sucks, btw...