StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
12636843
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2012-09-28T09:01:57.903
FavoriteCount
0
LastActivityDate
2012-09-28T09:01:57.903
LastEditDate
LastEditorUserId
0
OwnerUserId
762588
ParentId
12636050
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
First I think it is bad to for <code>SellingContract</code> to provide all the condition checking methods. The class should only be concerned with holding the data and providing access to the data. As for your two approaches: <ol> <li>I don't think the Visitor Pattern is useful here. For its proper application the visitor should be able to visit different types of objects; in your case this would be differnt types of <code>SellingContract</code> or maybe <code>Contract</code>. Also to be really useful there should be a need for different types of Visitors. But besides the <code>ConditionChecker</code> what would that be. So to sum it up: I don't think the Visitor Pattern is useful here.</li> <li>This approach seems sensible. I don't think it is a problem that the utility classes know about the <code>SellingContract</code> structure; they actually only need to know its public interface. But they can't reasonably check a condition on that object without knowing anything about it, so I don't see a problem here. Also your requirements imply a step-by-step procedure anyway so its not a big problem if your approach is a litte procedural. I recommend this approach.</li> </ol> For your conditions you could write one <code>ConditionChecker</code> per condition and then write a class that does a step-by-step application of those conditions. This will also make the code easier to debug and read since you can easily do things like step through the code in your favorite IDE and see the intermediate results. In the project I am currently working on we had a similar problem: Operate on student-data and check if they meet the all conditions for a degree and providing information about which conditions are met and not met to the user. We used the second approach and it works well. Also our software architect agrees that it is a good solution. Optionally you could implement a domain-specifc language for specifying the conditions and rules. This would allow you to have the business write the conditions themselves. But this takes cosiderably more effort to implement.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POCheck the information of a set of data structures
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USViktor Seifert
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.