We Keep Coding

MVP Clean Architecture - where do calculation and non data related tasks belong?

I've been doing a lot of research and trying to use MVP with Clean Architecture in my app, but still i have a lot of confusion and don't understand it completely. My biggest doubt is: where should non database related, like complex ma mathematical calculations, logic go? Every example app on the internet i found has to simply save and retrieve some data from the database.
For instance i have a screen where user need to insert 4 values and then i have code that takes this values, perform some calculations and return object that represents data to be displayed.
My question now is: where should i position the class or code responsible for producing the result in an MVP with clean architecture project, with following structure:
view <--> presenter <--> use cases <--> repositories
View sends input to the presenter, but then ? Also many examples use different "services" classes and in some of them they are connected to presenter and in other to repository.

Use cases are part of the model. In the model there are the data (the pojos to define how the data is stored in memory) and the use cases.
All your business logic as this complex mathematical calculations must be in one or many use cases.
The view will get the data and pass it to the presenter which should create a thread (in one of the many ways to run code asynchronously, I like using threadpoolexecutors for this) to run the use case which will do the maths and answer the presenter. And finally, the presenter will send the data back to the view.
Unless you have to retrieve any data (from sensors, files, databases, url responses...) or permanently store it I don't think you need a repository in this case.

You should write your complex and logical code in presenter itself
why?->
if you ever need any database values so you can get it from presenter by running thread and do further calculations.
if is there any validations you should use common classes to get the result
for ex.
view needs some result on inputs you can pass it to presenter ,
presenter will process the inputs and return the data back to view.
follow this link it will help you to understand MVP like a pro

Creating a standard graph builder using OOP and Design Patterns

This is an example of my firms costum made chart with connected table.
UPDATE my full idea
i have been given this alot of thinking since i started this post and i have finally come up with an idea that i think is solid using the Builder pattern i want to you guys what you think and what issues you think that i might run into. First let me explain the full idea:
My Company need some sort of Standard graph with a connected table that they can use for all of their programs (This will give the programs a feeling that they are all alike (which they are)) Since most of these charts are alike i thought i could easy the pain of creating a new chart every time you have to make a new program or have to place the chart somewhere else.
My Company use three diffrent charts primarily:
Barchart
LineChart
PieChart
When creating these charts there are a few unknown variables.
Name of the chart series: This is the name that will be display and this differs from every line/bar/ pie slice
Period: Chart data is taken from a period of time, either a day or a week (every day Monday, Tuesday, Wednesday etc) a month (Jan,Feb,mar,April etc) or even time of day.(8pm,9pm etc).
Type of chart: of-course a difference is what type of chart the user wants to see.
Last but not least the only difference between the chart creating lies within the Piechart, the pieChart is the only chart in Javafx that is not created from series but is created from an Observable list, so the pieChartBuilder has to use and insert the data in a different way than the others.
The picture above is Not an UML diagram it is a demonstration of how i plan my new program(s) to behave and adjust the design pattern, here is a walk through of what my thought are:
GUI: First the Gui is always separated from the actual logic i have no plans of demanding anything from the GUI except that it has to created in JavaFx and it has to have an instance of the Director class.
Director: The Director class is where all the action happens. First the client calls the director with what type of chart he wants to get, what period of time he wants data from and maybe what kind of data he wants to see. The client also sets the time period that he wishes to see the data in (day, week, month , year etc).
The Director then takes all of that data and class his instance of the statistic class asking the class for data that the director can then pass on the the Chart builder.
Statistics: the statistics class then checks if it already contains data and if not it class for a list of object to the database:
DataBase: The database is quite straight forward it class for the data in the time period that client has send on (either on a day, week, month, year basis) creates the object(s) add them to a list and return it to the statistics class.
(back in the) statistic class the objects data are then calculated and returned to the director.
(Back in the director) The director now calls the chartBuilder to build a chart of the type specified by the client with the timeframe (which is an array or an arraylist of time, This is an option the client can set in the director using Director.setStandardTime(time)) the builder then creates the chart and table with the data obtained from the Director. The client is then able to call ChartBuilder.getChart() and add that to his layout.
This is my idea. i Would love for you to comment on it. Thank you for reading and i will be looking forward to read all of your responses.

