The Big Programming Thread - Page 958

On May 03 2018 03:00 Manit0u wrote:


Private static is fine for the most part. Public static is where things get hectic.

Here's a nice and brief explanation:
https://dzone.com/articles/why-static-bad-and-how-avoid

Edit:

Also, speaking of DI and encapsulation I think that Symfony project in PHP world is doing a great thing. They're basically forcing you to do nice and clean DI as they won't allow typehinting arguments to constructors with concrete classes, you can only specify interfaces and then inject whatever you want that implements this interface. Very neat.

On May 03 2018 03:23 Excludos wrote:
You can make anything look horrible if you really try. Static has its place in programming. I've had classes with thousands of lines being a static only class, as the alternative would be to repeat those thousands of lines throughout the entire project. Like everything else it's just a tool; If you use it badly it's going to make bad code. Doesn't really have anything to do with the language being oop or not.

Btw, remember that boss I had who told me not to test my code? Just started in a new job. I have a week or two until my first proper project, so I can spend them learning whatever I want. I told them I wanted to spend everything only on learning to test properly, and they were ecstatic about it. I love it here already :D If anyone has any good reads, guides, whatever on the subject I'm grateful.

On May 03 2018 03:42 Acrofales wrote:


You used php and great thing in the same sentence. And it wasn't "it'd be a great thing if php burned in everlasting hell"...

On May 02 2018 01:33 nunez wrote:


this is me almost. except i use i3 instead of xmonad, and emacs instead of spacemacs. i switched from vim recently, very fun and painful. the way i use emacs tends to make me rely a bit less on the windows manager and the shell, which maybe is a bit worriesome, and un-unix like. maybe if used emacs server / client instead this would not be an issue. however i chose the easier path.

i try to homogenize hotkeys (f.ex. navigation) and theme across the programs i use in a programming context (windows-manager, text-editor, shell), but i don't bother customizing other software. i have a nice background photo that reminds me of relaxing in nature, the opposite of working with programming, but my tiling window manager makes sure i never get to see it.

i am planning to transition to guixsd from arch linux. but i did not find the time yet. i really do like arch, but i want to try something new. hopefully it will not be as short-lived as my excursion into gentoo.

On May 01 2018 13:44 berated- wrote:


I haven't played around with dagger a whole lot, but, I'm a pretty big spring fan boy, so maybe that makes me qualified to help?

Dependency injection is most often used to help implement the Inversion of Control pattern. The entire point is that one does not know where or how their dependencies are constructed, just that they need the service. The base example I always go back to is a print service in java. I don't care how the printer implementation is done, I just know that I need someone that can print, so I'm going to request such a service with my @Inject.

The reason I point this out, is when you say you just need a key generator with certain parameters, it feels like it doesn't line up with IoC in the way previously mentioned. IoC would work best if you just said, hey,I need a key generator, not with certain parameters. That's where in the Java world where we love our patterns, the factory pattern comes in. In your case you don't just need a keygenerator, you need one who knows how to make key generators. You could inject that in, and then use that method.

All of this is kind of eclipsed by the fact that you then mention statics. This isnt' to say that statics are bad, it's just that, they aren't often used with DI. One of the reasons that DI is so popular is that when you aren't specifying your implementation, but yet the interface that you need -- one can provide a completely different implementation under test that can skip hard integration and allow for easier unit testing with mocks or test doubles. Specifying a concrete implementation into a static field doesn't help that much for test-ability in most cases.

If you would like to get into more specifics I would be glad to ramble more.

On May 02 2018 05:24 Blisse wrote:


For your case, your Application needs to store an instance of the AppComponent object, and you'll do something like `Application.getInstance.inject(this)`.

I've never tried injecting into static fields, but I wouldn't be surprised if that doesn't work. You're basically subverting the whole point of using a dependency injection framework.

IMO this (https://www.techyourchance.com/dagger-tutorial/) is a simple Dagger tutorial that should get you running. Vasiliy has good ideas about Dagger. I would also check r/androiddev if you have any Android specific questions, more actives there.

On May 02 2018 07:14 Manit0u wrote:
It depends on how you use them, but most of the time static properties (methods, variables, attributes, you name it) break encapsulation and introduce global state, which you usually want to avoid. Do you really, really need a method to be globally accessible?

Every time you want to use the static keyword in an OOP language you should ask yourself some questions first:
1. Do you really need a method that can be called without instantiating an object?
2. If your answer to #1 was "yes" then you must ask yourself if this breaks the single responsibility principle?
3. In any case, maybe this code could be moved to a different class altogether and not make it static?

The only reasons I've found to use static props was for some helper classes, preferably making them abstract so that they're never instantiated (man, sometimes I really wish you could use both final and abstract at the same time). Usually they're used for storing some kind of system setting stuff that has to be hardcoded.

Perhaps I'm dead wrong, but that's my take on it

On May 07 2018 05:19 WarSame wrote:
The problem is that I need to access KeyGenerator a few function levels down, so I can't simply call 2 different interfaces. Once again, I face the problem that I need to get access to an object levels down the tree from something above it. That was where I thought DI came in.

On May 07 2018 06:31 WarSame wrote:
Yes, it is because the KeyGuard relies on some "authenticated" state being set. I don't know of any good way around that.

On May 07 2018 09:51 WarSame wrote:
Sorry, I did way back.

KeyGuardManager

createDeviceConfirmCredential starts an Intent that prompts the user to authenticate using their normal phone login credentials.

On May 06 2018 05:05 WarSame wrote:
...
I'll consider this but I don't think I know enough to correct my architecture to what you're saying.

Java/Android does not favor any app architecture nor does it have a dominant design pattern

On May 08 2018 04:51 Blisse wrote:
Android has favoured MVP for the last half decade, ...

On May 10 2018 06:14 WarSame wrote:
Could you link some examples of MVP and MVVM? I have not spent much time in my life looking at architecture in practice. I had a shitty Software Architecture course in university.