I'm curious as to which is the better practice and the reasoning behind it, for this example I'm going to be using a social application which contains a 'friends' and a 'ignore' list with some custom logic based on them, (For sending messages directly, etc)
Which would be the better practice, and why?
Scenario 1:
class user {
List<> friends;
List<> ignores;
...
logical methods here
}
Scenario 2:
class User {
Social social;
...
}
class Social {
List<> friends;
List<> ignores;
...
logical methods here
}
I've seen both scenarios used throughout numerous applications and I'm curious as to which is the "Correct" way to lay it out in java, these will have methods such as
#addFriend(User user)
check ignore
check valid user
check other info
add to list
end
#getFriend(int id)
find friend by id
check online status
return friend
It seems like while have a 'Social' class may be a cleaner approach, does it really follow good practices? Seems like it'd use more memory/user just for cleaner code.
The reason why you have such constructs as your Social, most of the time, is that they represent a logical set of data and operations which is needed for different entities in your application.
If nothing other than User has those properties and actions, then there is no point in doing it separately from User. But you may design it separately anyway, for future uses (for example, if you want to be able to expand it later and you believe there will be other entities which will need Social functionality).
Looking at this from an object-oriented viewpoint, it means that the Social is a type. And then you have to ask yourself, is whether your User is_a Social or whether your User has_a Social. Does it make sense to say that the user has a "social subsystem" or is the user a "social object"? If the correct relation is is_a, then User should extend Social. If not, it should have a Social member, such as you described.
However, in Java, since you can't have multiple inheritance of implementation, sometimes your type may inherit from several types, and you have to decide which of them to extend. Many times, you simulate multiple inheritance of implementation, by having a member of what should have been the "second parent class", declare all the methods in your class, and delegate them to that member.
So the general guidelines are, more or less:
If in your application's domain, the only class where it will make sense to have friends and ignores and their operations is User, and no other conceivable entity would ever need them, then implement them directly in User.
If other entities may need similar functionality, and not all of them extend User anyway, you may consider this functionality to be an entity or class in its own right, and then you should have every class which has an is_a relationship to this entity extend it.
If Java's limitations of multiple inheritance don't allow extending directly, as it makes more sense for the class to extend some other class, you should embed an object and delegate the operations.
There may be other practical reasons to separate the Social entity from User, despite User being the only class to use them. For example, if you have several different possible implementations of "social" behavior, you may want to be able to use various Social subclasses as "plug-ins" inside User, rather than subclassing User.
Don't worry about memory so early. Go for readable/cleaner code. Premature optimization is root of all evil.
This is really based on the logic of your program. But consider that increasing the number of classes unnecessarily, is not good practice.
In your example, if the User class only contains a Social field, and you will just delegate all the method calls to the Social class, then go with scenario one.
On the other hand, if the User class has many more fields, like name, date of joining ... then it would be even better to create a separate class for such fields such as UserInfo in order to better structure your program and enhance code readability.
Now the main concerns are not the memory or performance costs of class structure.
Way more important are readability and clean code, AND the possibility to persist domain classes in a DB in the most simple and efficient way.
The later include composition or aggregation concern which is specific for different DB's.
You should care about the design aspects becoz with this you will have maintainable,scalable and readable code.
Now going by your example , i find second scenario as good case as it follows the SRP(Single Responsibilty Principle)
Don't worry about memory here as it wont make iota of difference here.
So do you want to do something like:
for(Connection connection : userSocialConnections ){
sendMessageTo(connection);
}
If so, then the method sendMessageTo would need to accept a connection (friend or ignored, basically a user) and probably if the runtype connection is ignored (or has blocked the user) then the sendMessageTo will return without sending a message polymorphically. This would require that in java that the IgnoredPeople And Friends are subtypes of something called as Connection(or people or anything you like; in fact, a connection is also a user - current or potential, isn't it?). This approach seems (to me) more like thinking in problem domain. Storing as two list inside user or inside social inside user does not matter much as long as they both (ignored and friends) have a common interface.
I would ask, what all other scenarios can be there for user's friends or ignored list. Do they need to be loaded lazily or stored separately.
Related
can you tell me what are the best practices to distinguish DTO's which serve for transfer data for frontend (for instance show user profile) and DTO's which serve for some action (for instance create user, update user, ...)
What do you think about naming like this:
CreateUserDto, UpdateUserDto for action and UserDto, UserBaseDto for showing data on FE? I was also thinking about using suffix Command like CreateUserCommand instead of DTO suffix.
There's no distinction - in both cases you're talking about data transfer object. It's what sent back and/or forth. Moreover if your UI creates a user then it may use the same structure (hence same DTO) for GETing and POSTing - which I think is a widespread scenario.
There are no common conventions and thus your question boils down to "how to name a class or a package in my particular case" which opens a lot of possibilities. Like CreateUserDto that you suggested, or UserCreationRequestDto, or simply putting these classes into different packages.
Command is a GoF design pattern which has nothing to do with DTOs, so it may lead to confusion.
I am doing an android application that has two types of users, doctors and patients.
For the most part they do the same thing but in certain activities they do different things.
For example, in the calendar activity, the doctor fills out available appointment times they have, whereas the patient fills out their medications in their calendar.
In my use case diagram I have put the steps each user type takes in separate sections. Is this the correct way to do it or should I just do one section that has one actor called 'user' that outlines the generic tasks they share.
Click here to see my use case diagram
Any feedback is greatly appreciated
Your diagram seems more like a workflow, not a Use Case. Use Cases are at a very high level of abstraction. Also, they are purely Functional decompositions of the application, where you should avoid making premature design decisions. A Use Case shows the different actors that are involved and the actions they want to perform. Making them takes a systematic approach to ensure no bits of functionality are missed.
Important elements in a Use Case Diagram are:
The various actors using the application, including those responsible for the 'backend' and maintenance.
What the actors actually want to accomplish as the main Use Cases.
All derived Use Cases that are necessary to implement the main Uses Cases. I prefer the <<includes>> relationship to show this. There may be several levels of derived Use Cases.
The re-use of Use Cases between various other Use Cases.
You should avoid:
OO-type inheritance and other OO relationships. These will cause you to make premature design decisions.
Workflow. Use Cases are independent of how the actor triggers them. Workflow is actually a design decision, to be made long after Use Case analysis.
Blocks that don't actually do anything, like your 'Home' blocks. Use Cases are functional blocks, you must be able to define what information goes in, what information goes out, and what transformations it performs.
To fix your diagram, you should focus on the core functions the users want to perform. For the patient, that would be e.g. "Book Appointment", "Edit Medicine Schedule" and "Communicate with Doctor". Then you should break these up into smaller use cases using <<include>>. For example, the "Book Appointment" use case should include showing the calendar and choosing a day.
Have fun!
I have a domain object called VehicleRecord which is a hibernate entity. CRUD operations on these VehicleRecords are handled through an entity access object implemented as a stateless session bean interface
#Local
interface VehicleRecordEao {
void add(VehicleRecord record);
List<VehicleRecord> findAll();
...
}
#Stateless
class HibernateVehicleRecordEaoBean implements VehicleRecordEao { ... }
From a business layer perspective removing and adding these records is more than just a CRUD operation. There may be logging and security requirements for example. To provide these operations to clients sessions beans are created in a business layer.
#Local
interface VehicleRecordManager {
void createVehicleRecord(VehicleRecord record);
List<VehicleRecord> findAll(String make, String model);
...
}
#Stateless
class VehicleRecordManagerBean {
public void createVehicleRecordManager(VehicleRecord record) {
//business rules such as logging, security,
// perhaps a required web service interaction
//add the new record with the Eao bean
}
...
}
Controllers work between the presentation layer and the above business layer to get work done, converting between presentation objects (like forms) and entities as necessary.
Something here is not right (smells). I have a class called Manager which has got to be a red flag, but several examples in EJB books actually suggest this kind of high level class and tend to use the name manager themselves. I am new to EJB design but in OO design making high level classes called Manager or Handler or Utility screams of procedural and requires one to rethink their design.
Are these procedural-utility-class session beans the normal pattern, or is bad to organize your session by a bunch of methods related only to the entity they operate on? Are there any naming conventions for session beans? Should the Eao's and business session beans work at the same layer?
If there is a less smelly alternative to this pattern I would love to know, thanks.
Your approach is more-or-less standard. Yes, at a fundamental level this is a procedural approach and goes hand-in-hand with what has been dubbed the Anemic Domain Model "anti-pattern". The alternative is to incorporate your business logic into your domain model so as to create a more OO design where your operations are coupled with your DO's. If you were to go down this route you should be aware of the inherent pros and cons. If you feel that your approach makes the most sense, is easy to understand, test, scale, etc... Then role with it. I have worked on several n-tier projects where this exact "procedural" style is used -- rest assured it is quite standard in EE applications to do things this way.
It's an age old discussion. Should a bread bake itself, or does an oven bake it? Does a message sends itself, or does the postoffice do it? Do I send a message to my friend Pete by asking him to send a message to himself?
According to those who came up with the term ADM, it's more "natural" and more "OO" to let each object do all those things itself. Taken to the extreme (which no one advocates of course, but just as an example) class User would contain all logic for the entire application, since ultimately the user does everything.
If you use slim entities (entities containing only data) and service or DAO objects to work with them, then you're not necessarily not doing OO. There is still a lot of OO going around. Services implement interfaces, inherit from base classes, have encapsulated state (e.g. the EntityManager in JPA), have transparent interceptors via dynamic proxies (e.g. to check security and start/commit a transaction), etc etc.
The term "Anemic" has a definite negative association, but calling the same thing "Slim" actually sounds good. This isn't just a case of using different names to hide code smells, but represents a different thinking among different groups of people.
I think it's up to your taste, and depending on the complexity of your application - these things matter less / more. I think in design, you need to simply thing around the line of:
"If someone new came in without any prior knowledge of the system in question - is it intuitive enough for that person to follow and trace the codes, and straight forward to find where things are"
In your case - naming the EJB related to the Entity Object makes it straight forward and simple - what I dont get is why did you separate it to 2 classes EAO and Manager. Why dont you just combine them into one, so if the EJB/Bean class deals with VehicleRecord Entity, then it will be the "VehicleRecordEAO" or "VehicleRecordManager" or "VehicleRecordAccess" or anything really.
I think EAO / DAO / Access sounds more like getter / setter - or any other simple operations. I dont see anything wrong with "Manager" and make it consistent across the board that all business layer will be called "Manager".
Or if you feel better, think of it as the Facade Pattern - so you can call your business layer (the Manager) as VehicleRecordFacade and VehicleRecordFacadeBean.
That way you basically follow the name and concept of Facade pattern, where it becomes intermediary between application layer and the data layer.
Something here is not right (smells).
I have a class called Manager which
has got to be a red flag
My answer here is towards this concern of yours.
Yes. It is a red flag. Naming a class like "VehicleRecordManager" would be a code smell suggesting that Single responsibility principle would be violated sooner or later.
To elaborate, let me take a few use cases to deal with VehicleRecord
Buy a vehicle
Rent a vehicle
Search for a vehicle
Sell a vehicle
Find Dealers
In most Java applications when we write up a "VehicleService" ( or "VehicleManager") all the above operations would be placed in this class ! Well, this one is easy to do, but hard to maintain. And certainly this class has a lot of responsibilities, hence many reasons to change. (violating Single responsibility principle )
Would calling it VehicleDao eliminate some of the smelliness? A simple change, but indicates clearly it's concerned with data access concerns.
The description may sound like just a bunch of words so here is a more detailed explanation. I have a User object which is mapped to database table.
I want users to be in different roles. There will be a bunch of those - and they technically will be the same users in same table but to them will apply different roles. Say user in role A will have to have two fields as required, and will have to have certain restrictions to the length and contents on his password, as well as the time expiration of his password, etc.
While I can hardcore those rules I am very interested to find out of there is an other way to define the rules and may be store in database so it's easier to load/apply and the main idea - to change and update them -- without redeploying the codebase.
Technically the stupidest and straightforward solution is to implement class, serialized, store in db, then load, deserialze, call methods on it which will execute rules. The problem is in changes to the ruleset ( read "interface" of the rule class ) and that generally solution sounds like a hack.
Anytihing else? Any frameworks? Other approaches?
UPDATE: probably was not clear. say, I have class User.java
I need to define different rules say:
1. do we need to verify length of password, and what should it be?
2. do we need to require some properties to be required?
3. do we need to track login attempts for this user?
4. if we do track, how many login attempts allowed?
5. do we expire password?
6. if we do, then in how many days? or months? or weeks?
7. ...
and so on and so on.
so questions ARE.
- how do I define those rules and operate on User object WITHOUT modifying and redeploying code base?
- how do I store those set of rules?
Drools, jBPM, etc. do not seem like a fit for that task. But any advice would help!
JRuleengine is good I heard, sometime back I planned to use it for similar application.
There are many other Rule Engines though.
Well there are some good rules engines out there include jrules, drools I think is popular too. One thing to keep in mind is the relationship between a rule and the data it examines. After all you can have the rules in a word document, but when they execute they need examine data, and that is also a factor in choosing a rule engine or architecture. generally its if (a > b) then do y. Means you need to examine a and b in the rule execution. That is the real issue is how to get the parameters into the rule and engine.
We are following Domain Driven Design for the implementation of a large website.
However by putting the behaviour on the domain objects we are ending up with some very large classes.
For example on our WebsiteUser object, we have many many methods - e.g. dealing with passwords, order history, refunds, customer segmentation. All of these methods are directly related to the user. Many of these methods delegate internally to other child object but
this still results in some very large classes.
I'm keen to avoid exposing lots of child objects
e.g. user.getOrderHistory().getLatestOrder().
What other strategies can be used to avoid this problems?
The issues you are seeing aren't caused by Domain Driven Design, but rather by a lack of separation of concerns. Domain Driven Design isn't just about placing data and behavior together.
The first thing I would recommend is taking a day or so and reading Domain Driven Design Quickly available as a free download from Info-Q. This will provide an overview of the different types of domain objects: entities, value objects, services, repositories, and factories.
The second thing I would recommend is to go read up on the Single Responsibility Principle.
The third thing I would recommend is that you begin to immerse yourself in Test Driven Development. While learning to design by writing tests first won't necessarily make you designs great, they tend to guide you toward loosely coupled designs and reveal design issues earlier.
In the example you provided, WebsiteUser definitely has way too many responsibilities. In fact, you may not have a need for WebsiteUser at all as users are generally represented by an ISecurityPrincipal.
It's a bit hard to suggest exactly how you should approach your design given the lack of business context, but I would first recommend doing some brain-storming by creating some index cards representing each of the major nouns you have in your system (e.g. Customer, Order, Receipt, Product, etc.). Write down candidate class names at the top, what responsibilities you feel are inherent to the class off to the left, and the classes it will collaborate with to the right. If some behavior doesn't feel like it belongs on any of the objects, it's probably a good service candidate (i.e. AuthenticationService). Spread the cards out on the table with your colleges and discuss. Don't make too much of this though, as this is really only intended as a brainstorming design exercise. It can be a little easier to do this at times than using a whiteboard because you can move things around.
Long term, you should really pick up the book Domain Driven Design by Eric Evans. It's a big read, but well worth your time. I'd also recommend you pick up either
Agile Software Development, Principles, Patterns, and Practices or Agile Principles, Patterns, and Practices in C# depending on your language preference.
Although real humans have lots of responsibilities, you're heading towards the God object anti-pattern.
As others have hinted, you should extract those responsibilities into separate Repositories and/or Domain Services. E.g.:
SecurityService.Authenticate(credentials, customer)
OrderRepository.GetOrderHistoryFor(Customer)
RefundsService.StartRefundProcess(order)
Be specific with naming conventions (i.e. use OrderRepository or OrderService, instead of OrderManager)
You've run into this problem because of convenience. i.e. it's convenient to treat a WebsiteUser as an aggregate root, and to access everything through it.
If you place more emphasis on clarity instead of convenience, it should help separate these concerns. Unfortunately, it does mean that team members must now be aware of the new Services.
Another way to think of it: just as Entities shouldn't perform their own persistence (which is why we use Repositories), your WebsiteUser should not handle Refunds/Segmentation/etc.
Hope that helps!
A very simple rule of thumb to follow is "most of the methods in your class HAVE to use most of the instance variables in your class" - if you follow this rule the classes will be automatically of the right size.
I ran into the same problem, and I found that using child "manager" objects was the best solution in our case.
For example, in your case, you might have:
User u = ...;
OrderHistoryManager histMan = user.getOrderHistoryManager();
Then you can use the histMan for anything you want. Obviously you thought of this, but I don't know why you want to avoid it. It seperates concerns when you have objects which seem to do too much.
Think about it this way. If you had a "Human" object, and you had to implement the chew() method. Would you put it on the Human object or the Mouth child object.
You may want to consider inversing some things. For example, a Customer doesn't need to have an Order property (or a history of orders) - you can leave those out of the Customer class. So instead of
public void doSomethingWithOrders(Customer customer, Calendar from, Calendar to) {
List = customer.getOrders(from, to);
for (Order order : orders) {
order.doSomething();
}
}
you could instead do:
public void doSomethingWithOrders(Customer customer, Calendar from, Calendar to) {
List = orderService.getOrders(customer, from, to);
for (Order order : orders) {
order.doSomething();
}
}
This is 'looser' coupling, but still you can get all the orders belonging to a customer. I'm sure there's smarter people than me that have the right names and links referring to the above.
I believe that your problem is actually related to Bounded Contexts. For what I see, "dealing with passwords, order history, refunds, customer segmentation", each one of these can be a bounded context. Therefore, you might consider splitting your WebsiteUser into multiple entities, each one corresponding to a context. There may arise some duplication, but you gain focus on your domain and get rid off very large classes with multiple responsibilities.