A Repository as defined in Domain Driven Design manages a single Aggregate. An aggregate may contain many entities, and value objects, but will have a single object as its root. Many of the Dao and even now some of the Repository implementations I see do not follow this, they are more likely to have a Repository per entity, than a Repository per aggregate, and of course in some cases this is required for various reasons.

Firstly what is Polymorphism and why is it so important? Polymorphism is the ability to have a many implementations of a behavior that conform to a single interface. Put in perhaps slightly better, pragmatic terms, you have one implementations of a caller, that can operate on many implementations of a “parameter”, without conditionals, or changing the callers code. For instance the following, pseudo?, Perl 6-ism method handler( $obj ) { $obj.

It is worth noting that none of the following arguments apply to anything using the keyword static which makes things more procedural (or in some cases functional, than Object Oriented. The suggestion in Java is to give the least required permission, but this, in my humble opinion, violates the Open-Closed Principle. Java has four privacy levels. Giving something the least permission required to function is fine in a Security context, privacy in programming however is simply there to discourage developers from doing stupid things.

So when I started using Dependency Injection the following problem happened, how do I Inject this dependency when the container is not accessible at this point. Ok, that sentence even confused me a little bit, so what do I mean. Let’s say I have a Repository for Products that is injected into my controller. Each Product stored has one or more ProductVariants that is part of it’s aggregate, which itself has Nested Categories.

Moose interfaces are problematic, for 2 reasons. They are compile time, but runtime features such as attribute delegation could provide the interface (role ordering is the real problem here) They don’t ensure anything other than the method name. I think this problem can be solved better by using around instead of requires 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 package Interface::Create; use Moose::Role; use Type::Params qw( compile ); use Types::Standard qw( slurpy HashRef); around create => sub { my $orig = shift; my $self = shift; state $check = compile( slurpy HashRef ); my ( $obj_args ) = $check->( @_ ); return $self->$orig( $obj_args ); }; 1; Ordering of course still matters here as you can have multiple around modifiers on a method.

If you’re not familiar with the term “Inversion of Control”( IoC ) or “Dependency Injection” ( DI )you may wish to start with Martin Fowler’s post on the subject. If you’re looking for a way to do it with Perl, Bread::Board is the way to go. This post however is about the theory behind it, and a path to grokitude if you’re finding the concepts challenging. I should advise that I am not yet a buddha on implementation.

What is Interface Driven Design? Interface Driven Design simply means that you should design your software around a flexible, easy to use, easy to understand interface. This is easy to achieve if your objects are of SOLID design. There is a simple table and reference link if you’re not familiar with the principles. My Work is SOLID already Then you’re on the right track but it’s not enough if you don’t fully marry the concept to best practices.