-5

I have the following strange question. Lets say we have a class BlackJackGame and this class contains the BlackJackGame algorithm for electing a winner. Same class though contains the main method for starting the game. This main method in some sense is violating the principle of Single Responsibility for a class. In addition lets say we place one more method for printing the winner in some format. Lets say this method is also static, is this method breaking the responsibility principle any more than the main method. And then what, lets say we say that it is breaking. Does this mean we should create. Now lets presume we also have a utility method that parses the arguments coming from the command line and place it as static method as well.

1 Main class to hold the Main method, 1 Print class to hold the Print method and 1 ArgumentParser class holding a single static method to parse the arguments.

I will visualize it like this:

public class BlackJackGame{

//returns the wining player
public Player play(Deck deck) {
  // some logic here
}
// deck is a class holding the Deck.
public static Deck parseArguments(String args[]) {
// logic here
}

public static void printPlayer(Player winner) {
// some logic here
}

public static void main(String args[]) {
    Deck deck = createDeck(args);
    BlackJackGame game = new BlackJackGame();
    Player winner = game.play(deck);
    printWinner(winner);

}

}

If we follow the Single Responsibility Principle. Does it reay matter and is it more correct if we had:

public class BlackJackGame{

//returns the wining player
public Player play(Deck deck) {
  // some logic here
}
}

public class Main{

public static void main(String args[]) {
    Deck deck = DeckCreator.createDeck(args);
    BlackJackGame game = new BlackJackGame();
    Player winner = game.play(deck);
    Printer.printWinner(winner);

}

}

Isn't this a little bit extreme ???? Like Single Responsibility taken into extremities ?

I am asking this question because it popped up during a code review I requested here. codereview.stackexchange.com/questions/172469/… I kind of have feeling that it is a bit Single Responsibility Principle taken into extremeties to be honest.

Alexander Petrov
  • 9,204
  • 31
  • 70
  • 5
    _My opinion_ - don't hack up your code just so that it conforms to some named general guideline about how to approach code. – takendarkk Aug 09 '17 at 18:37
  • 2
    I wouldn't bother creating a separate class, especially for something as small scale as a blackjack game, but this question is opinion based. Remember there are few *absolute* rules in programming. – Kayaman Aug 09 '17 at 18:37
  • SRP rule always depends on context. Somebody will tell one thing, another will say different – ByeBye Aug 09 '17 at 18:38
  • I am asking this question because it popped up during a code review I requested here. https://codereview.stackexchange.com/questions/172469/blackjack-game-submitted-as-part-of-interview-but-deemed-to-be-below-their-sta/172479?noredirect=1#comment326970_172479 I kind of have feeling that it is a bit Single Responsibility Principle taken into extremeties to be honest. – Alexander Petrov Aug 09 '17 at 18:40
  • The first three comments all highlighted how this is an opinion-based question, and as such it does not belong on SO; sorry. – dcsohl Aug 09 '17 at 18:40
  • @dcsohl I still think it is interesting discussion which we can learn a lot. It is a very fundamental question and it is interesting to hear different opinions. – Alexander Petrov Aug 09 '17 at 18:41
  • 2
    A discussion of modern American politics would also be an interesting discussion from which we could all learn a lot. It doesn't belong here either. – dcsohl Aug 09 '17 at 18:42
  • Not extreme in my opinion. Keep in mind that each of those classes will grow as you add more logic to your game. Your program will be more readable if you separate the classes. – Kaveh Ghahremani Aug 09 '17 at 18:43
  • @AlexanderPetrov If you want a long, rambling opinion-based discussion with no concrete outcome then go to Quora. SO is explicitly not for this kind of stuff. – Slater Victoroff Aug 09 '17 at 18:49
  • @SlaterTyranus What is the problem at the end to summarize the points of both sides and produce an answer depicting them ? Even if it is not black and white still the arguments can be gathered and might be interesting. – Alexander Petrov Aug 09 '17 at 18:50
  • @SlaterTyranus but after all Stackoverflow has mechanism. I believe 5 votes are nessesary for the topic to be closed. 1 more and it will be closed :) – Alexander Petrov Aug 09 '17 at 18:51
  • @AlexanderPetrov The problem is that it's completely unanswerable. If that's what you're looking for again, go to Quora. SO does not and will not support these kinds of questions. – Slater Victoroff Aug 09 '17 at 18:52
  • @SlaterTyranus ok that is an answer I guess. That it is opinion based and not answerable. Thanks. – Alexander Petrov Aug 09 '17 at 18:52
  • 2
    ImO: SRP is a very important principle in coding. But each single responsibility contains more than one "sub-responsibilities". The question is, can you formulate the responsibility of a module in a simple way and are there other modules with overlapping responsibilities? Then you should rethink your programs structure. – aschoerk Aug 09 '17 at 18:53

1 Answers1

2

A few random thoughts.

(a) Can you even pin down precisely what it means for a class to have some "responsibility" ??? And subsequently, if (as I suspect) all you have is vague notions without any formally observable / measurable properties / characteristics to pin down the meaning of "responsibility", then how can you say as unequivocally as you do that what you have is violating it ?
(b) If your application grows large enough or you want certain advanced means (JMX) to interact with your running application, you will split "MyEngine" and "StartMyEngine" just naturally as you go. Methinks. If your application is not large/advanced/complex/critical/... enough, then not having that split will not matter much.
(c) Every instance method M(args) is the semantic equivalent of a static method SM that has all of args plus an argument of the type of the instance. So an instance method M() on class Foo is equivalent to a static method SM(Foo foo). This starts to reveal why your static print method "does not belong" in class BlackJackGame : it does not have any argument of type BlackJackGame and therefore cannot ever be said to relate in any way to the BlackJackGame type. Fundamentally speaking the same holds of course for main(String[]) but in that case its usage has become a common pattern, and moreover, there has to be an entry point somewhere somehow otherwise no java process could ever get started at all.

Erwin Smout
  • 18,113
  • 4
  • 33
  • 52
  • Yes I agree about your statement "This starts to reveal why your static print method "does not belong" in class BlackJackGame : it does not have any argument of type BlackJackGame and therefore cannot ever be said to relate in any way to the BlackJackGame type. " But now lets imagine that this method was placed in Player instead of BlackJackGame. How thing would have looked like then – Alexander Petrov Aug 09 '17 at 18:58
  • 1
    @AlexanderPetrov Obviously printPlayer does have some relation to BlackJackGame, it takes a Player instance generated by BlackJackGame.play() - this is a relation obviously. You split code when you feel this is the right thing to do, this could be hard to decide, so some programmers like to split everything eager, but in my opinion you need to find a golden ratio for that activity. – Krzysztof Cichocki Aug 09 '17 at 19:02
  • 1
    "How thing would have looked like then" : it would have looked such that professional nitpickers would start nagging you with "this should have been an instance method" and even outright *reject* your code when they are in a reviewing role. – Erwin Smout Aug 09 '17 at 19:02
  • @ErwinSmout Crap :D :D :D :D – Alexander Petrov Aug 09 '17 at 19:03
  • @Krzysztof Cichocki "golden ratio" : 1.618 ??? (sorry, couldn't resist). – Erwin Smout Aug 09 '17 at 19:04
  • @ErwinSmout yes, if you think that it is a good ratio to split the code :D The thing with code is - it needs to be easy to maintain, that means it needs to be easy to read and understand by other programmers more than following any rules or patterns. The rules are to help with achieving readablity, but rarely are absolute. – Krzysztof Cichocki Aug 09 '17 at 19:14
  • Preaching to the choir ! – Erwin Smout Aug 09 '17 at 22:19