Yegor Bugayenko

Ranch Hand
+ Follow
since Feb 11, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
2
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Yegor Bugayenko

In a pure object-oriented programming, there should be only one exit point from each method, here is why: http://www.yegor256.com/2015/08/18/multiple-return-statements-in-oop.html
8 years ago
It's an old topic but still relevant. See this blog post: http://www.yegor256.com/2014/05/13/why-null-is-bad.html It claims that using (returning or accepting) NULL is a terrible practice
9 years ago

Junilu Lacar wrote:If your mocking gets too complicated, then your object relationships are likely too complicated as well. If your test code requires a lot of complicated setup to test one small behavior, then there may be problems with your abstractions.



+1 Touche!
9 years ago
What is more important that "how does it look like" is "how does it behave". Its behavior is rather complex, since it returns other objects, that also expose some behavior, etc. etc. The entire hierarchy of objects is hidden behind its simple 2-3 method interface.
9 years ago
@Junilu you're absolutely right about Mk/Fk naming. I gave that names to classes some time ago, when I wasn't sure how to call them right - mock or fake. Now I'm sure, they are fake objects.

About your example, I also agree. If we can design our class this way, even better. But even though, compare this test:



with this one:



I find the second one much easier to understand.
9 years ago
These are fake objects, no mocks: AMock and BMock

Mock is something you create like this:



And this approach is error-prone, you should use it as a last resort. Fakes objects will make your tests compact and maintainable. Mocks will pollute your unit tests and even turn them into unmaintainable mess.
9 years ago

If a class that is nothing but a data container



This is where is the misconception I'm talking about. An object is NOT a data container. We're not in COBOL any more. Java is an object-oriented language! I hope
It's a flaw in Java design. Static methods and utility classes should be avoided in object-oriented programming, see this: http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html Despite all that, Java main(String...) method has to be static. It's just the way it is
9 years ago
I would recommend to read "Object Thinking" book by David West
9 years ago
Instead of mocking it's better to use fake objects. I've published an article on this subject a few weeks ago: http://www.yegor256.com/2014/09/23/built-in-fake-objects.html

So, in your case, before instantiating ImplementationClass, prepare fake versions of A, B, and C. Then, use them in the ctor. As a rule of thumb, try to stay as far away from mocking frameworks, as you can.
9 years ago
First of all, Wikipedia should help you: https://en.wikipedia.org/wiki/Abstraction_(computer_science)#Abstraction_in_object_oriented_programming

From myself I can explain it by example.

I don't know you. I never met you. I don't know where do you live. I don't know whether you're a man or a woman. I don't even know whether you're a human being or a computer bot.

But I'm writing this message to you now.

All I need in order to do this is to abstract myself away from who you really are and deal with your abstraction in my head and in this website.

This abstraction in my head knows how to read my messages. That's all I need to know about you.

Thus, abstraction is a simplification of real world things in order to make more digestible
System is a bad name here, since it conflicts with java.lang.System. I would recommend to use Base.

It is the main and the only class you instantiate at your application "entrance", also known as function main(). For example, if it is a command line application, it may look like:



The entire logic of your application is implemented by this class.
Java programs are full of getters and setters (setName, getById, setRequest, etc.) Some people consider them an anti-pattern in object-oriented programming. Recently I wrote an article where tried to summarize the arguments: http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

Would be great to hear you opinions.
Try jcabi-ssh, which is a very simple and convenient wrapper of JSch