My program's Journal consists of unique Pages identified by their Day. Within those pages are a collection of Entry (wrapped in an interface of their own, Entries).

Users will be directly interacting with unique Pages supplied by the Journal upon passed an instance of Day.

Within those Page he/she could opt to change the weather felt on that Day (but not the Day itself) plus add, remove, or edit an Entry.

The Entry itself is no more than a combination of Title and Body. Each Page can have as many of Entry as the user wants as long as they're unique to one another within itself. An Entry's uniqueness is determined by their Title (similar Body is completely fine).


public interface Journal extends Iterable<Page>, Serializable {

  Page pageFor(Day day);

Page.java (Entries is just List<Entry> but with maintained uniqueness)

public interface Page extends Entries {

  Day day();

Day.java (Weather is just an ordinary enum)

public interface Day extends Serializable {

  Date date();

  Weather weather();

  void changeWeather(Weather newWeather);


public interface Entry extends Serializable {

  Title title();

  void changeTitle(Title newTitle);

  Body body();

  void changeBody(Body newBody);

Throughout the process of designing this model my main goal has always been to make components as loosely-coupled as possible. But as with any beginner, I have my doubts:

  • Is this way of composition correct? Should a page know how to change the Weather of a Day it's related to instead?
  • How to correctly create an Entry to my Page? Should it has some method called createEntry(Title, Body) or would an add(Entry) be enough?
  • How to make this model more immutable? I want everything in my program-to-be as immutable as they could, but the nature of Day is to have changeable Weather or in other word, mutable.

Also, if you have any suggestions on how to improve this overall model, please don't hesitate to speak it through.

  • \$\begingroup\$ Entry should have a create time stamp and an update time stamp so you can arranges the Entrys in time stamp order. Everything does not have to have an interface. Generally, interfaces are for parts of the system that may have more than one implementation. A createEntry method should be part of the Entry class. An add method should be part of the Page class. It's the nature of a journal that most fields will be mutable. \$\endgroup\$ – Gilbert Le Blanc Mar 4 '16 at 21:56
  • \$\begingroup\$ My intention behind this all interface approach is so that the implementation (which I designed to be directly interacting with a persistence mechanism) could be easily exchanged. So the concrete class would be an SqlPage, or MongoEntry, etc. All of which will be supplied by a DI. Thanks for your other suggestions though! \$\endgroup\$ – MrHadiSatrio Mar 5 '16 at 10:20
  • \$\begingroup\$ This question is borderline off-topic as interface-only design questions aren't really the right fit for Code Review... see here and here. I strongly suggest putting in the implementation here so that there's more to review on... and who knows, after seeing the implementation, perhaps you'll have better ideas too... :) \$\endgroup\$ – h.j.k. Mar 5 '16 at 16:00
  • \$\begingroup\$ Well from the source you've just gave me the whole on/off-topic of interface-based questions is still debatable. I arranged the question to be this way because I want a peer review on whether or not the overall interaction between the components in my future program is good enough. In my opinion, a good interface modelling most of the time would result in better code overall. That said, do advise if I should ask this on another SE forum instead (SO, Programmers, etc). \$\endgroup\$ – MrHadiSatrio Mar 5 '16 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.