The most common Design Patterns for graphics tasks are Decorator (often with a "fluent" interface), Prototype/Clone and Visitor. These will proably come in handy.
Decorator: For when you want to add attributes to your object incrementally. Such as:
final int radius = 100;
// With fluent interface
final Graphic boxedShadedCircle = new Circle(radius, 100, 100).shaded().boxed();
// Without fluent interface
final Graphic nonFLuentBoxedShadedCircle = new Boxed(new Shaded(new Circle(radius, 100, 100)));
Prototype/Clone: For when you want to be able to duplicate some object (copy/paste functionality). It's basically the interface Clonable.
Visitor: When you want to add functionality to objects without adding to the code in the actual object. Say, if your application is somehow scriptable. See this post for an example:Visitor pattern
Now to relate to your specific solutions:
It seems like Decorator would be a good way to implement your first solution proposal. Alternatively Template method or some sort of composition ("combine generic graph drawer with data object").
For your second solution, Factory seems appropriate.
I can't say which is best. It depends on your local circumstances. All implementations have pros and cons, and the trick is to pick the appropriate one where the pros outweigh the cons.
Updates for the updated question:
ChartBuilder: This should probably be design pattern "Builder". This dp is about representing or rendering an abstract description/product such as a document description or a data set in different ways.
Director: This is Design patter Mediator. Or Facade, depending on intent. Facade if you are "hiding away" a ball of crappy legacy code, Mediator if you are coordinating the interaction of several more modern classes. Lots of grey area here. If Director also handles interaction with the GUI (resize, hide etc) it's definitely Mediator.
Overall, your structure is model/viewer/controller. Director acts as controller, Statistics acts as model, chartBuilder acts as viewer.
It's not uncommon to have several design patterns overlap, as in having the controller act as mediator.
You may be happier if you implement the whole thing as request/response using design pattern Observer for the response, rather than as straight calls with return values. It's more flexible that way, and you can hide latency/calculation/database lookup in a thread better.
You may want to use Composite for chartBuilder. If you want to have several views on the data active at the same time, rather than just one.

Take a look at EyeSee, and make a java implementation

Designing a program with statistics

I am about to start my newest project, it is basicly an application that gets some data from a database and then display that data a graph!
now even though that this may seem simple it is important to me that this is done in a very correct way when it comes to object orientated programming.
Now my idea was the following:
I wanted to create the following four classes:
Adapter:
The class that connects the application to the database and recives the data
CallQueue:
This is an object that differences depending on what type of data is recived from the database and what type of data you wish to show on your graph. An example of this would be Cheese and fruits. both of them are food but they are very different types of food.
Statistics
This would be a tool class used to calculate the information recived from the database (for example changeing it to percentage instead of raw data)
Graph
This would be the class that gets the information from the statistic class and turns the numbers into a graph
GUI
This is ofcourse the GUI class where i will post the graph on!
Now i want to make the project as object orientated as possible. But my problem is that the information from the database is not always the same. For example if get the data from a day to day basis it will be different than from month to month. This means that the information is always going to change depending on what the user need.
How would i make this program object orientated ? and what type of connections should my classes have to eachother to make it most accessible. Do i have to create subclasses in order to simplify it?
should i add all information from the datbase directly into the CallQueue Class or should that object be created later on?
Update - Elaboration
The name callQueue is not a streaming implementation it is marely an object that should contain values of the data recived from the database (note that this is still in the idea phase and nothing is implemented). The idea is that a user opens the program and then chooses a day from and then a day to for instance: 04/11/2012 to 10/11/2012. The reason the objects value changes is when the day changes for instance to the following: 04/11/2012 - 04/12/2012 then a new graph will be created new information from the database will be calculated ect ect.
One thing that i am confused about aswell is the following:
When you have an object that is created from the database (adapater Note this could be optimized if you guys have a better idea) then how would you calculate statistics from that? would it be better that the statistic class called the adapter for data then worked with the data and then created the objects contain the calculated data?
Then the Graph class would need to get the objects data and insert into the graph.

