I'm using both ways for get the simple class name in Kotlin, but I don't know which the best.
I often use for logging, so I use only into current class, therefore I use this in example bellow.
Someone help me, please.
this::class.simpleName
OR:
this.javaClass.simpleName
It's probably more important to pick one method and be consistent. I doubt there is an established best practice on this particular matter (though you never know). It's also unlikely either of these perform better or worse than the other.
That being said, this.javaclass will only be available when running on the JVM: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.jvm/java-class.html
Whereas this::class I believe is commonly available whether you are targeting JVM, JS or Native. As a rule of thumb, I tend to favor whichever is common across all targets when there is a choice.
Related
I am not quite sure if this question belongs here or to another community on stackexchange, if the latter, I could not find the right one and would be glad about a hint.
I am at the moment programming a little game (roundbased -no threading) in Java and I am wondering:
Is it bad practice if one object is known to several others?
In my case I wonder if I should create an Object o and then pass it as a constructor argument to several other, later created objects.
It does work, but I wonder if this should in general rather not be done?
Does someone have an answer?
Yes of course. It is normal case in the world of oop. One of simple examples of such usage is dependency injection. For more information see https://en.m.wikipedia.org/wiki/Dependency_injection
Besides, many design patterns use such approach : strategy, observer etc.
Is sequential coupling really a bad thing in code?
Although it's an anti-pattern, the only risk I see is calling methods in the wrong order but documentation of an API/class library with this anti-pattern should take care of that. What other problems are there from code which is sequential? Also, this pattern could easily be fixed by using a facade it seems.
Thanks
It is an antipattern to just ignore a method call because something which shouldn't have been done before hasn't.
This should be controlled using design by contract. Failed preconditions typically raise a failed precondition exception, which is basically the software yelling at you if you use the class in the wrong way. They are superior to written documentation.
Even in Wiki article you mentioned there is an opinion that
This may be an anti-pattern, depending on context.
In many cases there is no other way. Eventually we use algorithms to solve tasks. And they are by definition
an effective methods for solving a problem using a finite sequence of instructions
Sometimes it's possible to hide this sequence. But not always.
its a minor anti pattern, as if the documentation is bad (or the api is confusing) you can get things into a bad states. Its like a recipe where it only tells you to put the yolks aside after you've already beaten the eggs together.
We've had a slight change to our system which means what used to be two related business rule are now the exact same rule. Because of this, I've generalised the implementation and I'm wondering what to do with the old specified classes related to them.
Is it lazy to leave the old classes lying around and just inheriting the new generalised version (with no extra content, just empty classes)? Or is it sensible because it saves a good deal of refactoring?
The interface is the same regardless - so I'm curious : epically lazy, or cunningly avoiding unnecessary refactoring?
Get rid of it. That is the point of source control. If you ever need to refer to it, it'll be in the history.
Get rid of the extra class. What's the purpose of keeping it?
Don't your refactoring tools handle this for you?
If the code doesn't do anything, get rid of it. Source control will keep the history for you should you ever need to refer back to it.
imho, clean, readable and concise code should be ever developer's goal aside from meeting the business requirements. That said, I would deprecate the classes, and make a task to refactor when time allows. Deprecating the class will help developers to know what class should be used.
From pure OO design perspective, you should clean up the code.
From software delivery perspective, there are reasons why you may not want to do that:
Minimize amount of unnecessary changes to the code. helps with investigations in production issues.
Save the opportunity cost of re-factoring and use it on something more beneficial.
Even if you don't have something like Resharper, you can use VS.NET's "Find Usages" tool. Then update all usages to the new class.
Alternatively, just delete it and fix the compile errors. A.k.s "poor man's refactoring".
I asked this question about Microsoft .NET Libraries and the complexity of its source code. From what I'm reading, writing general purpose libraries and writing applications can be two different things. When writing libraries, you have to think about the client who could literally be everyone (supposing I release the library for use in the general public).
What kind of practices or theories or techniques are useful when learning to write libraries? Where do you learn to write code like the one in the .NET library? This looks like a "black art" which I don't know too much about.
That's a pretty subjective question, but here's on objective answer. The Framework Design Guidelines book (be sure to get the 2nd edition) is a very good book about how to write effective class libraries. The content is very good and the often dissenting annotations are thought-provoking. Every shop should have a copy of this book available.
You definitely need to watch Josh Bloch in his presentation How to Design a Good API & Why it Matters (1h 9m long). He is a Java guru but library design and object orientation are universal.
One piece of advice often ignored by library authors is to internalize costs. If something is hard to do, the library should do it. Too often I've seen the authors of a library push something hard onto the consumers of the API rather than solving it themselves. Instead, look for the hardest things and make sure the library does them or at least makes them very easy.
I will be paraphrasing from Effective C++ by Scott Meyers, which I have found to be the best advice I got:
Adhere to the principle of least astonishment: strive to provide classes whose operators and functions have a natural syntax and an intuitive semantics. Preserve consistency with the behavior of the built-in types: when in doubt, do as the ints do.
Recognize that anything somebody can do, they will do. They'll throw exceptions, they'll assign objects to themselves, they'll use objects before giving them values, they'll give objects values and never use them, they'll give them huge values, they'll give them tiny values, they'll give them null values. In general, if it will compile, somebody will do it. As a result, make your classes easy to use correctly and hard to use incorrectly. Accept that clients will make mistakes, and design your classes so you can prevent, detect, or correct such errors.
Strive for portable code. It's not much harder to write portable programs than to write unportable ones, and only rarely will the difference in performance be significant enough to justify unportable constructs.
Even programs designed for custom hardware often end up being ported, because stock hardware generally achieves an equivalent level of performance within a few years. Writing portable code allows you to switch platforms easily, to enlarge your client base, and to brag about supporting open systems. It also makes it easier to recover if you bet wrong in the operating system sweepstakes.
Design your code so that when changes are necessary, the impact is localized. Encapsulate as much as you can; make implementation details private.
Edit: I just noticed I very nearly duplicated what cherouvim had posted; sorry about that! But turns out we're linking to different speeches by Bloch, even if the subject is exactly the same. (cherouvim linked to a December 2005 talk, I to January 2007 one.) Well, I'll leave this answer here — you're probably best off by watching both and seeing how his message and way of presenting it has evolved :)
FWIW, I'd like to point to this Google Tech Talk by Joshua Bloch, who is a greatly respected guy in the Java world, and someone who has given speeches and written extensively on API design. (Oh, and designed some exceptionally good general purpose libraries, like the Java Collections Framework!)
Joshua Bloch, Google Tech Talks, January 24, 2007:
"How To Design A Good API and Why it
Matters" (the video is about 1 hour long)
You can also read many of the same ideas in his article Bumper-Sticker API Design (but I still recommend watching the presentation!)
(Seeing you come from the .NET side, I hope you don't let his Java background get in the way too much :-) This really is not Java-specific for the most part.)
Edit: Here's another 1½ minute bit of wisdom by Josh Bloch on why writing libraries is hard, and why it's still worth putting effort in it (economies of scale) — in a response to a question wondering, basically, "how hard can it be". (Part of a presentation about the Google Collections library, which is also totally worth watching, but more Java-centric.)
Krzysztof Cwalina's blog is a good starting place. His book, Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, is probably the definitive work for .NET library design best practices.
http://blogs.msdn.com/kcwalina/
The number one rule is to treat API design just like UI design: gather information about how your users really use your UI/API, what they find helpful and what gets in their way. Use that information to improve the design. Start with users who can put up with API churn and gradually stabilize the API as it matures.
I wrote a few notes about what I've learned about API design here: http://www.natpryce.com/articles/000732.html
I'd start looking more into design patterns. You'll probably not going to find much use for some of them, but as you get deeper into your library design the patterns will become more applicable. I'd also pick up a copy of NDepend - a great code measuring utility which may help you decouple things better. You can use .NET libraries as an example, but, personally, i don't find them to be great design examples mostly due to their complexities. Also, start looking at some open source projects to see how they're layered and structured.
A couple of separate points:
The .NET Framework isn't a class library. It's a Framework. It's a set of types meant to not only provide functionality, but to be extended by your own code. For instance, it does provide you with the Stream abstract class, and with concrete implementations like the NetworkStream class, but it also provides you the WebRequest class and the means to extend it, so that WebRequest.Create("myschema://host/more") can produce an instance of your own class deriving from WebRequest, which can have its own GetResponse method returning its own class derived from WebResponse, such that calling GetResponseStream will return your own class derived from Stream!
And your callers will not need to know this is going on behind the scenes!
A separate point is that for most developers, creating a reusable library is not, and should not be the goal. The goal should be to write the code necessary to meet requirements. In the process, reusable code may be found. In that case, it should be refactored out into a separate library, where it can be reused in the future.
I go further than that (when permitted). I will usually wait until I find two pieces of code that actually do the same thing, or which overlap. Presumably both pieces of code have passed all their unit tests. I will then factor out the common code into a separate class library and run all the unit tests again. Assuming that they still pass, I've begun the creation of some reusable code that works (since the unit tests still pass).
This is in contrast to a lesson I learned in school, when the result of an entire project was a beautiful reusable library - with no code to reuse it.
(Of course, I'm sure it would have worked if any code had used it...)
Lately, I've been making use a lot of the Strategy Pattern along with the Factory Pattern. And I really mean a lot. I have a lot of "algorithms" for everything and factories that retrieve algorithms based on parameters.
Even though the code seems very extensible, and it is, having N factories seems a bit of an abuse.
I know this is pretty subjective, and we're talking without seeing code, but is this acceptable in real world code? Would you change something ?
OK- ask yourself a question. does/will this algorithm implementation ever change? If no then remove the strategy.
I am maintence.
I once was forced (by my pattern lovin' boss) to write a set of 16 "buffer interpreter tuxedo services" using an AbstractFactory and a double DAO pattern in C++ (no reflections, no code gen). All up it something like 20,000 lines of the nastiest code I've even seen (not the least because I didn't really know C++ when I started) and it took about three months.
Since my old boss has moved on I've rewritten them using good 'ole "straight up and down" procedural style C++, with couple of funky-macros... each service is like 60 lines of code, times 16... all up less than a 1000 lines of really SIMPLE code; so simple that even I can follow it.
Cheers. Keith.
Whenever I'm implementing code in this fashion, some questions I ask are:
what components do I need to substitute to test ?
what components will I expect users/admins to disable or substitute (e.g. via Spring configs or similar) ?
what components do I expect or suspect will not be required in the future due to (possibly) changing requirements ?
This all drives how I construct object or components (via factories) and how I implement algorithms. The above is vague, but (of course) the requirements can be similarly difficult to pin down. Without seeing your implementation and your requirements, I can't comment further, but the above should act as some guideline to help you determine whether what you've done is overkill.
If you're using the same design pattern all over the place, perhaps you should either switch to a language that has better support for what you're trying to do or rethink your code to be more idiomatic in your language of choice. After all, that's why we have more than one programming language.
Would depends on the kind of software I'm working on.
Maintenance asks for simple code and factories is NOT simple code.
But extensibility asks sometimes for factories...
So you have to take both in consideration.
Just have in mind that most of the time, you will have to maintain a source file MANY times a year and you will NOT have to extend it.
IMO, patterns should only be used when absolutely needed. If you think it can be handy in two years, you are better to use them... in two years.
How complex is the work the factory is handling? Does object creation really need to be abstracted to a different class? A variation of the factory method is having a simple, in-class factory. This really works best if any dependencies have already been injected.
For instance,
public class Customer
{
public Customer CreateNewCustomer()
{
// handle minimally complex create logic here
}
}
As far as Strategy overuse... Again, as #RichardOD explained, will the algorithm ever really change?
Always keep in mind the YAGNI principle. You Aren't Gonna Need It.
Can't you make an AbstractFactory instead off different standalone factories?
AlgorithmFactory creates the algorithms you need based on the concrete factory.