Win a copy of Terraform in Action this week in the Cloud forum!

marten koomen

Ranch Hand
+ Follow
since Feb 03, 2007
marten likes ...
jQuery Postgres Database Java
Melbourne, Victoria, Australia
Cows and Likes
Cows
Total received
1
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
42
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by marten koomen

Thanks Stephan

You need to remove the type parameter R from Resource, because you're not using it anywhere (except in the self-referential type bound on R itself). You must leave it on your Manager class, because you actually use it there.


yes, carry over from my first prototype, don't know why I did it then.

Don't use integers for IDs.


I've changed the key to a String, Although I can't for the moment figure out how to abstract a Key into a class, will work on it.

Don't expose fields. Sub-classes may access private fields though protected accessors.


Will tidy up

What Java version are you on?


from eclipse -> C:/Program Files/Java/jdk1.8.0_102/jre/bin\server\jvm.dll

Don't do database stuff from constructors. Constructors must be lightweight. Let factory methods retrieve properties from a database and make the constructor accept the properties you want to set.


In principle I agree here, but for my first prototype I got into all sorts of problems abstracting out the database from the objects. In this design the only way a Resource object is instantiated is when it's read from the database, so it somehow makes sense to pass the Result Set into the constructor. But I'll contemplate this. This project is for a very relational domain, so the objects doing the work all represent complete rows in a database table. Also in my first prototype I got into all sorts of problems creating unmodifiable Resources and other objects containing Resource state. I got into a big mess. I'm trying to avoid that here by encapsulating everything in a manager.


Instead of returning defensive copies from methods, return unmodifiable views


will do, but for the moment I know my clients will want to sort a list and present it.

What is a TTException?


Probably not the best solution, but this is a custom made exception that I use to swallow exceptions thrown by database interactions etc along with a severity indicator. TTException is then thrown so that it can propagate to the dispatcher/controller Servlet can then decide what to do and how - e.g. terminate the session or inform the client that a transaction has not been completed.  I understand this is not ideal, but I don't know how else to treat database exceptions elegantly for the browser based client.

Return an Optional from methods instead of null


I've been working to Joshua Bloch's Item 54, to not return nulls but empty collections, I'll need to double check that.

Use upper type bounds when accepting a collection from which to retrieve elements.


Will do, I think I know what this means, it sounds similar Joshua Bloch Item 31, of using bounded wildcards, so I'm understanding accept a Collection when that will do, rather an List.

I don't understand why Resource needs a reference to the Manager, as it is the Manager that initiates and coordinates mutations to the Resource along with informing any other involved resources. I'll need to get my head around this.


1 year ago

Thing's generic type parameter T is unused. Remove it.
You have public and protected members in a package private class.
Your constructors are redundant.
ConcreteThingManager's name can be shortened to Manager, because ConcreteThing already provides a separate namespace for it.
ConcreteThingManager's class header doesn't do what you think it does. Instead of using the class ConcreteThing, you introduced a new type variable named ConcreteThing.


When I look at these concerns in my actual code where my Thing (hereafter called Resource) class is over 1000 lines long, I can't find a way of getting around the type headers. Below are some snippets from the actual code, now called Resource to avoid transcription errors.

I trust this gives a flavour. I'm keen to get this right because my first subclass is also ~800 lines. The Resource class crosses the nexus of MC of my MVC, where client classes are responsible for generating the view.
The code now looks great (from my perspective) without any warnings, and where type wildcards<?> make sense.

So I've shorten the name to Manager, but when I play around with the Type headers Eclipse becomes a sea of red.

Just using the word singleton should send shivers up your spine


okay, I understand this (I think), thanks
1 year ago
ok, so inverting the nesting works, thanks Stephan.  Thing is now the outer class, Manager the inner class which is static.  Type parameters look normal, all warnings removed without suppression.

I'll now contemplate what I did, and build my suite of Thing sub-classes.

many thanks to all.

1 year ago
Sorry Paul you are right, it's a typo, doh.  It get confusing doing multiple changes. Apologies again.  I will not edit the above this time
1 year ago
So Stephan's suggestion of inverting the nesting relationship solved the problem of parameter references neatly. This design requires the ThingManager to be static, as only one instance of manager needs to be created, not one manager for every Thing.

However, the following code raises two issues.
1) I cannot create a new ConcreteThing from within the nested manager class, with Eclipse giving an error on line 13 of the ContreteThing to that effect.
2) Access to the Thing object by the ThingManager is not private, with the sayHello() only visible to the manager when its modifier is public or protected, but not private (this can be worked around)



The JavaDocs on nested classes here states that.

Note: A static nested class interacts with the instance members of its outer class (and other classes) just like any other top-level class. In effect, a static nested class is behaviorally a top-level class that has been nested in another top-level class for packaging convenience.



