1

Whilst there are many good examples on this forum that contain examples of coupling and cohesion, I am struggling to apply it to my code fully. I can identify parts in my code that may need changing. Would any Java experts be able to take a look at my code and explain to me what aspects are good and bad. I don't mind changing it myself at all. It's just that many people seem to disagree with each other and I'm finding it hard to actually understand what principles to follow...

user559142
  • 12,279
  • 49
  • 116
  • 179
  • 2
    post the code and be specific on where you need help – Aravind Yarram Jan 05 '11 at 14:28
  • Privately e-mail rather defeats the purpose of this forum. Published answers benefit other people, not just the asker of the question. – Raedwald Jan 05 '11 at 15:19
  • Sure, I understand. How can I post code without answering my question? I don't want to deter people from looking at this post – user559142 Jan 05 '11 at 15:35
  • 1
    You can edit this post to add the code. – Raedwald Jan 05 '11 at 15:41
  • the class familymember contains name, gender, dateofbirth(string), mother, father, children. it contains methods for getting and setting the mother and also linking the relationships. Im sure it is ok as it does only one thing (defining a person/familymember). The above however, I;m not sure how to determine their coupling and cohesiveness...Especially in the family tree class. – user559142 Jan 05 '11 at 15:55

4 Answers4

3

First, I'd like to say that the primary reason you get such varying answers is that this really does become an art over time. Many of the opinions you get don't boil down to a hard fast rule or fact, more it comes down to general experience. After 10-20 years doing this, you start to remember what things you did that caused pain, and how you avoided doing them again. Many answers work for some problems, but it's the individual's experience that determines their opinion.

There is really only 1 really big thing I would change in your code. I would consider looking into what's called the Command Pattern. Information on this shouldn't be difficult to find either on the web or in the GoF book.

The primary idea is that each of your commands "add child", "add parent" become a separate class. The logic for a single command is enclosed in a single small class that is easy to test and modify. That class should then be "executed" to do the work from your main class. In this way, your main class only has to deal with command line parsing, and can lose most of it's knowledge of a FamilyTree. It just has to know what command line maps into which Command classes and kick them off.

That's my 2 cents.

rfeak
  • 8,124
  • 29
  • 28
  • @user559142 - Apologies. It's commonly called the Gang of Four book due to the authors, but it's real title is "Design Patterns: Elements of Reusable Object-Oriented Software." It's one of those books that most software engineers have in their library. One of the ones you keep. – rfeak Jan 05 '11 at 16:48
  • Ah ok thanks a lot. I'll have to look into that. Do you think the rest of the code looks ok? – user559142 Jan 05 '11 at 17:10
1

In short:

Cohesion in software engineering, as in real life, is how much the elements consisting a whole(in our case let's say a class) can be said that they actually belong together. Thus, it is a measure of how strongly related each piece of functionality expressed by the source code of a software module is.

One way of looking at cohesion in terms of OO is if the methods in the class are using any of the private attributes.

Now the discussion is bigger than this but High Cohesion (or the cohesion's best type - the functional cohesion) is when parts of a module are grouped because they all contribute to a single well-defined task of the module.

Coupling in simple words, is how much one component (again, imagine a class, although not necessarily) knows about the inner workings or inner elements of another one, i.e. how much knowledge it has of the other component.

Loose coupling is a method of interconnecting the components in a system or network so that those components, depend on each other to the least extent practically possible…

In long:

I wrote a blog post about this. It discusses all this in much detail, with examples etc. It also explains the benefits of why you should follow these principles. I think it could help...

TheBoyan
  • 6,802
  • 3
  • 45
  • 61
1

I can recommend Alan's and James's book Design Patterns explained -- A new perspective on object-oriented design (ISBN-13: 978-0321247148):

Cover: Design Patterns explained -- A new perspective on object-oriented design

It's a great book about has-a and is-a decissions, including cohesion and coupling in object-oriented design.

Raphael Bossek
  • 1,904
  • 14
  • 25
  • Thanks a lot, I will get that for future development. I am developing an app for preparation of my exams next week - so don;t really have time now! But thanks for the recommendation. – user559142 Jan 05 '11 at 14:43
0

Coupling defines the degree to which each component depends on other components in the system. Given two components A and B ,how much code in B must change if A changes. Cohesion defines the measure of how coherent or strongly related the various functions of a single software component are.It refers to what the class does. Low cohesion would mean that the class does a great variety of actions and is not focused on what it should do. High cohesion would then mean that the class is focused on what it should be doing, i.e. only methods relating to the intention of the class. Note: Good APIs exhibit loose coupling and high cohesion. One particularly abhorrent form of tight coupling that should always be avoided is having two components that depend on each other directly or indirectly, that is, a dependency cycle or circular dependency. Detailed info in below link http://softwarematerial.blogspot.sg/2015/12/coupling-and-cohesion.html

rvkreddy
  • 183
  • 1
  • 9