Designing A reader and Processor using Java

I am writing a Core java module, where in there, there are events which are read and then those read events are needed to be organized into some form

I have figured the OOPS deign something like this

EventManager has Two Objects, EventReader and EventScheduler

The EventReader reads the data from the text input file and gives back an array of Objects of type Event.

The EventScheduler takes in as input the Event array object and processes them (including sorting the array as per its convince, then arrange them as using (KnapSackProblem) according to some criteria).

Inside the EventScheduler, I have kept methods which sorts and then arranges the Events as per the desired output.

So Is this design High Cohesion and Loose Coupling.. Threotically atleast.. Since I cannot share the entire diagram on the site.

I need a good design and wanted to know what is the correct design for this scenario.

Kindly let me know if you need more design information in this regards to understand the scenario more.

Any Help will be most welcome!

Thanks in Advance :) Cheers

basic java design approach for memeber fields

Suppose you have this low level work Java class with a public method with input parameters and other private methods to manipulate this input data . Which is the preferable approach : set the input data into member fields so no need to pass it between private methods, or pass it as parameters to private methods?

Observer Patter, or just modify the object in another class?

lets say, in our system when an user registers, he gets a voucher too right away. There are 3 solutions:

1,

class UserModel
{
    public function create ($username)
    {
        $userId = SQL INSERT INTO users
        Voucer::create ($userId);
    }
}

but its bad (hurt SRP and LoD)

2,

class ModelHelper
{
    public static function create ($username)
    {
        $userId = UserModel::create ($userName);
        Voucer::create ($userId);
    }
}

it only hurts LoD now.

3, a solution using Observer Pattern (Im not going to provide a source code right here).

So which is the best?

What is the use of the enum singleton in Java? [duplicate]

This question already has an answer here:

• Implementing Singleton as Enum in Java 5 answers

When the Gang of four introduced the singleton pattern, they also had to explain, why not to use static class fields and method instead. The reason was: the possibility to inherit. For Java it had sense - we cannot normally inherit the class fields and methods.

Later the "Effective Java" book appeared. And we know now that the existence of reflection destroys the singularity of the singleton class with private constructor. And the only way to make a real SINGLEton is to make it as a single item of an enumeration. Nice. I had done some myself this way.

But a question remains: While we cannot inherit from enumeration, what is the use of this singleton? Why we don't use these old good static/class fields and methods?

Design pattern: bundle models in controller or in service

We use asp.net mvc with Entity Framework as our ORM.

Our database is really old and was built long time ago. So foreign keys are missing and we can't add it now. We need to bundle different models into ViewModels. We are not sure if we should do the initial model bundling in difference service methods or in the controller.

So my question is what design pattern and practice you think is best. Bundle in controller:

 public class PlayerController : ApiController
 {
     private readonly PlayerService _playerService;
     private readonly ItemService _itemService;

     public PlayerController(PlayerService playerService, ItemService itemService)
     {
         _playerService = playerService;
         _itemService = itemService;
     }


     public UserViewModel Get(int id)
     {
        var user = playerService.GetUser(id);
         var item = itemService.GetItem(id);
         var userViewModel = Mapper.Map<UserViewModel(user);
         userViewModel.item = Mapper.Map<ItemViewModel(item);
         return userViewModel;
     }
 }

Or bundle in the service:

public class PlayerController : ApiController
 {
     private readonly PlayerService _playerService;
     private readonly ItemService _itemService;

     public PlayerController(PlayerService playerService, ItemService itemService)
     {
         _playerService = playerService;
         _itemService = itemService;
     }


     public UserViewModel Get(int id)
     {
        var userWithItem = playerService.GetUserWithItem(id);
        return Mapper.Map<UserViewModel(userWithItem);
     }
 }

The call to getting the item would be done in the "GetUserWithItem" instead, like this:

public User GetUserWithItem(int id)
{
    var user = _dbContext.user.Find(id);
    user.Item = _dbContext.item.Where(x=>x.userId => id);

    return user;
}

Which is the 'correct' way of doing it that would offer most benefits?

Logic inside BuilderPattern

Recently I came across with a builder pattern that intrigued me.

So, I have an EntityBuilder which builds an Entity, but it doesn't return the entity. Here is the method signature:

public void build();

Instead, inside the build() method, it delivers the new object created, the Entity, to a CacheImplementation instance to store it. Note: the CacheImpl is injected in the builder's constructor.

public void build(){
    //create new entity
    cacheImplementation.add(entity);
}

Does this sounds like best practice?

Logic inside BuilderPattern

I have a brief question. Recently i came across with a builder pattern that intrigued me.

So, i have an EntityBuilder which builds an Entity, but it doesn't return the entity. Here is the method signature:

public void build();

Instead, inside the build method, it delivers the new object created, the Entity, to a CacheImplementation instance to store it. Note: the CacheImpl is injected in the builder's constructor.

public void build(){
    //create new entity
    cacheImplementation.add(entity);
}

Does this sounds like best practice?

Thanks, Vlad