From experience designing large systems and even smaller, the best approach is to think in terms of components rather than classes. This will allow you to break down your problems into smaller (and mostly independent) pieces.
So for example, you will have a component which sole responsibility will be to bring the data to your application for processing. That component will need to be able to deal with the multiple data sources, etc... That then becomes a sub-system that you can design independently from the rest of the application and deals with a specific problem, smaller than the whole.
If the sub-problems are still larger than they should, keep breaking them down into sub-compoennts, until the implementation of the components becomes almost trivial. At that point, you can start bringing in the notion of classes because you have enough visibility on the protagonists in your system.
In short, I put a lot of emphasis on separation of concerns. By isolating sub-problems into sub-components, you also isolate the solutions which makes it easier to correct your design mistakes or replace implementations without impacting the entire system.
Just my two cents...

Designing a point system in Spring

I have a lot of existing data in my database already, and want to develop a points mechanism that computes a score for each user based on what actions they do.
I am implementing this functionality in a pluggable way, so that it is independent of the main logic, and relies on Spring events being sent around, once an entity gets modified.
The problem is what to do with the existing data. I do not want to start collecting points from now, but rather include all the data until now.
What is the most practical way to do this? Should I design my plugins in such a way as to provide for an index() method, which will force my system to fetch every single entity from the database, send an EntityDirtyEvent, to fire the points plugins, for each one, and then update it, to let points get saved next to each entity. That could result in a lot of overhead, right?
The simplest thing would be to create a complex stored procedure, and then make the index() call that stored procedure. That however, seems to me like a bad thing either. Since I will have to write the logic for computing the points in java anyway, why have it once again in SQL? Also, in general I am not a fan of splitting business logic into the different layers.
Has anyone done this before? Please help.

First let's distinguish between the implementation strategy and business rules.
Since you already have the data, consider obtaining results directly from the data. This forms the data domain model. Design the data model to store all your data. Then, create a set of queries, views and stored procedures to access and update the data.
Once you have those views, use a data access library such as Spring JDBC Template to fetch this data and represent them into java objects (lists, maps, persons, point-tables etc).
What you have completed thus far does not change much, irrespective of what happens in the upper layers of the system. This is called Model.
Then, develop a rule base or logic implementation which determines, under what inputs, user actions, data conditions or for all other conditions, what data is needed. In mathetical sense, this is like a matrix. In programming sense, this would be a set of logic statements. If this and this and this is true, then get this data, else get that data, etc. This encompasses the logic in your system. Hence it is called "Controller".
Do not move this logic into the queries/stored procedure/views.
Then finally develop a front-end or "console" for this. In the simplest case, develop a console input system, which takes a .. and displays a set of results. This is your "view" of the system.
You can eventually develop the view into a web application. The above command-line view can still be viable in the form of a Restful API server.

I think there is one problem here to be considered: as I understand there's huge data in the Database so the idea to create only one mechanism to calculate the point system could not be the best approach.
In fact if you don't want to start collecting points but include all the data, you must process and calculate the information you have now. Yes, the first time you will run this can result an overhead, but as you said, you need this data calculated.
By other hand you may include another mechanism that attends changes in an entity and launches a different process capable of calculate the new pointing diffence that applies to this particular modification.
So, you can use one Service responsible of calculate the pointing system, one for a single entity and another, may be longer to finish, capable of calculate the global points. Even, if you don't need to be calculated in real-time you can create a scheduled job responsible of launch it.
Finally, I know it's not a good approach to split the business logic in two layers (Db + Java) but sometimes is a requirement do it, for example, if you need to reply quickly to a request that finally works with a lot of registries. I've found some cases that there's no other option than add business logic to the database (as a stored procedures, etc) to manage a lot of data and return the final result to the browser client (ex: calculation process in one specific time).

You seem to be heading in the right direction. You know you want your "points" thing decoupled from the main application. Since it is implied you are already using hibernate (by the tag!), you can tap into the hibernate event system (see here section 14.2). Depending upon the size/complexity of your system, you can plugin your points calculations here (if it is not a large/complex system), or you can publish your own event to be picked up by whatever software is listening.
The point in either design approach is that neither knows or cares about your point calculations. If you are, as I am guessing, trying to create a fairly general purpose plugin mechanism, then you publish your own events to that system from this tie-in point. Then if you have no plug-ins on a given install/setup, then no one gets/processes the events. If you have multiple plug-ins on another install/setup, then they each can decide what processing they need to do based upon the event received. In the case of the "points plugin" it would calculate it's point value and store it. No stored proc required....

