|
Malevolence -> RE: Thoughts on the new "pull" system in logistics (7/7/2020 4:00:21 AM)
|
quote:
ORIGINAL: Vic
About to post some further refinements to the new Logistics tools.
quote:
for v1.04-beta4:
Fixed issue with Custom Pull Points not working if Automatic Points were disabled
Limit Production now also limits Asset auto Pull Points.
Fixed issue with Auto Asset Pull Points not taking branching into account
Added the option to distinguish between Additive Custom Pull Points and Overruling Pull Points.
Added the option to set a Hex-based order if the Traffic Signs apply to Truck Logistics, Rail Logistics or Pull Points (or a combination)
I think we are getting close to wrapping this up.
The Traffic Sign Window might have gotten a bit busy, but except for bugs with this new system I am going to move on now to better explaining to the player with logistics problems WHY his Unit/Asset/Zone has a problem. I want to make it easier for the player to understand what the issue is, if he has one. They are separate concerns, despite being summed into LP's during turn resolution.
There is still however some work to be done finishing up the rules around the new Pull Points. Especially in the interaction between Truck and Rail Logistics.
Best wishes,
Vic
I still recommend separating that window into three tabs on the control side (left). Use one for each method of assigning/prioritize LP's... rail, truck, pull. Make it unambiguous and explicit for players.
Bonus, you will be ready when it comes time to add air and sea delivery too.
quote:
ORIGINAL: Wiki
The Interface Segregation Principle was first used and formulated by Robert C. Martin while consulting for Xerox. Xerox had created a new printer system that could perform a variety of tasks such as stapling and faxing. The software for this system was created from the ground up. As the software grew, making modifications became more and more difficult so that even the smallest change would take a redeployment cycle of an hour, which made development nearly impossible.
The design problem was that a single Job class was used by almost all of the tasks. Whenever a print job or a stapling job needed to be performed, a call was made to the Job class. This resulted in a 'fat' class with multitudes of methods specific to a variety of different clients. Because of this design, a staple job would know about all the methods of the print job, even though there was no use for them.
The solution suggested by Martin utilized what is today called the Interface Segregation Principle. Applied to the Xerox software, an interface layer between the Job class and its clients was added using the Dependency Inversion Principle. Instead of having one large Job class, a Staple Job interface or a Print Job interface was created that would be used by the Staple or Print classes, respectively, calling methods of the Job class. Therefore, one interface was created for each job type, which was all implemented by the Job class.
IRailPointsController, ITruckPointsController, IPullPointsController.
Same reason your UI is using model-view-viewmodel.
|
|
|
|
