Allan Halme

Ranch Hand
+ Follow
since Aug 22, 2003
Merit badge: grant badges
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Allan Halme

Originally posted by Maki Jav:But what is "clearly" an association then?


When one class makes a reference to another, there's an association between the two. If only one refers to the other but not vice versa, the association has a direction.
[ September 27, 2007: Message edited by: Allan Halme ]

Originally posted by Barry Brashear:
What design pattern would you use to transfer the data coming from one
application into another?



It would be useful if you were a bit more specific about your problem. What is the relationship between the applications and the nature of their interaction? What kind of data do you have? etc

Originally posted by Paul Croarkin:
Empower yourself and just do it.



I've learned that this is best. Refactoring's the same thing.

Managers expect developers to produce quality code and aren't worried about how its done. They don't care whether we use while loops or do-while loops; they're not interested in whether we're using the old or the new for loop syntax; etc. Similarly, they're not interested in whether we're doing TDD or refactoring or using Eclipse's refactoring features or the RefactorIT plugin or whatever.

If developers produce good code reasonably within the effort estimate ranges developers originally provided or within the current timebox, then the managers will (ought to be) happy.
[ September 27, 2007: Message edited by: Allan Halme ]
17 years ago
Hi Lasse,

What do you feel is the role of TDD in determining the design and architecture of an application?

You mention in a footnote that test-driven development, test-driven design, and test-first programming are all the same thing. I see clearly that test-driven development and test-driven programming are the same thing, but I feel that test-driven design is a broader issue.

At a certain level, TDD most definitely "drives" the design of the code, because of the refactoring that the tests enable you to do.

However, at a higher level of abstraction, there are architectural design decisions, patterns, and structures that--though they may and should evolve over time and during the project--are probably not best determined via the process of test-first programming.

Your thoughts?
17 years ago
Lasse,

How much or what parts of the value of using TDD is dependent on the development process being agile or iterative, as opposed to a more waterfall-based approach, which may indeed have a "unit testing phase" (that a previous poster mentioned)?

