Flyweight vs Singleton

Implementations seems to be virtually identical, differing only in style, where the flyweight object is created and held by associated objects (containers: pointer objects, caches; factories; or cache-and-factory objects like Spring's BeanFactory) while the Singleton produces and carries the object within the class object.

Other than that, the difference appears to be one of intent: the Singleton expressly denotes one-and-only-one object for whatever reason (e.g. entry-points to be shared concurrently for caching, logging, accessing network resources where it's intended or simply ok to serialize access) while the Flyweight pattern is expressly to cut down on memory usage and does not strictly enforce the notion of one-and-only-one object.

DAOs vs Repositories...

DAO = Repository
BO (Business Object) = Service
Bean = DTO != Domain Object

So the "Repository/Service" pattern roughly equals the "DAO/BO" pattern in my mind, just different nomenclature.

They imply layers of responsbility; but what those responsibilities are often comes down to personal style. E.g. I've seen the @Transaction decoration placed on the service (as some would argue transactions are a business concern) however I've also seen then defined in DAOs.

DTOs/Beans naturally tend toward placement in higher layers, e.g. an MVC controller* or a JSF view deals with these data bag abstractions, although the "bean" in JSF takes on some controller responsibilities vis-a-vis interacting with the BOs, indeed I've seen beans be called controllers in JSF.

BOs/Services may have the responsibility of translating the beans to domain objects and passing them to corresonding CRUD operations of the DAOs/Repositories; although I've seen where it's been convenient to pass domain objects (which DAOs/Repositories typically deal with at the persistence layer) all the way to the front-end. Likewise, I've also seen beans be passed from front-end to BO to DAO where convenient.

So while the assignment of responsibility among the layers isn't always straightforward, having responsibilities spread out, ala SRP, is useful so that one layer doesn't try to do too much.

* In Spring MVC the controller may set a "form backing bean" as a "model attribute" because it's through the model context that the view and the controller communicate.

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."