So I'm back to the issue of a static nested class or non-static inner class. My initial choice to go with a non-static inner class was the conceptually strong one(Manager)-to-many(Thing) relationship in the design, a Thing is conceptually not a top-level-class (to me). At this point I cannot understand other's preference for a static inner class given the strength of the relationship, that's not to say there are not good reasons, it's just that I don't understand them as yet.

So this is is then about trade-offs, with encapsulation being my primary consideration.

Campbell wrote

We always worry when we hear about singletons. Not sure I understand the last part of your reply:


I'm using singleton conceptually here to represent a tenant, I have a Collection of tenants maintained in a Singleton as per Item 3 of Joshua Bloch through an enum.
My design has multiple tenants where each Tenant has many Collections of different types of Thing and multiple users that can read or mutate Thing objects that are shared. Tenants can also exchange collections of Thing objects. So external to the ThingManager activity is not very controlled, and I need to encapsulate Thing mutations in a manager so that I can ensure integrity of the database and the view of clients as much as possible.

As to my last line

I generally don't know if I'm just not programming very well, or if my domain is somewhat unique, I suspect a bit of both.


I have said this in other places, but my domain is education where I have seen (in a role in bureaucracy) big projects founder or deemed ill-suited by teachers. My project is exploring this, so when I run into problems I don't know if it's my lack of programming or issues unique to the domain.

1 year ago
I think that is the problem (to which Stephan is pointing out) that is inherent in the design. I've now minimised generics, made the inner classes static (why not), and will pass Collections onto clients Typed to the abstract (Thing) class, where it makes more sense for clients to cast them into their concrete types.

I'm happy with the encapsulation that the inner class for Thing provides, and while the typing is not perfect, it's pretty straightforward with minimal use of parameterised types.
Thanks
1 year ago
Unfortunately I can't get this to work

on line 3, Eclipse says Syntax error on token "extends", , expected
1 year ago
sorry about the edit, i wanted to avoid giving people a bum steer, now I've given them two, doh.

Yours (Campbell) seems like another worthwhile solution that I'm exploring now, the sub class is tricky with the original solution.

You would probably need to parameterise any methods using that Collection.


yes, clients get defensive copies of the Collection, and I'm trying to give them assurance of getting the Type they are expecting. But I haven't implementing that yet.

Why are you making an inner class public


The inner class is public because these are the objects (Things) used by clients, the clients render the Collection in an interface, and the client selects which object(Thing) to mutate and does so through the manager (ThingManager).

Why didn't you make that nested class static?


The ThingManager is a Singleton (or at least is a member of Singleton), and each Thing is attached to its ThingManager.  I've tried to get my head around Joshua Bloch's Item 24 on this. I've revisted now on your questioning and have changed the nested class to static. This works. So the inner class is now static and the class declaration looks like this - although I'm still playing around with the subclass

Why have you got private setters? Wouldn't methods that add something to your Collection have to be public?


Each Thing is available to multiple clients (through a web interface) where each client can make changes to Thing objects asynchronously, I have designed for changes to be made through a manager to ensure changes from multiple clients are made in an orderly fashion.  The ThingManager is responsible for ensuring integrity of the database to which all changes are instantaneously written.

I also have rogue collections floating about (containing Thing objects marked as deleted but presented to clients after a search for possible un-deletion). So a ThingManager helps to keep track of this in single a Class.

I generally don't know if I'm just not programming very well, or if my domain is somewhat unique, I suspect a bit of both.




1 year ago
actually it's not without its problems, while it is  neat in the abstract ThingManager it get's a bit more complex in the ConcreteManager. Nevertheless it's not an academic exercise, and for what I'm trying to do, which is to manage lots of different types of Things in a consistent way, it seems an appropriate solution.
1 year ago
Just for completion, I'm showing here the abstract parent class and the concrete child class with its generic types resolved (which took a bit of time). Both these work for me. A tad excited by this.


Abstract Class


Concrete subclass
1 year ago
Hi Carey

I am using a nested class, and note that it is not static so that each Thing always belongs to its ThingManager. Thing is shared by multiple clients who are able to mutate Thing, but they need to do this through synchronized methods in the ThingManager which is responsible for maintaining the integrity of the Thing collection. So only the ThingManager can mutate Thing when methods are called by clients, but all clients can see the instances of Thing and access its getters whenever they want.

This was my reasoning.
1 year ago
Thanks Paul, that is so cool, I would never have thought of that. I implemented it in my class and it now looks so much cleaner and easier to read.
Cheers
1 year ago
Hi

I have a pattern (not an evil design pattern, just something that recurs in my design) in my program where an abstract class ThingManager is responsible for managing a collection of Thing which is also an abstract class nested in the ThingManager so that it controls all the mutation on Thing.