(Assuming that the process isn't so strict that it actually enforces coding production code first and then producing unit tests after the fact, but allows development and unit testing to proceed simultaneously.)
17 years ago

I'm not sure what you mean by "unit testing phase"



Lasse's being modest here

I think an interesting question is this -- how much of the value of using TDD is dependent on the development process being agile or iterative, as opposed to a more waterfall-based approach, which may indeed have a "unit testing phase"? (Assuming that the process isn't so strict that it actualy enforces coding production code first and then producing unit tests after the fact, but allows development and unit testing to proceed simultaneously.)

Lasse, your thoughts?

(I'll repeat this question as a separate topic in this forum.)
[ September 27, 2007: Message edited by: Allan Halme ]
17 years ago



This is clearly better than what I've been using. I have hereby upgraded to this directory layout
[ September 27, 2007: Message edited by: Allan Halme ]
17 years ago

Did it's better to start with learning JUnit or TDD first (as big picture then JUnit is to apply TDD)?[/QB]



This would depend on what it is you are trying to do.

If your goal is to learn to develop code with TDD, then you'll probably do well to progress evenly with both: studying a bit of TDD from the book and then trying it out bit by bit with JUnit, and they'll form a positive feedback loop.

If your goal is to just learn how to use JUnit for the occational unit test or for writing unit tests after your production code is "ready", then you don't need TDD ...
17 years ago

Originally posted by Dirk Schnelle:

When the project starts, developers also start developing tests. But as the project continues the developers have less time to maintain their tests and turn to pure hacking.



I've seen this happen a couple of times and in these cases the fundamental reason for developers ceasing and desisting from writing and maintaining unit tests is that they, the developers, didn't see value in writing and maintaining them. I, on my part, wrote and maintained them as far as I could and for the code I was writing, but it was a real uphill struggle as I was really the only one doing it. And it was my "fault" that in that situation, I didn't manage to convince or show the other developers of the value of the tests. It also didn't help that when we inherited the code base all the existing unit tests mainly tested for the success of setters and getters, which set a really horrible example for the other developers, none of whom had done unit testing or TDD before.

So it really ultimately boils down to the skills and goals of the development team and the techniques they put to use.
17 years ago
I always put test code into the same package as the code being tested. It makes it very straightforward to find the test classes (e.g. with Eclipse's Open Type) and I don't see any reason for them not to be in the same package.

However because you don't want to deploy test code and you don't want to package it into your production packages and because you don't want to have funky exclusion clauses in your build scripts, I always put the test code in a different source folder.

I wouldn't put the test code in a different project though (i.e. a different Eclipse project), because your test code is a first-class citizen of your codebase and is fundamentally a part of your project.

This is my standard project source code layout. I've got "java" in the path because I want to keep separarate non-Java files that nevertheless go into the jar package and into the classpath, such as some static property files etc.

17 years ago

maybe I am outside the realms of design patterns here



Any established solution (the rule of thumb is "used at least three times" somewhere) to a recurring problem can be expressed as a pattern, so you're within the realms of design patterns here.

Whether or not there is actually a pattern for your problem is, of course, a different matter

I know I've run across the need to be able to version and diff models (class diagrams), but I haven't yet found or heard of any really good solutions.

Originally posted by Vladas Razas:
For my project I chose to have simple beans and I keep relationship information in other classes. I still have my lightweight beans. Did I chose correctly?



Ultimately, you will know whether you chose correctly by how easy or hard you or your colleagues or successors will find understanding, modifying, extending, and correcting your code.

One way of looking at your problem is this: does your Group-Element structure represent a true Composite? I.e., looking from the domain's perspective ("business logic" perspective), does a single set of Groups and Elements that are in relationship to one another form a logical, coherent whole that should be treated as a single whole?

Or are, indeed, the Groups and Elements independent of each other, with their relationships being separate and providing additional information with regard to the Groups and Elements, but without actually conceptually belonging to the Groups and Elements themselves?

For example, an automobile could be represented as a set of car parts grouped and subgrouped in various ways -- in this case, the grouping relationships are integral to the whole, and the concept of "car" is a single entity that can and should be handled as a Composite.

Or, for example, Companies and Persons could be engaged in a mutual relationsihp, Employment, but where Company and Person are entirely valid, independent entities, with the Employment relationship brining valuable extra information regarding a pair of them, but not being fundamental attributes thereof.
[ September 29, 2004: Message edited by: Allan Halme ]

Originally posted by Maxim Katcharov:
What do you call any sort of class that is used by the owner, but no client of the owner is aware of that class?



An implementation detail that should be of no concern to anyone else except the owning class itself and the developers responsible for it?

But what if you're trying to define an inheritance tree? It is my understanding that abstract classes are used to define inheritance trees


Why would you want to define an abstract inheritance tree? Inheritance or deep class hierarchies are not, in themselves, desirable design features of an object-oriented application; there is inevitably tighter coupling between super- and subclasses than between a class and an associated collaborating class.

I usually hear that abstract classes are to be used when some common functionality can be factored out of a set of classes.


Right -- but for this to happen, you have to have the classes and their shared, common functionality first -- then, and only then, can you refactor common stuff into either (i) a superclass, or (ii) an independent collaborating class.

What if there is no common functionality, but you want to create a superclass for polymorphism? Would a good designer ever do this?


Nope, because if there is no common functionality (let's start using the word "behavoiur" here) then there is no need for polymorphism. You don't want to be doing polymorphism just for buzzword compatibility.

If, however, you do indeed have a set of classes that you wish to be able to treat polymorphically, then you do actually have similar behaviour across them; but here, then, you could more cleanly go with an interface.
[ September 29, 2004: Message edited by: Allan Halme ]

"Software Architecture Design Patterns in Java"



I haven't heard of this book before, but I would dare to hazard, purely from its name, that it may not end up being a classic. It's name has got two distinct concepts confused -- architecture patterns and design patterns. There may be some kind of conscious intention in conflating the terms, but I'll not be convinced that that's a good idea by any argument.

Volume 1 POSA has a good description of what the two are, what their differences are, and why they merit the separate designations. There are architecture patterns, then there are design patterns, and then there are language-specific idioms.