ok so bounded type parameter, i'll look at that up
The Big Programming Thread - Page 796
Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
Deleted User 3420
24492 Posts
ok so bounded type parameter, i'll look at that up | ||
spinesheath
Germany8679 Posts
Don't use singletons just because you only need a single instance of that class. You can consider using them if it is absolutely critical that there never is more than one instance of that class. And even then there might be better alternatives. Singleton is taught way too carelessly and as a result many people think it's a good pattern when it really is not (most of the time). There probably also is a historic reason to the prominence of the pattern, because it allowed people who came from C to use static variables in the then new C++ while still pretending that they have successfully adopted OPP principles. The pattern has very real drawbacks (threading issues, hard to get away from if needed) that might not be apparent at the moment but often come back to haunt you. | ||
RoomOfMush
1296 Posts
There is no build-in support for singletons in the java language. You usually use Singletons in java by either defining a "public static final" member variable in some kind of class or by using a "public static" method which will (lazy) initialize a "private static final" member variable and return it. Example: public class BigBadController { or if you have a multithreaded application: public class BigBadController { | ||
AKnopf
Germany259 Posts
![]() | ||
Manit0u
Poland17185 Posts
![]() | ||
Neshapotamus
United States163 Posts
On November 10 2016 12:52 Manit0u wrote: ![]() Dependency Injection alone is great. I use it for unit testing and such. However, as soon as you introduce dependency injection, you will almost certainly see it with coupled with "inversion of control". To implement inversion of control, you will start using a container. Containers solve dependency injection but introduce object lifetime management problems. In a typed language, you will trade compile time errors for runtime errors. Why bother using a typed language? You API design is going to down the shitter. Eventually, your code it going to be unmanageable because your API is so fucked. ex: A -> B -> C -> D .... -> Z People stop caring about API design because ill let my container figure out how to resolve dependencies instead of making the api better. I don't have a solution to this, but I have seen this happen way too many times. It makes we wonder if dependency injection is the answer. Ultimately, dependency injection is just a glorified term for passing a parameter to a function. I think functional programming is the answer as this is what functional programming solves inherently in the language. | ||
phar
United States1080 Posts
e.g. https://google.github.io/guice/api-docs/latest/javadoc/index.html?com/google/inject/Singleton.html | ||
Manit0u
Poland17185 Posts
On November 10 2016 16:00 phar wrote: There exists also the concept of using dependency injection to inject... a singleton. e.g. https://google.github.io/guice/api-docs/latest/javadoc/index.html?com/google/inject/Singleton.html This reminds me of the good old AbstractSingletonProxyFactoryBean ![]() Convenient proxy factory bean superclass for proxy factory beans that create only singletons. Taken from "Everything wrong with Java in a single class." | ||
Djagulingu
Germany3605 Posts
On November 10 2016 16:07 Manit0u wrote: This reminds me of the good old AbstractSingletonProxyFactoryBean ![]() Taken from "Everything wrong with Java in a single class." Is this shit for real or did Spring guys create this shit just for fun and games and shit | ||
ZigguratOfUr
Iraq16955 Posts
On November 10 2016 16:32 Djagulingu wrote: Is this shit for real or did Spring guys create this shit just for fun and games and shit Oh it's for real. I have many more doubts about InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState (from com.sun.java.swing.plaf.nimbus.State). | ||
emperorchampion
Canada9496 Posts
On November 10 2016 16:41 ZigguratOfUr wrote: Oh it's for real. I have many more doubts about InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState (from com.sun.java.swing.plaf.nimbus.State). rofl | ||
Djagulingu
Germany3605 Posts
On November 10 2016 16:41 ZigguratOfUr wrote: Oh it's for real. I have many more doubts about InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState (from com.sun.java.swing.plaf.nimbus.State). http://www.javafind.net/gate.jsp?q=/library/36/java6_full_apidocs/com/sun/java/swing/plaf/nimbus/package-tree.html It's the entire fucking package :D | ||
RoomOfMush
1296 Posts
On November 10 2016 21:49 Djagulingu wrote: http://www.javafind.net/gate.jsp?q=/library/36/java6_full_apidocs/com/sun/java/swing/plaf/nimbus/package-tree.html It's the entire fucking package :D As far as I know these are auto-generated. No reason to argue about the readability of auto-generated code. | ||
Acrofales
Spain17831 Posts
On November 10 2016 16:41 ZigguratOfUr wrote: Oh it's for real. I have many more doubts about InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState (from com.sun.java.swing.plaf.nimbus.State). Well, that's just a naming convention gone horribly wrong. I have no idea what the class is supposed to do, but it seems like something you might want to do. The other one... why in the holy hell would anybody create something like that? Just click on it. And then click through to the superclasses and things; there's plenty of goodness there. But before you click, ask yourself one simple question: what does a factory to create singletons do? | ||
Manit0u
Poland17185 Posts
Good read for anyone. | ||
Deleted User 3420
24492 Posts
| ||
Blitzkrieg0
United States13132 Posts
On November 11 2016 10:19 travis wrote: For example an insert method inserting into an empty tree is easy. just return a nonemptytree with the key and value. inserting into the nonempty tree, I use recursion to check for duplicate key, if i hit a duplicate i replace the value. using compareTo I move left/right down the tree appropriately until.... i hit a leaf. but how the fuck will I know when I hit a leaf? What does polymorphism have to do with any of this? You're going to have an insert method for the NonEmptyTree class and a different method implementation for the EmptyTree class. Polymorphism as described above will determine which method will be executed. You don't actually know when you hit a leaf. The code does though which is the point of polymorphism. | ||
Deleted User 3420
24492 Posts
| ||
Blitzkrieg0
United States13132 Posts
On November 11 2016 10:29 travis wrote: OH, so the way I use my methods is by using my "right" and "left" tree members? Since they are either nonemptytree OR emptytree? I'll try to go through an example so it's clear... Lets say I have a Tree structure like the following where E signifies an EmptyTree and the fourth level is all EmptyTree where I was too lazy to draw the rest of tree: root 8 So I'm going to insert a new Tree into my structure which has the value 12. My insertion method will be called on the root. This is a NonEmptyTree so we'll be using that insertion method. This method determines if it go to the left or right child based on a simple comparison. 12 is greater than 8 so we'll call the insertion method on the right. Again we've hit a NonEmptyTree so the same thing happens. This time 12 is less than 14 so we'll call the insertion method on the left. Now we've hit an EmptyTree so a different method will be executed. This method is going to replace that node with a NonEmptyTree with the value 12. Because of polymorphism, the code knows which method to execute and we don't actually know or care. | ||
Deleted User 3420
24492 Posts
Suddenly I don't think this design is so annoying. (it also means this project is way way easier than I thought) | ||
| ||