Oh jeesh man. Yes, stakeholders, projects, and relation. You have just been writing about how it is such a no-no for JavaSpaces to use Entry because it is not specifically a part of spaces....well String isn't either...and neither is Class. My point is, you need to know where you are going before you can architect a system to get what you require. Plain and gosh darn simple. Just because something is used in more than one system doesn't make it a no-no.
Jini is a base tool for a specific set of purposes. Part of it is JavaSpaces. Other Jini parts use Entry. Just because Spaces uses Entry which is really a common class does not mean it is a no-no nor mean the architecture is bad, nor that there is a coupling problem. My overall point, bluntly, is you have to understand that before you start talking cohesion, decoupling, and architecture. That isn't tack that is reality. This is tack. On the words, my point is that you keep talking about the words less the real meaning in the context of what you are working on...Jini...not just spaces, not just lookup, and not just Linda...Jini. The whole package. There is going to be some commonality, and without doubt there is always going to be refactoring which can be achieved and cohesion and decoupling can be improved. I see Entry, Transaction, Lease as common classes needed by different systems. Entry is a marker interface with a specific meaning in the overall project. Are you saying it should not exist? Are you saying all things should just operate on POJOs? What is your specific meaning? Cohesion, Coupling, Architecture have no meaning, literally no definition, without something hard, pieces, which are capable of being coherent, coupled or decoupled, to be architected is my point, and requirements, that which you need, give you those pieces which can actually be a model to be those things. Wade ================== Wade Chandler, CCE Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member http://www.certified-computer-examiner.com http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org ----- Original Message ---- > From: Michael McGrady <[email protected]> > To: [email protected] > Sent: Thursday, December 11, 2008 6:46:40 PM > Subject: Re: Split JavaSpaces and JINI > > If you think that planning, examining or even improving the structure or > River > in relation to its stakeholders is just "talk", or that high cohesion and low > coupling just as much as good documentation and comprehensive testing are not > values independent of needs and requirements of the stakeholders, then the > future looks bleak. I don't think you really want to take this tack. I > think > we can say that certain things are bad whatever your requirements or needs. > There are legitimate architectural standards, e.g., the ilities that have > nothing to do with function. > > Mike > > On Dec 11, 2008, at 11:24 AM, Wade Chandler wrote: > > > I think you'll find in any debate, more scientific in nature at least, > > which > by itself precludes politics :-D, devoid of words, and more filled with > examples > of the thing being debated will be more tolerable for those in the > discussion. > We can talk architecture all day long, but without an understanding of > exactly > what you or we are talking about, those pieces we are referring, and > specifically what River is, will be, and everyone's understanding of those > things, cohesion, decoupling, architecture (to a degree) are all irrelevant. > The > needs and requirements and what that means at large are needed first. The > horse > before the cart. > > > > Wade > > > > ================== > > Wade Chandler, CCE > > Software Engineer and Developer, Certified Forensic Computer Examiner, > NetBeans Dream Team Member, and NetBeans Board Member > > http://www.certified-computer-examiner.com > > http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam > > http://www.netbeans.org > > Michael McGrady > Senior Engineer > Topia Technology, Inc. > 1.253.720.3365 > [email protected]
