Self-containment in OO
in [OOP]
|
Prev: Last Call for Papers Reminder (extended): The World Congress on Engineering WCE 2010
Next: CFP CGVCVIP 2010: new date - until 29 March 2010
From: johnzabroski on 28 Apr 2010 15:33 On Apr 16, 9:00 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Daniel T. wrote: > > The heuristics alone as a bald list do seem a bit rough, but you have to > > remember there is an almost 400 page book that goes along with them. > > Also, keep in mind, the book was written in 1996 when people were new to > > OO. Now, some of the heuristics are things that are an ingrained part of > > the community. > > Ah, if only it were true with javascript community. Take a look at, for > example, Dojo or MooTools. > -- > Garrett > comp.lang.javascript FAQ:http://jibbering.com/faq/ Interesting. I would love examples of shitty Javascript code. Where should I start looking? I don't think the problem is especially unique to prototype-based languages like Javascript, though...
From: S Perryman on 29 Apr 2010 04:21 johnzabroski(a)gmail.com wrote: > On Mar 22, 7:40 am, Vladimir Jovic <vladasp...(a)gmail.com> wrote: > Bottom line: Your software, as implemented, sucks, and is not testable > in the way OO programmers discuss testability. Kent Beck pioneered > Test-Driven Development as a way to help prevent programmers from > making such design mistakes, because testing first generally causes > programmers to steer clear of such awful designs. Ironic, as all the examples I've ever seen presented by the test-driven "gurus" have appalling testability (by "testability" I use the long- time qualitative/quantitative definitions used by the hardware/software engineering communities) . Regards, Steven Perryman
From: Vladimir Jovic on 29 Apr 2010 04:50 johnzabroski(a)gmail.com wrote: > > It is fundamentally obvious to anyone looking at your example that you > are using object superclasses as a way to control leaf classes. What > you've effectively done is build a lattice, or house of cards, for a > software system. The reason unit testing is getting progressively > harder is that you don't actually have any real world analagous units > to test, so as you make changes to your software, you have to edit the > lattice appropriately. This requires preserving an entailment > relation through all leaf classes that ensures value paths are > steady. Technically speaking, this is fundamentally impossible to do > and will guarantee client code will break if it is using value paths > now absorbed by the new class. > You got that more or less right. The good thing is that I have better confidence in unit tests, because they are doing more then just unit testing. Not all things are "emulated" (as in TDD), but the very bad side is the maintenance is getting harder. > Bottom line: Your software, as implemented, sucks, and is not testable > in the way OO programmers discuss testability. Kent Beck pioneered > Test-Driven Development as a way to help prevent programmers from > making such design mistakes, because testing first generally causes > programmers to steer clear of such awful designs. I know, but I am trying to improve :) What are alternatives? How to fix such architecture? I am looking into dependency injection, but if you know of more techniques and design patterns that are used in TDD, would be great if you share.
From: S Perryman on 29 Apr 2010 06:02 Vladimir Jovic wrote: > What are alternatives? How to fix such architecture? > > I am looking into dependency injection, but if you know of more > techniques and design patterns that are used in TDD, would be great if > you share. 1. Separation of concerns A universal means of reducing dependency. 2. If you have a system with a dependency graph thus : A -> B -> C1 -> D -> E -> F -> C2 There is nothing wrong with that. From the construction/testability viewpoint, we are asking whether you can construct/test thus : E -> F D -> E C1 -> D B -> C1 + C2 A -> B where the entities on the right-hand side of the "->" are the real entities, or test stubs. The problem you appear to have is that the dependency chain cannot be divided as above, for your system. On that basis, the "Demeter" principles are probably most appropriate. These attempt to minimise the dependencies that entities have on eachother. You will also find that the Demeter concepts have good synergy with things like dependency injection. Regards, Steven Perryman
From: Vladimir Jovic on 29 Apr 2010 07:40
S Perryman wrote: > Vladimir Jovic wrote: > >> What are alternatives? How to fix such architecture? >> >> I am looking into dependency injection, but if you know of more >> techniques and design patterns that are used in TDD, would be great if >> you share. > > 1. Separation of concerns > > A universal means of reducing dependency. > > > 2. If you have a system with a dependency graph thus : > > A -> B -> C1 -> D -> E -> F > -> C2 > > There is nothing wrong with that. > > From the construction/testability viewpoint, we are asking whether you > can construct/test thus : > > E -> F > D -> E > C1 -> D > B -> C1 + C2 > A -> B > > where the entities on the right-hand side of the "->" are the real > entities, or test stubs. > I can, but the problem (I think) is that I am using real objects for unit testing. > The problem you appear to have is that the dependency chain cannot be > divided as above, for your system. > > On that basis, the "Demeter" principles are probably most appropriate. > These attempt to minimise the dependencies that entities have on eachother. > > You will also find that the Demeter concepts have good synergy with things > like dependency injection. > That means I am on good tracks, because that is how I designed the system (based on the Demeter concepts). Thanks |