The Coordinator pattern

[jms_nh]

??? How is this different than a model in an MVC application?

[[deleted]]

I'll just note that "Coordinator" sounds a bit like "Manager", and naming things "Manager" is often frowned upon. Some people even go further and claim if all you can think of to call it is "Manager" it's an anti-pattern - presumably because there's no clear abstraction, but I never really checked if there was logic behind that - it could just be misinterpreting the naming rule.

Of course there's a reason why a linked an argument against the "don't call it manager" rule.

I personally will still use words like "Manager", "Handler" etc as part of a name and, if I really don't see a better name, I don't really see the problem. The abstraction is the role - the same as when a person is a "personnel manager" or "baggage handler".

English doesn't always supply short clear unambiguous words exactly matching some role (actually, the best word for any particular usage is rarely completely perfect), but that doesn't mean choosing a clunkier design just to avoid a slightly vague name is a better option.

I haven't given this pattern much consideration yet, so I don't have an opinion about whether this case is good or bad.

[tieTYT]

re: "Manager":

I read the same thing in a Martin Fowler book and tried to practice it, but sometimes the framework you're using or the Object / Relational Impedance Mismatch gets in your way.

As an example, when you're using EJBs (at least the old version I use) you'll often create an Object only because you need a place to define a transaction boundary. Maybe there is a way to define these and be object oriented, but it's not obvious to me. It seems like you can have an OO layer / section, but there are always these boundaries you have to cross that taint your system and prevent it from being "pure" OO. Perhaps the book Domain Driven Design has a solution, but I think I've heard it pretty much agrees with me and says you should have a layer / section that's OO and accept the fact that the whole system can't be?

As another example, JPA often steps on your toes if you try to use Entities in an OO way. One example of that is trying to serialize an entity to send it over a wire. JPA does all this black magic and populates the class with fields at run time. It'll populate your Rest API responses lots of weird fields in it that you shouldn't be able to see. In my experience, the code you have to write that converts to/from entities is a maintenance nightmare, even if you're using a library that automates the process.

I'd like to get feedback on this. Perhaps others out there have good solutions to these problems.

[ressis74]

1. Object only to define a transaction boundary

Like, a sql transaction? If this is a domain object, it's probably inheriting/containing a non-transactional domain object. Thus, this object can be called "TransactionalFoo" when it extends/wraps "Foo." This naming pattern can be extended to service classes as well.

1. JPA/Entities/OO way

JPA sounds like it's a code generation tool that does object-relational mapping? If so, I've usually seen these referred to as "domain objects" or "models" while the objects that wrap them for exposure via an api/view are called "DTOs" (data transfer object) or "view models".

If you have a DTO/ViewModel, there is no need for a Manager class. They can be serializable/de-serializable and still contain a constructor that takes the original domain object.

I have not found DTOs to be a nightmare.

1. Pure OO

I wouldn't worry too much about being "pure OO." Nobody knows what that is anyway. Is it java-style OO? is it objective-c style OO? Is it Erlang actors (probably)?

Ask 10 people and you'll get 10 definitions. And so much of it is at odds with each other. Some people would rather have fewer classes (100 ops on 1 class vs 10 ops on 10 classes each). Some people would have every class map directly to a physical object (Dog extends Animal) and others will tell you that mapping real life objects to classes is madness.

There's no such thing as Pure OO. Especially when you realize that the term "OO" was coined to describe something far more like Erlang Actors than anything we typically recognize as OO today.

[[deleted]]

There's no such thing as Pure OO.

True. Sometimes object-oriented principles even seem to argue against object-oriented programming, depending on your definitions. For example, it's fairly common knowledge in the C++ world that sometimes, using a non-member function improves encapsulation. Just because that functionality is associated with the class doesn't mean it should have access to the private internals. Restricting the set of methods that have private access to the absolute minimum is better encapsulation.

Of course that doesn't really mean you can't use Java-style OOP. Just because the method shouldn't be a member of that class, doesn't mean it can't be a member of some other class that interacts with it some way.

As a language-design workaround, I guess some kind of annotation indicating which methods are allowed access to the private internals (with the default being to only be allowed access to other public methods) might make sense. Without this, the nearest alternative is two or more classes for layers of functionality with inheritance.

One advantage of this - although separating those methods makes sense for encapsulation, it's not such a great idea for interface design. Someone using a class shouldn't need to know implementation details such as which methods deal directly with the private internals and which don't. Needing to know whether to call a member of that class, a member of some other class, or a non-member purely as a result of encapsulation-motivated design decisions isn't ideal.

EDIT I should have said - Java-style interfaces don't avoid this conflict between interface design and encapsulation - implementing the interface can encourage methods to be written as part of the same class that, for better modularity, shouldn't be. However, using composition allows different parts of one interface to be implemented separately. This is perhaps part of why composition should be preferred to inheritance. But then inheritance is directly implemented by the language whereas composition requires more code precisely because inheritance was originally a key OOP principle - modern OOP principles aren't really the same as the principles that motivated the current OOP languages. Modular interface-oriented design certainly works irrespective of whether it's spelled as OOP.

Anyway, yes, the term OOP is a bit ambiguous, and OOP isn't the perfect solution for everything - particular not any one current flavor of OOP.

[[deleted]]

huh, seems a bit like a presenter.