Skip to content

Instantly share code, notes, and snippets.

@folkengine
Last active August 26, 2024 17:30
Show Gist options
  • Save folkengine/a40e2d455feb0512392e244ef0d3446e to your computer and use it in GitHub Desktop.
Save folkengine/a40e2d455feb0512392e244ef0d3446e to your computer and use it in GitHub Desktop.
general_contract.md

ALTHOUGH Object is a concrete class, it is designed primarily for extension. All of its nonfinal methods (equals, hashCode, toString, clone, and finalize) have explicit general contracts because they are designed to be overridden. It is the responsibility of any class overriding these methods to obey their general contracts; failure to do so will prevent other classes that depend on the contracts (such as HashMap and HashSet) from functioning properly in conjunction with the class.

Excerpt From Chapter 3 Effective Java 3 Edition Joshua Bloch

general contracts

@shankari & @james-ctc I will have to respectively disagree with your comments concerning operators against Domain entities that are only used in unit tests should also be placed under the testing directory.

I come from the school that sees these elements as part of the general contract for the entities. Since this is a library, and we want to support using this library for things other than itself, these would be considered a standard part of what Joshua Block calls "their general contracts". I, for one, would much rather not have to write them for utilities such as appenzell.

ALTHOUGH Object is a concrete class, it is designed primarily for extension. All of its nonfinal methods (equals, hashCode, toString, clone, and finalize) have explicit general contracts because they are designed to be overridden. It is the responsibility of any class overriding these methods to obey their general contracts; failure to do so will prevent other classes that depend on the contracts (such as HashMap and HashSet) from functioning properly in conjunction with the class.

-- Joshua Bloch, Chapter 3 Effective Java 3 Edition

Please forgive me for citing a Java book, but it is one of my favorites, and had a massive impact on my craft as a developer.

Nevertheless, in the spirit of Git-R-Done I am going to move them and table this discussion until a later date.

Thanks for the feedback.

TEST_F(ChargepointTestFixtureV201, K08_CalculateCompositeSchedule_sil_TC_K_40) {
    std::vector<ChargingProfile> profiles =
        SmartChargingTestUtils::get_charging_profiles_from_directory(BASE_JSON_PATH + "/sil_TC_K_40/");

    const DateTime start_time = ocpp::DateTime("2024-08-21T09:14:17");
    const DateTime end_time = ocpp::DateTime("2024-08-21T09:21:06.49");

    CompositeSchedule expected = {
        .chargingSchedulePeriod = {{
                                       .startPeriod = 0,
                                       .limit = 230.0,
                                       .numberPhases = 1,
                                   },
                                   {
                                       .startPeriod = 3600,
                                       .limit = 10.0,
                                       .numberPhases = 1,
                                   }},
        .evseId = DEFAULT_EVSE_ID,
        .duration = 7200,
        .scheduleStart = start_time,
        .chargingRateUnit = ChargingRateUnitEnum::W,
    };

    CompositeSchedule actual =
        handler.calculate_composite_schedule(profiles, start_time, end_time, DEFAULT_EVSE_ID, ChargingRateUnitEnum::W);
    ASSERT_EQ(actual, expected);
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment