2

I am building a small application and I am trying to understand the best way to approach the design. I am looking for some guidance/advice how best to approach the following issue.

What I have is that I receive a set of data, real time. I then analyze the data for patterns. The patterns are classes that derive from an abstract class which implements an interface. The number of patterns will change over time as patterns are added/removed. In addition, depending on the access level of the user, the data is analyzed with different pattern options.

For example, if I have five patterns, A, B, C, D and E, level 100 access may only analyze the data with pattern A whereas access level 300 will analyze with patterns B, D and E, and access level 500 will analyze with all the patterns. The access levels are linked to the user, and a user can have different access levels on different data streams.

My thought is to create a hash table or dictionary for the patterns and a db for the users and their various access levels. Is this the best way to go or is there a better approach that will work in real time?

closed as unclear what you're asking by Robert Harvey, user40980, World Engineer Jun 24 '14 at 4:12

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • How hard a real time constraint are we talking here? Are you flying a plane, or are you checking for twitter trends? Also, inheritence for patterns seems distasteful. – Telastyn Jan 24 '14 at 19:54
  • The real time constraint is a hard constraint. The data comes in at various rates but fairly quickly and constantly. I do not understand why inheritance in patterns would be distasteful especially as a number of patterns can be, to a high degree, derived from a single abstract class. – Zeos Jan 24 '14 at 20:03
  • First and foremost you need to focus on the data model for your users/roles/permissions, there are many approaches to this and this authentication/authorization portion of any application tends to be a non-trivial portion. I would suggest you ask another question here about how you plan on designing the data model and what you expect to get out of it for just authentication/authorization (also what the difference between those two are if you're not familiar with it) and asking for suggestions/critiques of your planned approach or if it looks functional. – Jimmy Hoffa Jan 24 '14 at 20:42
  • @JimmyHoffa Thank you for your suggestion. Can you give me an idea how to phrase the data model authentication/authorization issue. I would simply restate the problem and then ask for suggestions/advice on the best approach to the data model for this. Would that work? Thank you. – Zeos Jan 24 '14 at 21:13
  • 4
    @Zeos: I don't think you will get a really helpful answer unless you edit your question and add an example for the data and an example for a "pattern". Your current description leaves it completely to the imagination of the reader what you mean by "pattern" - that's a term which can mean almost anything. – Doc Brown Jan 24 '14 at 22:03
1

You're on the right track, what you've described is a classic Strategy pattern.


There seems to be some confusion around the answer and I'll elaborate. The question is a little ambiguous as to what is being asked and such broad questions are usually flagged, but I wanted to answer the general gist.

The composition of behaviors over a single interface allows for multiple implementations to be instantiated and swapped out at run-time, which is the basic definition of a strategy pattern. The behaviors can be instantiated upon startup or construction and then stored in a simple dictionary for selection by key on an as-needed basis, or perhaps constructed on the fly as needed via dependency injection.

Several commentators seem to be taking issue with the notion of 'real time' as it is traditionally used as speed of results, and my perspective relevant to the question is simply that data is processed per call.

Lastly, a persistent data store of users and roles is exactly what is needed to create an authorization scheme for demarcating which behaviors can be used by which users.

Hopefully this clears up the answer.

  • 2
    Uh, I really don't see a strategy pattern hidden in creating a dictionary to store in-memory data version of a database's data... also he's not on the right track, his decided approach is pretty poor and shows a (very common) lack of understanding DB design.. I don't say that to be dismissive or insulting, just that he's right to be asking here as folks on this site likely have better ideas for approaching the problem than what he's suggesting. – Jimmy Hoffa Jan 24 '14 at 20:33
  • I've edited to try and address the mismatch in our thinking. The question itself doesn't sufficiently describe the problem space to suggest an architecture and at best pointing him at the pattern he's somewhat intuitively described was the best possible solution. – Kevin Jan 24 '14 at 21:02
  • 1
    Thanks for editing to give some explanation! Though I'm leaving the -1 sorry, the strategy pattern is a stand-in for higher-order-functions, you seem to be confusing strategy pattern with the basic purpose of an interface. – Jimmy Hoffa Jan 24 '14 at 21:03
  • That's fine, it's not a beautiful answer nor is it a beautiful question. I think you're misunderstanding my application of strategy pattern to his solution - it is the runtime selection of an implementation to use, please consult the link I referenced. The fact that an interface matters at all is a static-typed methodology to let the caller of the implementation(s) know that the implementation call is consistent. – Kevin Jan 24 '14 at 21:06
0

I coded a similar type of application where I have various access levels and patterns to analize a input data, in that case what my team do was make all the patterns as childs of a abstract class and store that classes name in the database, users and their access level were stored as well. When a user logs to the system all the patters for his level were loaded via reflection. In our case the data was the Twitter Stream and we analize all the tweets to match with predefine patters such "HasALink" or "MentionPeopleInList", the solution perform well for us.

  • Thank you. That makes sense but using Reflection in real time makes me wonder about efficiency and speed. This is a good suggestion though. Thank you very much. – Zeos Jan 24 '14 at 19:39
  • 3
    @Zeos: you are making biased assumptions about code which is not even written so far beeing too slow, but in your comments above you could not tell what your performance requirements are, only some meaningless words about "hard constraints". Sorry, but this won't bring you any further to a solution. – Doc Brown Jan 24 '14 at 23:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.