I want to create a simple "multi-agent" system consisting of three agents. For each agent, there is a type created encapsulating the mailbox processor. There are attributes common to all the agents (position, id etc.) and functions (sendMessage, move) and agents differs from each other with the implementation of mailbox processors (how the messages are processed). In addition, they may differ by other functions specific to particular agents. Every agent should also contain (as one of its attribute) a list of other agents, to whom it will be sending the messages. This is a just very simple model based on which I plan to play with the mailbox processors in F#.
In OOP, this would mean creating an agent interface (or abstract class), and all the particular agents would be inherited from this interface with their own implementation.
I know OOP is possible in F#, however I would rather stick to pure functional design. However, it seems to me that OOP is the most suitable approach in this case. I would be glad if you could give me any idea with respect to functional (F#) design? Thank you.
First of all, the functional style and object-oriented style in F# are not really in conflict.
Functional style consists of using immutable types, pure functions without side-effects and F# data types such as discriminated unions, functions etc.
Object-oriented style is more focused on how you organize code (using classes and interfaces), but the code can still be purely functional without using any mutable state.
In agent-based systems, it makes a good sense to use functional style in the implementation of the agent, but to organize the agents using classes. I think this is probably the best practice in F# (see also this article on encapsulating F# agents on MSDN).
In your example, you're saying that an agent keeps a list of other agents that it sends messages to. There are a few alternatives worth considering (if you want to avoid interfaces):
Expose an F# event (Event<'T>). This way, the agent simply exposes a notification and does not have to explicitly manage a list of other agents (and this design also allows other types of subscribers).
Keep a list of functions. If you just need to send messages to other agents, then you essentially need just an interface with a single method. In that case, you could keep a list of functions such as
Message -> unit.
I generally prefer exposing events - this way, the system is less tightly coupled and you can more easily compose agents in various ways (they do not have to implement a specific interface to be composed). This article discusses agent-based architectures from a higher-level perspective, and may be useful too.
Why would you want to stick to a pure functional design ? F# allows a clean combination of functional and OOP principles and I would make use of both mechanisms and leverage the power of the language.
If you want to combine the functional and OOP aspects, I would start by making your objects immutable. Thus you're using objects, but in a functional paradigm.
You have come up with an OOD, is it surprising that an OOP solution seems the most natural?
If you rewrote the design description with processes, and data transformations in mind it would naturally fall out as a FP design, and sound really awkward in OO with lots of 'er classes. As it is there is almost zero description of the types of data or what transformations need to take place. At first glance I would say an agent is a function of three arguments a mailbox, a message handler(or list of message handlers), and a list of other agents' mailboxes to contact. If future dispatch is based on the message then the message handler is a function of two args. the message, and the list of mailboxes.
Related
Did not find a more suitable SE site, so asking this here.
In BPM, there are more-or-less standard ways of marking activities - like Start (green circle), Stop (red circle), Conditional (yellow diamond). An example I found is here.
Conditional is basically an 'if' in any programming language.
What I could not find any example of is a 'switch'.
I know that one could use multiple Conditionals, but I have to implement a user friendly way, so I'd like to know if there is any standard way of representing such a thing in BPM.
It depends on what you mean by "switch". If you want to switch process flow in one or another way you can use Complex Gateway. A Complex Gateway allows the modeler to specify any arbitrary rules needed to determine how to emit tokens or process arriving tokens.
BPMN Complex Gateways can be used for splitting or merging a complicated process flow scenario. However, it is not recommended practice as there are simpler and more practical inclusive and exclusive gateways. There is always better to use their combination. You can learn more about complex gateways here.
Using non-deterministic functions is unavoidable in applications that talk to the real world. Making a clear separation between deterministic and non-deterministic is important.
Haskell has the IO monad that sets the impure context by looking at which we know that everything outside of it is pure. Which is nice, if you ask me, when it comes to unit testing one can tell which part of their code is ultimately testable and which is not.
I could not find anything that allows separating the two in F#. Does it mean there is just no way to do that?
The distinction between deterministic and non-deterministic function is not captured by the F# type system, but a typical F# system that needs to deal with non-determinism would use some structure (or "design pattern") that clearly separates the two.
If your core model is some computation that does not interact with the world (you only need to collect inputs and run the computation), then you can write most of your code as functional transformations on immutable data structures and then invoke these from some "main" I/O loop.
If you're writing some highly interactive or reactive application then you can use F# agents (here is an introductory article) and structure your application so that the non-determinism is safely contained in individual agents (see more about agent-based architectures)
F# is based on OCaml, and much like OCaml it isn't pure FP. I don't believe there is away to accomplish your goal in either language.
One way to manage it could be in making up a nominal type that would represent the notion of the real world and make sure each non-deterministic function takes its singleton as a parameter. This way all dependent functions would have to pass it on along the line. This makes a strong distinction between the two at a cost of some discipline and a bit of extra typing. Good thing about this approach is that it can verified by the compiler given necessary conditions are met.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is dependency injection?
I respond: "You don't need to use the new operator."
Interviewer's response: "<SIGH>. That's it?"
That's all I could come up with.
What would have been a more correct response if that is not correct?
It decouples a component from its external dependencies (e.g. other libraries, databases, etc.) allowing you to easily change them - even at runtime.
This can (for example) be useful in automated testing as you can inject mock objects via the public API.
Dependency injection decouples classes from the services they depend on, allowing you to register a set of services once and use them throughout your codebase.
This allows you to switch implementations non-intrusively, especially if the implementations are unit-tested.
It also allows you to put different service implementations with the same classes for different use-cases, such as web vs. GUI vs. testing.
The wikipedia article is a good reference: http://en.wikipedia.org/wiki/Dependency_injection.
Mainly, it reduces coupling and eases testing. You can conveniently unit test the class just by feeding it a mock instead of the real class. It's a good question in interviews to see if the candidate is familiar with TDD good practises.
Rather than thinking in terms of the words "dependency injection", think "list of factories". To use a real-world example, think of a catalog supply firm with thousands of different products. It would like to use a common scheme for keeping objects in inventory and reordering them when empty. It would be hard to run such a business if every product had its own independent means of ordering, and there had to be one person who knew how to order every product. That's not how businesses operate, however. Instead, there will be a file which contains for each product the information and procedures necessary to order it. Many products would use the same procedures, but a few products might require special procedures (e.g. call 815-555-6666 between 2pm and 3pm, ask for Steve, and ask him for widgets with blue end-caps, since the company normally puts on yellow end-caps).
Think of dependency injection as being the ability to include procurement instructions within the list of product types. Think of how smoothly the catalog firm can run with such ability, and how awkward it would be to have a firm of any size without it.
PS--"Dependency injection", like "Resource Allocation Is Initialization", is a phrase I dislike because its practical meaning has little to do with the words that comprise it. Most uses of DI don't seem to have much to do with "dependency", nor with "injecting" anything. I think "list of factories" is a word longer (but syllable shorter) and conveys the meaning much better. Incidentally, for RIAA, I'd substitute "object lifetime matches object scope".
I've read a lot about IoC and DI, but I'm not really convinced that you gain a lot by using them in most situations.
If you are writing code that needs pluggable components, then yes, I see the value. But if you are not, then I question whether changing a dependency from a class to an interface is really gaining you anything, other than more typing.
In some cases, I can see where IoC and DI help with mocking, but if you're not using Mocking, or TDD then what's the value? Is this a case of YAGNI?
I doubt you will have any hard data on it, so I will add some thoughts on it.
First, you don't use DI (or other SOLID principles) because it helps you do TDD. Its the other way around, you do TDD because it helps you with the design - which usually means you get code that follow those principles.
Discussing why to use interfaces is a different matter, see: https://stackoverflow.com/questions/667139/what-is-the-purpose-of-interfaces.
I will assume you agree that having your classes do many different things results in messy code. Thus, I am assuming you are already going for SRP.
Because you have different classes that do specific things, you need a way to relate them. If you relate them inside the classes (i.e. the constructors), you get plenty of code that uses specific versions of the classes. This means that making changes to the system will be hard.
You are going to need to change the system, that's a fact of software development. You can call YAGNI about not adding specific extra features, but not on that you won't be needing to change the system. In my case that's something really important as I do weekly sprints.
I use a DI framework where configuration is done through code. With a really small code configuration, you hook up lots of different relations. So, when you take away the discussion on interface vs. concrete classes, you are actually saving typing not the other way around. Also for the cases a concrete class is on the constructor, it hooks it up automatically (I don't have to configure) building the rest of the relations. It also allows me to control some objects life time, in particular I can configure an object to be a Singleton and it hands a single instance all the time.
Also note that just using these practices isn't more overhead. Using them for the first times, is what causes the overhead (because of the learning process + in some cases mind set change).
Bottom line: you ain't gonna need to put all those constructor calls all over the place to go faster.
The most significant gains from DI are not necessarily due to the use of interfaces. You do not actually need to use interfaces to have beneficial effects of dependency injection. If there's only one implementation you can probably inject that directly, and you can use a mix of classes and interfaces.
You're still getting loose coupling, and quite a few development environments you can introduce that interface with a few keypresses if needed.
Hard data on the value of loose coupling I cannot give, but it's been a vision in textbooks for as long as I can remember. Now it's real.
DI frameworks also give you some quite amazing features when it comes to hierarchical construction of large structures. Instead of looking for the leanest DI framework around, I'd recommend you look for a full-featured one. Less isn't always more, at least when it comes to learning about new ways of programming. Then you can go for less.
Apart from testing also the loose coupling is worth it.
I've worked on components for an embedded Java system, which had a fixed configuration of objects after startup (about 50 mostly different objects).
The first component was legacy code without dependency injection, and the subobjects where created all over the place. Now it happened several times that for some modification some code needed to talk to an object which was only available three constructors away. So what can you do but add another parameter to the constructor and pass it through, or even store it in a field to pass it on later. In the long run things became even more tangled than they already where.
The second component I developed from scratch, and used dependency injection (without knowing it at the time). That is, I had one factory which constructed all objects and injected then on a need to know basis. Adding another dependency was easy, just add it to the factory and the objects constructor (or add a setter to avoid loops). No unrelated code needed to be touched.
With the latest additions to our dependency injection framework (annotations in spring), the marginal cost of creating DI-managed components seems to have hit some critical new threshold. While there previously was an overhead associated with spring (tons of XML and additional indirections), dependency injection seems to have started going where lots of patterns go; they go under the hood and "disappear".
The consequence of this is that the conceptual overhead associated with a large number of components becomes acceptable. It's arguable that we could make a system where most classes only expose
one single public method and build the whole system by just aggregating these pieces like crazy. In our case a few things are given; the user interface of your application has some functional requirements that shape the topmost services. And the back-end systems control the lower part. But in between these two, everything is up for grabs.
Our constant discussion is really why are we grouping things in classes and what should the principles be ? A couple of things are certain; the facade pattern is dead and buried. Any service containing multiple unrelated features also tend to get split up. "Unrelated feature" is interpreted in an extremely much stricter sense than I have ever done earlier.
In our team there are two prevailing trains of thought here: Implementation dependencies restrict grouping; any functionality in a single class should preferably be a client of all injected dependencies. We are a DDD project and the other fraction thinks the domain restricts grouping (CustomerService or finer grained CustomerProductService, CustomerOrderService) - normalized usage of injected dependencies is unimportant.
So in the loosely coupled DI universe, why are we grouping logic in classes ?
edit: duffymo point out that this may be moving towards a functional style of programming; which brings up the issue of state. We have quite a few "State" objects that represent (small) pieces of relevant application state. We inject these into any service that has a legitimate need for this state. (The reason we use "State" objects instead of regular domain objects is that spring construct these at an unspecified time. I see this as a slight workaround or alternate solution to letting spring manage the actual creation of domain objects. There may be better solutions here).
So for instance any service that needs OrderSystemAccessControlState can just inject this, and the scope of this data is not readily known to the consumer. Some of the security-relate state is typically used at a lot of different levels but totally invisible on the levels in-between. I really think this violates fundamentally with functional principles. I even had a hard time adjusting to this concept form an OO perspective - but as long as the injected state is precise and strongly type then the need is legit aka the use case is proper.
The overriding principals of good OO Design do not stop at loose coupling, but also high cohesion, which gets ignored in most discussions.
High Cohesion
In computer programming, cohesion is a
measure of how strongly-related or
focused the responsibilities of a
single module are. As applied to
object-oriented programming, if the
methods that serve the given class
tend to be similar in many aspects,
then the class is said to have high
cohesion. In a highly-cohesive system,
code readability and the likelihood of
reuse is increased, while complexity
is kept manageable.
Cohesion is decreased if:
* The functionality embedded in a class, accessed through its methods,
have little in common.
* Methods carry out many varied activities, often using coarsely-grained or
unrelated sets of data.
Disadvantages of low cohesion (or "weak cohesion") are:
* Increased difficulty in understanding modules.
* Increased difficulty in maintaining a system, because logical changes in
the domain affect multiple modules, and because changes in one module
require changes in related modules.
* Increased difficulty in reusing a module because most applications
won’t need the random set of operations provided by a module.
One thing that gets lost when people go crazy with IoC containers is the cohesion is lost and traceability of what and how something does something becomes a nightmare to figure out later own down the road, because all the relationships are obscured by a bunch of XML configuration files ( Spring I am looking at you ) and poorly named implementation classes.
Why are we grouping things in classes and what should the principles be ?
Are you stressing the, "Grouping," or the, "Classes?"
If you're asking why are we grouping things, then I'd second Medelt's, "Maintainability," though I'd rephrase it as, "To reduce the potential cost of ripple effects."
Consider, for a moment, not the actual coupling between your components (classes, files, whatever they may be) but the potential coupling, that is, the maximum possible number of source code dependencies between those components.
There is a theorem which shows that, given a chain of components a - b - c - d - e, such that a depends on b, etc., the probability that changing e will then change the c component cannot be greater than the possibility that changing e will then change d. And in real software systems, the probability that changing e will affect c is usually less than the probability that changing e will affect d.
Of course, you might say, that's obvious. But we can make it even more obvious. In this example, d has a direct dependency on e, and c has an indirect (via d) dependency on e. Thus we can say that, statistically, a system formed predominantly of direct dependencies will suffer from a greater ripple effect than a system formed predominantly from indirect dependencies.
Given that, in the real world, each ripple effect costs money, we can say that the cost of ripple effect of an update to system formed predominantly of direct dependencies will be higher than the cost of ripple effect of an update to system formed predominantly of indirect dependencies.
Now, back to potential coupling. It's possible to show that, within an absolute encapsulation context (such as Java or C#, where recursive encapsulation is not widely employed) all components are potentially connected to one another via either a direct dependency or an indirect dependency with a single, intermediate component. Statistically, a system which minimises the direct potential coupling between its components minimises the potential cost of ripple effect due to any update.
And how do we achieve this distinction between direct and indirect potential coupling (as if we haven't already let the cat out of the bag)? With encapsulation.
Encapsulation is the property that the information contained in a modelled entity is accessible only through interactions at the interfaces supported by that modelled entity. The information (which can be data or behavior) which is not accessible through these interfaces is called, "Information hidden." By information-hiding behavior within a component, we guarantee that it can only be accessed indirectly (via the interfaces) by external components.
This necessarily requires some sort of grouping container in which some sort of finer-grained functionality can be information-hidden.
This is why we are, "Grouping," things.
As to why we're using classes to group things:
A) Classes provide a language-supported mechanism for encapsulation.
B) We're not just using classes: we're also using namespaces/packages for encapsulation.
Regards,
Ed.
I can think of two reasons.
Maintainability: You'll naturally expect some logic to go together. Logic that defines operations on one particular outside service for example a database should probably be grouped together in a logical way. You can do this in a namespace or a class.
State and identity: objects do not only contain logic but also maintain state. Logic that is part of the interface of working with the state of a particular object should be defined on that object. Objects also maintain identity, an object that models one entity in the problem domain should be one object in your software.
As a side-node: The state and identity argument is mostly applicable to domain objects. In most solutions I've used the IoC container mainly for the services around those. My domain objects are usually created and destroyed as part of the program flow and I usually use separate factory objects for this. The factories can then be injected and handled by the IoC container. I've had some success creating factories as wrappers around the IoC container. This way the container handles lifetime of the domain objects too.
This is a very interesting question. If I look back at the way I've implemented things in the past I can see a trend towards smaller and more granular interfaces and classes. Things certainly got better this way. I don't think the optimal solution has one function per class though. This will effectively mean you're using an OO language as a functional language and while functional languages are very powerful there is a lot to be said for combining the two paradigms.
Pure DI perfect universe, I think single classes+method design is ideal. In reality we need to balance the cost of that which makes it less feasible.
Cost factors
Overhead of DI. Spinning up all the underlying and related underlyings for a single method is expensive. Grouping into a class allows us to offset some of that.
Skills - DI is new to many (myself ESPECIALLY) so understanding how to do it better or get out of old/habitual designs is tough
Brown field apps which have them already, it's easier/cheaper/quicker to live with them and worry about this in future green field apps
Hopefully my newbie-ness (yes, I am filled with made up words) with DI hasn't made me completely wrong with this.