My Rules for Code Logic Clarity

- All accesses of maps should be in a separate private method describing the outcome. A good example is the isReader() method in the ReadWriteLock class shown here.

Model Transformations

Building on the last two posts, it occurred to me that much of software development within under OOP is transcribing models between modules. That's why it's crucial to use ModelMapper or Automapper or some form of automation to do the tedious field transcriptions.

But even before the transcription process begins it pays to recognize modeling at the lowest levels for what it is, that it has a source, a destination etc. Understanding the model's context is necessary for building the model effectively, so that it's more descriptive and useful than just a plain old DTO.

Pointers for model (i.e. a class that is a "model") design:
- The insertion of null values (or equivalents such an NA enum value, empty string, etc.) is indicative that either the model was not designed properly or has grown beyond it's original scope due to new requirements. Either way it is a signal the software in question needs re-architecting/refactoring.

My Simple Rules to Enforce OOP

1. Every new class (whether it's a repository, factory, domain object, or algorithm element) created should be package private by default. The following are exceptions.
  1.1. Classes declared public may be placed in packages named "facade" or "api" so long as they serve as the module's interface.
  1.2. Classes declared public may be placed in packages named 'model.' It's in here where you will put all your interfaces and abstract factories -- implementations of which are in other package private packages and are either injected via DI using Spring (or equivalent) or "exported" via factory methods of corresponding package private source model objects called by and passed on by facade classes.

2. In public methods, never return or accept Java API classes such as Map, Set (generic or not), etc.. Those are too low-level and should be used only within the inner workings of a domain model class. Only return/accept strongly typed domain model objects that you roll yourself.
As for primitives, these should not be passed between objects either. They too should be encapsulated in domain model class instantiations.
  2.1 Exception 1: Interfaces ending in 'Repository' may return collections.
  2.2 Exception 2: Interfaces ending in Value may return primitives But:
    2.2.1 An interfaces ending in Value must be nested within a correspondingly named interface (I.e. same name minus the Value suffix).
  2.3 Exception 3: Getters and Setters of primitives are allowed when required by a framework such as ModelMapper or Drools -- but a JavaDoc comment above each accessor must state the framework and that it is used by that framework exclusively.

3. Rule of thumb for whether 'it' should be a Factory or Repository: Repos (interfaces/classes ending in 'Repo') should return root level model objects (i.e. those not composed of other model objects). Factories should be responsible for constructing and returning model objects that are composed of other model objects.

See also:
on favoring package private classes: http://www.codingthearchitecture.com/2014/06/01/an_architecturally_evident_coding_style.html
'model' packages are like "Stable Abstractions" - see http://www.codemanship.co.uk/parlezuml/metrics/OO%20Design%20Principles%20&%20Metrics.pdf

Micro Models

I stumbled mentally on the conclusion that the easiest way to do OOP in a team environment where modeling, DDD, UML, etc. aren't regimented (on a side note, I have yet to see a place where it truly is regimented uniformly), is to use this notion of "Micro Models" -- mini-domain models set up quickly under tight encapsulation constraints (Facades for pulling data out and interfaces for creation).

For example, given a new requirement to produce a report listing some options for a decision maker, one may come up with an algorithm to produce such a report using various inputs factored for timing, weighting etc. In this case the inputs would be your domain objects yielding as message responses the results of internal calculations based on their own object graphs and object-specific notions of the algorithmic factors. There could even be objects that model the algorithm itself and its outputs, such as "Iteration," "Plan", etc.

The object model, i.e. the "Micro Model," would NOT use a repository, DAO, ORM, or anything to indicate that it is not alone in this world. This is where Micro Modeling departs from DDD IMO. Instead, the Micro Model is spawned once and only once by a DAO or collection of DAOs that essentially provide to the client of the Micro Model the seed object, which the client and/or the facade can use to interface with the model. So the DAO -- itself an abstraction here, the implementation of which is injected and could make use of other DAOs, ORMs, services etc. -- knows about the Micro Model (the seed objects anyway), but the Micro Model does not know about the DAO. Note, I'm not saying Repository because that is a DDD concept that implies the domain can access the Repository, which is see as defeating encapsulation and also conrtradicts OOP principles that state that objects and behavior go together; and also ironically seems to contradict DDD itself which from what I gather preaches that objects should represent the domain -- and what does say a RestaurantRepository represent in the domain? A Restaurant represents a restaurant, but a RestaurantRepository?? This is what I would consider to be a leaky abstraction...

See also:
"Bounded Contexts" in DDD

Java vs. C#/.NET

C# has the var keyword. Java has no equivalent.

C# has extension methods. Java has no equivalent.

.NET has LINQ. Java has no equivalent.

C# has the delegate keyword. Java 8 has the @FunctionalInterface annotation for interfaces with a single method

C# allows methods to reflect on type parameters. Java does not due to "type erasure."

Visual Studio vs. Eclipse

Found that in Eclipse often you have to save all files before type mismatch errors go away. VS is smarter, i.e. you don't have to save files before type resolution kicks in.

more to come...