So in Eclipse this comes up as okay


but what I really want is for the Type parameter to be an extension of Thing, as below, but Eclipse tells me that Thing cannot be resolved to a type


I can work around this as the code is safe, but the work around suppresses warnings, uses wildcards, and use the abstract class as type parameters, This is not neat. It would be cool to just have the one parameter <T extends Thing>.

Any suggestions?

Thanks
1 year ago
Thanks Christopher, another reason why I love this forum
.

Frameworks such as React were essentially built to do what I think you want to do. Re-usable components.


You are correct, and a great part of my application is a "complex administration tool" similar to what you mention. Further, I think React may do this well if I was able to get my head around it. However, one of the features in my application is that the HTML and JavaScript are built on the fly where the id for DOM elements and the CSS class selectors are randomly generated. This allows me to attach events using the class selectors to DOM elements, where the event sends to the server the class selector along with the id of a parent element so that the server knows what to do (class selector) and with what resource (element id). The Controller Servlet then uses this data to assign responsibility for the response to a response handler. In principle my pattern seems to work a bit like Spring MVC, but in baby steps. Also, this is not the total scope of interaction, but a large part of it.

This is the main reason why I'm adverse to dependencies such NPM and Node, my application is basically a big StringBuilder or automated text editor. This makes the incorporation of other interfaces like NPM problematic, conceptually at least. However, this problem may be easy to resolve in practice and I'm not familiar enough.

Hopefully you account for the XSS implications here


I'm trying my best, as a starting point I'm thinking of SSL, randomised ids and class selectors etc, and a single Controller Servlet through which additional security features can be added to in the future. But in the end, my application will not involve marketable or sensitive user data. But I'm keeping this mind, with perhaps more robust solutions should  this get to a commercial stage. (I'm also using prepared statements for access to the database)

This is what dependency management (like Maven) is for :-)


Total agreement on that, having worked in Netbeans last time, which I think had/has ANT in the background, I was totally adverse to Maven, but this week I bit the bullet and solved my dependency problem by working with Maven.  So my setup now is Eclipse, Maven, Tomcat, Git, Postgres.  This was a steep learning curve this week, and I now feel like I'm out in the wild, having previously been able to refer back to the Head First and Murach books through which I learnt programming.

My environment works but still seems brittle with how it manages Tomcat and debugging. I'm hoping I will be able to iron that out. But having gone to Maven I now have a better sense of what applications are built on, how cooperation is important, and that keeping an ordered development environment is important.



1 year ago

I think an important question is: What is the application used for? If it's intended to teach students, I would argue that including NPM and excluding jQuery are especially important


While I'm foggy on the technology, I'm quite clear what I'm trying to achieve educationally. It's not to teach a particular technology, that would be training, education is more about teaching broad patterns and while I've not taught computer studies/science for some years, my preference would be to teach programming through something like Logo which teaches broad underlying patterns, something Seymour Papert was renowned for.

In terms of patterns, HTML, CSS and JavaScript seem to be an enduring pattern on the internet, with JavaScript being the last one to calm down, perhaps ES6 might do that. I need to make a judgement for myself if React will be enduring, or if it will pass by the way of Angular JS, Adobe Flash, Dreamweaver etc (although I'm not fully up with the technologies). React certainly seems more robust, who knows. And jQuery does seem a transitory compensatory technology for a lack of standardisation across browsers, as well as providing short cuts.

MVC is another important pattern, and I'm working under the hypothesis that the web is not good at the kind of point-to-point communication required for education. So I'm trying to maintain the integrity of meaning - be it by gesture, image, video or text - for communication between teacher and student. Automation and algorithms can distort this communication, and this is a major source of critique in certain areas of educational academia. So I'm looking to avoid intermediary technologies that can enhance/distort communication. I'm not saying React will do or not do that, it's just a general concern of mine.

help of cutting edge technology developed by businesses


The relationship between education and business is uncertain for me. I worked on the PISA project in its early years when it was cutting-edge and managed by Australians. Australia is now in decline on its scales (graph below). I also conceived and successfully managed its first international computer-based test (pure Java - I didn't program) which got me an invite to a large firm in Menlo Park ~2005, after which I went into Kepler's bookshop to buy some books on philosophy. I had a hunch that technology inspired education was heading in the wrong direction, and unfortunately the graph below now supports that hunch. Conflicts across education, business and technology has affected my career, and not always in a good way.


Further, the health of democracies - which is a function of education - seem compromised across the globe and my hypothesis is that how technology is used in education affects this. An inordinate focus on science and technology without ethics or moral education is my hypothesis here.

But in the end, I'm a plodding educator who can't program very well, and I think Java Ranch is really cool because it's very communicative and real.  I'm currently solving a classpath problem lol.
1 year ago