As of Chronicle-Queue v4.5.27, it seems like the ServiceWrapperBuilder needs to be enhanced to include StoreFileListener assignment? If there's a different construct, again, by way of ServiceWrapper queue creation, what is it?
The ServiceWrapperBuilder is intended as an example. Most likely you will want to build your own wrapper to suit your needs.
If there's a different construct, again, by way of ServiceWrapper queue creation, what is it?
Its the one you write. For our projects we write one to suit the project.
Related
I use Optaplanner as an optimisation library. I am trying to move away from XML configuration but I noticed that some of the *MoveSelectorConfig and *EntitySelectorConfig classes have set<X> methods instead of with<X> methods (e.g. setEntityClass(), setId(), setCacheType(), setSelectionOrder()). This makes it not possible to write a fully declarative configuration. Is this intended? What is the rationale? Are there plans to change this?
It is most definitely not intended, rather an oversight. If you want to report which builder methods are missing, we will eventually fix that. That said, since the setters are always there, this is not critical.
I have a class design that looks like this one:
When Main receives an item, properties of other items can change based on some rules. For example, if Item1 has a red color, item2.level must be 3. Sometimes a value can change properties of multiple items. Implementing all rules in Main class is possible but it's a mess code.
So, I have implemented the Aggregate class that include all items. When Main.setItem(item1) is executed, I update Aggregate with Aggregate.setItem1 and run Rules.updateAggregate that updates items of Aggregate according to all rules.
It works, but Rules class is very inefficient. Because it doesn't know which item has updated, it apply all rules all times. Also, updateAggregate method is very large and difficult to test.
Is there any better design?
To reduce the coupling you could use a design based on events.
Main and Item classes should be publishers of events and Item classes should be also subscribers of event types as they want to react to events.
You should define some event types. For example :
event type : "new Item with ..."
event type : "Item 1 changed the foo property"
and so for...
According to question and comments, here is one example of a design that could work. Gist link to the example code
The example is made using C# but should not have any problems to implement other languages. (Could be easier with dynamic languages)
The design probably doesn’t fit directly to your use case but here are a few points what I try to demonstrate with it and maybe you can find better ideas with this way.
I made a few iterations and this was the first version that I could work on a similar use case without any third party libraries.
Main points of design
In the example, I try to keep Item -classes very clean from rules.
Rules -class is disappeared because, in the example, rules are in Aggregate class. However, I don’t see any problem to implement the same rules in separated Rules class, if needed. I don’t know exactly how complex your rules are and tried to keep the example simple.
The aggregate has methods to raise “notification” about Item changes.
I didn’t test my example but the implementation should be easier to test. For example, you should be put Items on specific state and try how rule behavior works. This can be validated to use unit tests but I didn't have any real use cases.
I tried to kept classes decoupled as possible.
Downsides
Depending on your needs, classes can be too coupled. Specially Aggregate can contain a lot of code so the more decoupled solution should be possible.
Implementation can be varied by programming languages and not always so clean. Originally, I used a similar pattern with event sourcing and modified to this example.
If a number of Items are huge, then the design is not very flexible.
How to improve
As said in comments and other answers, event-based implementation is probably what you want. I used Observer pattern as a starting point but it was going towards event-based implementation.
You should also look at some event-driven libraries that can have a good example of how to implement an application that reacts to changes. Also, those libraries usually help to wire up objects and give more decoupled implementation. Of course, then you are coupled with those libraries but probably not a bad case. No need to reinvent this mechanism anyway.
Check following links that can help with new ideas. Observer vs pub-sub pattern
I completelly agree with #davidxxx that events based design is better approach in your case. You can have a look at the observer design pattern. In case your business logic is so complex that you are not able to provide reqired parameters , you can always inject the whole list/tree/whatever of items and perform find operations on it.
Creating a module (bundle, package, whatever) with only interfaces seems to me a strange idea. Yet, I don't know the other best solution to solve the following architectural requirement.
There often appears a need for a set of utilities. In many projects I can see the creation of "utils" folder, or even a seperate package (module) with frequently used ones.
Now consider the idea that you don't want to depend upon a concrete utils set. Instead you, therefore, use interfaces.
So you may create the whole project, with multiple modules, dependent only on the "Utils-Interfaces" set, which could be a separate module. Then you think you can re-use it in other projects, as these utils are frequently used.
So what do you do? Create a seperate module (package, bundle...) with interfaces with definitions of the methods to be implemented by concrete utility-classes? And re-use this "glue-interfaces-packages" (possibly with other "glues", such as bridges, providers etc.) in your various other projects? Or is there a better way to design the archictecture regarding the utilities that could be easily switched from one to another?
It seems a bit odd to have an interface for utility methods as it should be clear what they do. Also in most language you won't have static dispatch anymore. And you wouldn't solve a problem by having interfaces for utility methods. I think it would make more sense to look for a library doing the same thing or writing your own if such functionality isn't already implemented. Very specific things should be tied to the project, though.
Let's look at an example in Java:
public static boolean isDigitOnly(String text) {
return "\\d+".matches(text);
}
Let's assume one would use an interface. That would mean that you have to have an instance of such an implementation, most likely a singleton. So what's the point of that? You would write the method head twice and you don't have any advantage; interfaces are used for loose coupling, however such generic utility methods aren't bound to your application.
So maybe you just want to use a library. And actually there is one for exactly this use case: Apache Commons. Of course you may not want to include such a big library for a single method. However, if you need this many utility methods you may want to use it.
Now I've explained how to use and reuse utility methods; however, a part of your question was about using different implementations.
I can't see many cases you wanted this. If, for example, you have a method specific to a certain implementation of sockets, you may instead want
A) the utility method as a part of the API
B) an interface for different socket implementations on which you have one common utility method
If you cannot apply this to your problem, it's probably not a utility method or I didn't consider it. If you could provide me with a more specific problem I'd be happy to give you a more concrete answer.
In objective-c when you are implementing a method that is going to perform a repetitive operations, for example, you need to choice in between the several options that the language brings you:
#interface FancyMutableCollection : NSObject { }
-(void)sortUsingSelector:(SEL)comparator;
// or ...
-(void)sortUsingComparator:(NSComparator)cmptr;
#end
I was wondering which one is better?
Objective-c provides many options: selectors, blocks, pointers to functions, instances of a class that conforms a protocol, etc.
Some times the choice is clear, because only one method suits your needs, but what about the rest? I don't expect this to be just a matter of fashion.
Are there any rules to know when to use selectors and when to use blocks?
The main difference I can think of is that with blocks, they act like closures so they capture all of the variables in the scope around them. This is good for when you already have the variables there and don't want to create an instance variable just to hold that variable temporarily so that the action selector can access it when it is run.
With relation to collections, blocks have the added ability to be run concurrently if there are multiple cores in the system. Currently in the iPhone there isn't, but the iPad 2 does have it and it is probable that future iPhone models will have multiple cores. Using blocks, in this case, would allow your app to scale automatically in the future.
In some cases, blocks are just easier to read as well because the callback code is right next to the code that's calling it back. This is not always the case of course, but when sometimes it does simply make the code easier to read.
Sorry to refer you to the documentation, but for a more comprehensive overview of the pros/cons of blocks, take a look at this page.
As Apple puts it:
Blocks represent typically small, self-contained pieces of code. As such, they’re particularly useful as a means of encapsulating units of work that may be executed concurrently, or over items in a collection, or as a callback when another operation has finished.
Blocks are a useful alternative to traditional callback functions for two main reasons:
They allow you to write code at the point of invocation that is executed later in the context of the method implementation.
Blocks are thus often parameters of framework methods.
They allow access to local variables.
Rather than using callbacks requiring a data structure that embodies all the contextual information you need to perform an operation, you simply access local variables directly.
On this page
The one that's better is whichever one works better in the situation at hand. If your objects all implement a comparison selector that supports the ordering you want, use that. If not, a block will probably be easier.
I have spent the last couple of hours reading about the singleton pattern and why not to use it, amongst others those really good sites:
Singleton I love you, but you're bringing me down
How to Think About the "new" Operator with Respect to Unit Testing
Where have all the Singletons Gone?
I guess quite a lot of you know these already.
Looking at my code after reading that, I clearly am one of the maybe 95% of programmers that misunderstood and misused the singleton pattern.
For some cases, I can clearly remove the pattern, but there are cases where I am unsure what to do:
I know singletons for logging are accepted, one reason for that being that information only flows into them but not back into the application (just into the log file or console etc of course).
What about other classes which do not meet that criteria but are required by a lot of classes?
For example, I have a settings object which is required by a lot of classes. By a lot, I mean more than 200.
I have read into some other SO questions like "Singletons: good design or a crutch?", and all of them pointed out why using singletons is discouraged.
I understand the reasons for that, but I still have one major question:
How do I design a class which needs a single instance, accessible from everywhere, if not using the Singleton pattern?
The options I can think of would be:
Use a static class instead (though I don't see how this would be any better, looking at OOP and unit testing).
Have it created in an ApplicationFactory and perform dependency injection on every single class that needs it (keep in mind it's 200+ for some cases).
Use a singleton anyway, as the global access bonus outweighs the disadvantages for that case.
Something completely different.
It will depend on exactly what you mean by a settings object.
Do all 200 classes need all the settings; if not why do they have access to the unused settings?
Where do the settings come from and is there a good reason why each class can't load its settings as and when required?
Most importantly though, don't make changes to working code just because the code uses a pattern which is frowned upon. I've only used the singleton pattern once but I'd use it again.
EDIT:
I don't know your constraints but I wouldn't worry about multiple access from a file until it had been shown to be an issue. I would split up the configuration into different files for different classes/ groups of classes or, preferably, use a DB instead of files with different tables providing data for each class.
As an aside I've noticed that once you put the data in a db people seem to stop worrying about accessing it multiple times even though you're still going to the file system in the end.
PS: If other options aren't suitable I'd use a singleton... you want data to be globally available, you're not willing to use dependency injection, you only want the file to be read once; you've limited your options and a singleton isn't that bad.
Isn't this already discussed extensively and exhaustingly?
There is no misuse of the pattern. If your software works as expected (inlcuding maintainability and testablility) you are right with singletons.
The thing about people complain is that the singleton pattern has more impact than only restrict a class to have a single instance.
you introduce a global variable
you cannot build a subclass
you cannot reset the instance
If all this is not a problem for you: Use singletons all over the place. The pattern discussion is academic and hairsplitting.
And - to answer your question - checkout the monostate vs singleton thread: Monostate vs. Singleton