Don Kiddick

Ranch Hand
+ Follow
since Dec 12, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Don Kiddick

Hello,

I have about 4 directories I use all the time in windows and I need to open files in them, copy files between them etc. I normally have a few explorer windows open but it isn't very organised.

What I would like is to have an application that will allow me to open a certain number of explorer windows (I don't need the explorer bar, just the contents). Ideally this would take up one space in my task bar.

Any ideas?

regards,
Don
8 years ago
In my case, the domain involves ui concepts. I think...
Hello!

I am building an application. The application is a container for other applications. We are able to host components built from other teams, provide different layout configurations and provide transitions to that layout when events are raised by the components.

We have a pojo-based model. That main entities in the model are things like
* Component : the components other teams write
* Frame : a layout element that components can be placed on
* Transition : something that happens when an event is raised by a component - often results in frames being hidden/shown/moved etc.

I'm confused whether this is a domain model (where our domain is the ui) or a presentation model (in which case we don't really have a domain model).

Why does this matter?

Well the model ultimately gets realised with some ui widgets - in this case swing and jide. So far we have avoided having any jide or swing specific code in our model. The ui layer though is proving hard to unit test, and so I want it to be as dumb as possible. So I want to move the logic currently inside the ui into a model of some sort. The two main choices I see are :
1. Moving the logic inside our existing model. This means moving (polluting?) our model with Swing/Jide specific references.
2. Creating a presentation model, which sits between our existing model and the ui.

1. seems somewhat 'wrong' if I consider our existing model to be a domain model - having jide and swing specific reference doesn't seem good. It is however simpler.
2. seems cleaner...but also more complicated...am I maybe overcomplicating things?

regards,
D.
Exactly. So just live with conditional is probably the best bet. Ta.
Hi,

I find there is a tension between the principles of "tell don't ask" and model view seperation. For example, I always end up with code like this :



Not ideal, switching on the objects type.
However to maintain model/view seperation, I cannot ask the object for it's image.
I could also create a map of class to image, but that is just another way of writing the switch statement, and it doesn't handle subclasses so well
I've tried using a double dispatch pattern, and while this does get rid of the switch, it makes the code much more confusing.

So in the end, I just live with the switch statement. Are there any other patterns/approaches I could use here?

thanks, Don.
yeah was wondering about that, seeing as we don't have to prepend test to our test methods anymore.
One thing I've noticed using the assert keyword is that it's really hard to test using junit that they are thrown.

e.g.



I don't know if this is a junit 4.0 thing, but fail() now throws a AssertionError, thus making this test always pass!
Ilja, thanks for your time.
Don.
thanks for the reply.

With that example you can still call "new Trade()" independently of a portfolio though, leaving the parent null.

I'm beginning to think option 2 (trade constructor takes a portfolio) is my preffered one.

What is the advantage of using an assert over IllegalArguementException? I think I always want my assertions on.

thanks, Don.
I have a parent (Portfolio)/child (Trade) relationship, where each portfolio has 0 or more trades, and each trade has exactly on portfolio.

I currently have this coded as follows :



However this doesn't capture the requirement that Trades always have exactly one Portfolio, ie, parent cannot be null. I would ideally like the code to reflect this knowledge.

The other way I thought to do it is :



I worry that this makes my code less testable as it is more hassle to create trades now.
Also during the trade constructor, portfolio.addTrade() gets called, which isn't ideal (calling parameters methods within a constructor.

After writing this down, I'm beginning to think that the 2nd style is the best.
Does anyone have any views on this and/or patterns that they use to handle this situation?

thanks, Don.

or you pass the "singleton" object all along the collaboration chain because one class at the end needs it. Worse, all your collaboration classes will depend on the "singleton" even without using it.



I'm not sure that is true. e.g is class A collaborates with classes B and C and class C uses a single instance of class D.

If C is passed an instance of D via A. Classes A & C are clearly depenedent on A.
If C accesses D via a global access point such as a singleton. Class C is clearly dependent on D and A is clearly dependent on C. Therefore A is also dependent on D.

The difference is that by passing the instance along the collaborators the dependency is explicit instead of implicit. In general I think this is preferable.

thanks, D.
Hello,

I'm writing a rich client using eclipse rcp. I'm finding that I have various views that share state, in particular selection. An example of this for eclipse users is the outline and editor views, both observing a java class. Selecting methods in the outline view, causes the selection in the editor view to jump to that method and navigating in the editor view also causes the selection in the outline view to change.

In my example I have one view that displays a list of Markets. I also have another view that has a combo box. Changing the selection in the combo, updates the selection in the list and vice versa.

To implement this I added a bound selectedMarket property to the MarketService. All works great, although it doesn't sit perfectly with me - it doesn't seem like a typical resposibilty of a service layer object.

Do you think this sort of app state belongs in the service layer?
It's quite handy in a way, in that the app state and the service are related. Deleting the selected market, obviously makes it no longer selected. Trivial when in the same service but if I seperated out the state into a seperate object I would have to add some extra binding to take care of this.

hmmm...well I think maybe I've answered my question, keeping this state in the service layer is easier which is a good thing. What do you think?

thanks,
D.
There is a trade object, it is currently saved to a file system. The details (filename, location) are filled in a dialog (swt). I'm introducing tests for this logic and I'm introducing a service layer. There will be a TradeService interface which will have methods to persist the trade.





When I'm running my unit tests, I will be subbing in a TransientTradeService which keeps a handle of trades in a HashMap. In production, we will use FileTradeService which actually saves stuff to disc.

Thing is, the FileTradeService needs the extra details mentioned. How to handle this? My solution was to invert control to the TradeService - essentially by passing in the current widget which will allow TradeService implementations which need more details from the user to be able to ask for them from the user.


and



On one hand seems neat, but also seems odd by service layer having a dependency on the ui. Is this something to be worried about? If so, any other solutions?

thanks, Don
There is a trade object, it is currently saved to a file system. The details (filename, location) are filled in a dialog (swt). I'm introducing tests for this logic and I'm introducing a service layer. There will be a TradeService interface which will have methods to persist the trade.





When I'm running my unit tests, I will be subbing in a TransientTradeService which keeps a handle of trades in a HashMap. In production, we will use FileTradeService which actually saves stuff to disc.

Thing is, the FileTradeService needs the extra details mentioned. How to handle this? My solution was to invert control to the TradeService - essentially by passing in the current widget which will allow TradeService implementations which need more details from the user to be able to ask for them from the user.


and



On one hand seems neat, but also seems odd by service layer having a dependency on the ui. Is this something to be worried about? If so, any other solutions?

thanks, Don