You're trying to accomplish "bootstrapping." The approach you choose should depend on how complicated the point calculations are. If stored procedures or plain update statements are the simplest solution, do that.
If the calculations are complicated, write a batch job that loads your existing data, probably orders it oldest first, and fires the events corresponding to that data as if they've just happened. The code which deals with an event should be exactly the same code that will deal with a future event, so you won't have to write any additional code other than the batch jobs themselves.
Since you're only going to run this thing once, go with the simplest solution, even if it is quick and dirty.

There are two different ways.
One is you already know that - poll the database for for changed data. In that case you are hitting the database when there may not be change and it may slow down your process.
Second approach - Whenever change happens in database, the database will fire the event. That you can to using CDC (Change Data Capture). It will minimize the overhead.
You can look for more options in Spring Integration

GUI patterns in Java/GWT - general approach

I'm helping to build a GWT application for a client and rewrote most of the stuff to work better, shorter code, faster, etc. However in all the GUI application I've worked on (not so many really) there comes a flexing point where you just have to put a lot of rules and move logic from the listeners to some common mediator. Then some times this could get an ugly mess so you whatever small think you need to do in the listener.
Let's take an example:
form with 10-20 fields
two exclusive radio control about half of the state of the other fields (enabling, validation, input limits)
three exclusive radio controls control again almost the same fields, but in a different way (affecting calculations, enabling); they are also controlled by the above
4 or so number fields are validated on the fly depending on the previous selections and some real-time data object; they can have upper/lower limits, be enabled/disabled
one drop-down box controls the next 6 or so controls - displaying/hiding them, modifying validators
some checkboxes (shown by the above combo) activate some input fields and also determine their validation algorithm
While everything is up an running, without known bugs, there are a few coding gotchas that really bother me:
code is spread among listeners and some mediator methods.
loading the form with some preset values presents its own challenges: like data objects that might be available or not, data objects that might alter their state and subsequent field behaviour
some fields are having a default value set and this should not be overwritten by automatic filling, but if the data objects are not there (yet) then they will need to be filled eventually when the later become available
form cannot be submitted if any of the fields are not validated
My approach:
identify which fields share a common afair and move code into one place
each radio group shares a single listener implementation between its radios
default form filling is deferred until the live data is available (as much as possible) and as a result it gets called multiple times
each action has a call to a common validator method
the validator runs through all the fields in the form, calls their validators (which highlight all errors) and returns a single boolean
each relevant keypress or mouse action, data change it gets deferred to be called after 250ms from the last call; this means first call just places the validator as a delayed action, subsequent calls reset the timer
Ok, it doesn't make any sense to dwelve into more details but I'm more upset about the fact that there is no clear separation between visual actions (enabling), data actions (setting form field values), field listeners, retrieving form values and live data listeners.
What would be a good approach/pattern (next time maybe) to make sure that MVC get separated and lends itself better to maintenance? I know this is not a typical question but I've read every documentation I could get my hands on and still did not find some helpful answer.

I'd move closer towards MVP than MVC. It's clearly the way Google intends to go, so adopting it will probably mean that you're able to go with the flow rather than fight the current.
How does this affect you? Well, I believe you should accept that a tidier implementation may involve more code: not the 'shorter code' you were hoping for. But, if it's logically structured, efficient code the Google compiler should be able to trim lots out in the compiler optimisation phase.
So, move as much of the logic as you can into the model layer. Test this thoroughly, and verify that the correct level of page reset/tidying happens (all of this can be done with plain JUnit, without any UI). Next, use your Presenter (Activity) to tie the View to the Model: handling the interactions, populating the fields, etc.

you can divide a Huge class in different classes bu dividing the GUI in different JPanels. All the panels are implemented in different classes extending JPanel. Guess that would help you.