In addition to forsvarir's answer, especially the "always True" aspect, I'd like to give an additional reason why to change that.
Your parkBigCar() method (and its siblings) is only legal to be called after isPlaceForBigCar() has been checked and returned true. You surely know that today and wrote all your calls appropriately, but if ...
There's a lot of this. references in your code. Typically in Java you only use this. where you need to in order to disambiguate variables. Consider removing them as they're only adding noise to your code.
Your park methods all return boolean, even though they all always return true. If you want to maintain the same approach, consider ...
@Jeremy Hunt's great answer has covered an approach that will make your classes more testable. I'm just going to add a few other things to think about, with your existing code.
You're naming your tests using a given..when..then approach. If that's your preference, then you may want to consider using Mockito's BDD extensions which might ...
Don't force unnecessary bounds on your trait
You're requiring many bounds on your trait that simply aren't necessary. For example, it's nice to have the Debug trait so you can easily print out debug information, but you're currently having that as a requirement in order to implement your trait List. So try to reduce the trait bounds to just what's necessary ...
Title idea: How to refactor simple API Client code in PHP CLI
Here are a couple of tips:
I would add if's and switch'es as soon as possible. For example, you are setting fields and headers of Request::class inside it, just before the execution of cURL request. Why not at Request::class' creation time? Refactor your factory to add correct parameters at ...
In this post let me focus on the project structure.
Project vs Projects
Most of the time when we implement a n-tier application we separate each tier into its own project. We also separate implementation and abstraction. Some like this:
I agree with the advice presented by @slepic.
The capacity can be passed as a parameter when a bookshelf is created. The current code treats that capacity as a constant.
If you were to keep that capacity as a property that isn’t asssigned vía constructor method, that value could be set when the property is declared, eliminating the need for the constructor:
Is that really how a bookshelf work?
"Hello Magic Bookshelf, report status!"
"Bookshelf contain 0 items, remaining capacity is 3"
"Ok, spawn a new item!"
"Ok give me item 0!"
"Here it is, it is The C Programming Language by keringhan & Ritchie"
"Got it. Please spawn another item"
Disclaimer: I'm currently the maintainer of python-telegram-bot.
TBH I haven't tried to understand every detail of what you presented. I'd still like to comment on the design you chose to use methods of your custom classes as callbacks. More precisely I find it rather irritating that you define methods like