Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I want to know how to tackle this type of scenario.

We are building a person's background, from scratch, and I want to know, conceptually, how to proceed with a secure object pattern in both design and execution...

I've been reading on Factory patterns, Model-View-Controller types, Dependency injection, Singleton approaches... and I can't seem to grasp or 'fit' these types of designs decisions into what I'm trying to do..

First and foremost, I started with having a big jack-of-all-trades class, then I read some more, and some tips were to make sure your classes only have a single purpose.. which makes sense and I started breaking down certain things into other classes. Okay, cool. Now I'm looking at dependency injection and kind of didn't really know what's going on.

Example/insight of what kind of hierarchy I need to accomplish...

  • class Person needs to access and build from a multitude of different classes.
    • class Culture needs to access a sub-class for culture benefits
    • class Social needs to access class Culture, and other sub-classes
    • class Birth needs to access Social, Culture, and other sub-classes
    • class Childhood/Adolescence/Adulthood need to access everything.

Also, depending on different rolls, this class hierarchy needs to create multiple people as well, such as Family, and their backgrounds using some, if not all, of these same classes. Think of it as a people generator, all random, with backgrounds and things that happen to them. Aging, death of loved ones, military careers, e.t.c.

Most of the generation is done randomly, making calls to a mt_rand function to pick from most of the selections inside the classes, guaranteeing the data to be absolutely random.

I have most of the bulk-data down, and was looking for some insight from fellow programmers, what do you think?


Flowchart added. I decided to leave a few things out, but you get the idea.. I didn't really know what types of visuals to use, so I prioritized the boxes importance by size, and the most connections. The non-boxes are flavor text, with no life altering events.


share|improve this question
I think I'll need a diagram before I understand what you want. In fact, it'll probably help you too. lucidchart.com is a good free option that can export to an image file. –  Hand-E-Food Dec 6 '12 at 4:48
I will get right on this and edit the OP with an image flowchart! :) –  Admiral Kunkka Dec 6 '12 at 6:24
Wow, that's a serious diagram you have going on there! If I wanted to explain the meaning of "complexity" to someone, I'd use your diagram as an illustration :) –  dasblinkenlight Dec 6 '12 at 11:21
Can you add a diagram to explain your diagram? –  JNK Dec 6 '12 at 14:19
add comment

closed as not a real question by gnat, Walter, Glenn Nelson, Tim Post, ChrisF Dec 6 '12 at 14:26

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

This is actually a big project that will involve the use of many design patterns at the same time, together with many other concepts.

At its basis, however, it is just a big exercise in Object Oriented Analysis. Try to stick with regular OOP for the first part of your work. Lay down a well-organized hierarchy of classes.

From this point on, try to apply the design patterns that lend themselves to this task in the most evident way. For exampe, you have to build a lot of objects so most likely you can apply a factory pattern here and there. Just do not use patterns for the sake of it. Use them if you need them. There isn't anything wrong with old plain OOP.

The use of other patterns heavily depends on specific implementation strategies and details. For example, a MVC architecture makes sense only if you have some kind of view (desktop or web). If you are developing a webservice (SOAP or REST) it would make little sense.

Regarding this point, do not try to solve with design patterns what are actually problems related to your implementation strategy. For example, before getting concerned with dependency injection and singletons, you should decide how to manage your data (A simple SQL database? A full-blown ORM like Hibernate?) and how to expose them to the human world (A web interface? A desktop program? What?). These implementation decisions will automatically force you to follow specific development paths and to adopt specific patterns.

share|improve this answer
add comment

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