tag:blogger.com,1999:blog-32241238.post1523983766536113829..comments2023-03-25T05:46:26.256-04:00Comments on Why not?: Dream Programming Language: No Static FieldsDanhttp://www.blogger.com/profile/06099373265709774874noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-32241238.post-66609639455362590392008-12-15T11:21:00.000-05:002008-12-15T11:21:00.000-05:00Oh, and if you're feeling really advanced, you mig...Oh, and if you're feeling really advanced, you might want to look into Haskell's monads. Monads are steeped in pretty deep math and functional programming concepts. Monads allow the developer to model state in the stateless world of functional programming. As a nice benefit, they allow you to differentiate between functions without side-effect and functions that cause a side effect (in fact, these have different static types, so you can't get it wrong). One of the first things that I read regarding monads was <A HREF="http://en.wikibooks.org/wiki/Haskell/Understanding_monads" REL="nofollow">an example describing a random number generator</A>. After that, try watching the great Brian Beckman's introductory video: <A HREF="http://channel9.msdn.com/shows/Going+Deep/Brian-Beckman-Dont-fear-the-Monads/" REL="nofollow">Don't fear the Monads</A>.Danhttps://www.blogger.com/profile/06099373265709774874noreply@blogger.comtag:blogger.com,1999:blog-32241238.post-25562175968496875142008-12-15T11:15:00.000-05:002008-12-15T11:15:00.000-05:00I think that my views on static fields and singlet...I think that my views on static fields and singletons came from learning about unit testing. Singletons especially can make unit testing nearly impossible, unless you are willing to completely break encapsulation. You might start by reading some unit testing literature. A good introduction (and the book that started me off) is <A HREF="http://www.amazon.com/dp/0321146530" REL="nofollow">Test Driven Development: By Example</A>. Once you adopt a unit-testing mindset, you may find that designs that you previously thought were beautiful are now ugly. It seems to cause developers to shift their way of thinking, and that's almost definitely a good thing.<BR/><BR/>I understand your desire for books on "pure OO". It seems like there's plenty of introductory literature, but nothing for the intermediate developer. For what it's worth, I think intermediate OO deals with patterns and practices to enable large scale software re-use. You might want to look into:<BR/>* <A HREF="http://en.wikipedia.org/wiki/Single_responsibility_principle" REL="nofollow">Single Responsibility Principle</A><BR/>* Preferring composition over inheritance<BR/>* Keeping your class hierarchies as shallow as possible<BR/>* Defaulting to public visibility wherever possibleDanhttps://www.blogger.com/profile/06099373265709774874noreply@blogger.comtag:blogger.com,1999:blog-32241238.post-79046408084305314792008-12-15T04:19:00.000-05:002008-12-15T04:19:00.000-05:00I really appreciate your point of view about singl...I really appreciate your point of view about singleton and static fields. They help to make some tricks sometimes, but they are not in scope of Object Oriented concepts, so they should be considered as, well, some sort of useful garbage, I avoid to use them principally. By the way can you point me some good literature titled like "Pure Concepts of OO Programming", but not for the beginners of course I want something scientifically advanced.Testhttps://www.blogger.com/profile/02575292473252442625noreply@blogger.com