Clever Geek Handbook

What are some methods of understanding object interaction

When launching a new application, what are the ways to decide which objects you need, what they should do, and how they should interact with each other?

Is this a whiteboard job, or is it easier to just start coding and move things around as needed?

+2


source to share


6 answers


CRC Cards or Responsibility Engagement Cards are a good way to do this - see the Wikipedia page .



They are a good way to brainstorm (as a team or just by themselves) which classes you need, what each class will respond to, and how they will interact with each other.

+7


source


You might want to try:

CRC cards



Maps will help you identify the object, its responsibilities and cooperation.

Wherever you create CRC cards, you view the entire process. This process defines rules that help keep each class concise and really do only the operations that it needs.

+3


source


This should be more or less "natural" of the requirements.

Do you have a clear idea of ​​what the application should do, its scope, et al?

It really depends on what size of the project you are talking about: the approach and rigor to be applied are different for a commercial software team than for a personal project.

However, some general advice:

1) On your picker (I love boards) I start listing use cases or user stories. Keep going until you feel like you have the most important / covering 80%.

2) When you are satisfied that you have "WHAT" (examples of use) succinctly and more or less enough, you can start developing "HOW" (objects, algorithms, etc.). I would suggest a bias toward less complexity: you don't need a complex and layered hierarchy of objects unless you really need to (and even then, probably not).

3) I try to apply the "no coding" rule until # 1 and # 2 are met, despite prototyping discarding or researching specific approaches. It is very easy to start scrolling through the code and find that you are "trapped" by the object model that you encountered before fully understanding what you are building.

4) Once you are done collecting your requirements, you can use any number of approaches to trigger functional blocks / objects / roles, etc. CRC cards are one approach; I've also had success with class diagrams and UML diagrams.

I personally enjoy doing a lot of whiteboards in UML; I often photograph with a digital camera to archive thinking / approaches. They are much better than nothing when it comes to documenting a bad person or answering the question "why did we / didn't ..." 2 months on the way.

+2


source


I think the answer depends on several factors:

  • How big is the project? For a small project, it's pretty easy to have an idea of ​​the three or four objects that might be required and just start coding. For large projects, it is important to list them ahead of time so that you can create good names and object hierarchies.

  • how many people are in the project? If you are more than just you, you should sit down and plan who will work on what is required, and that requires a list of the classes that will be needed.

For anything more than a small (one or two days) project, it is worth spending some development time before starting coding. Whiteboards are fine for this, but be sure to take a picture when you're done!

+2


source


Sequence and class diagrams. It's a long way to go when you're in design. The last thing you want to do, if you're not limited in terms of time and resources, is just start coding.

+1


source


It is probably best to start on a whiteboard or some design review. It all depends on what you really need to do. Find out what action your application requires. Map the objects appropriately to the methods that you raise after you have broken your application into the appropriate parts.

+1


source






More articles:


All Articles