Hi there,
Tớ nghĩ cậu đúng khi nghi ngờ điều này. Câu trả lời cho cậu là: có, design của cậu có phá hỏng 1 số tính chất của OO design 
Design này có vấn đề gì?
Ở class Validation
, tất cả các method của cậu đều là public static
method. Static method như cậu biết, là hành vi không gắn liền với bất cứ object nào. Hiển nhiên, việc này phá hỏng điều quan trọng nhất của OO design: hướng về đối tượng 
Ở class Fighter
, cậu cũng có 1 loạt hằng số, nhưng nó cũng public static
nốt. Điều này phá hỏng tính đóng gói (encapsulation), khi những object khác có thể tùy ý truy cập vào những thông tin riêng tư của Fighter
. Thử tưởng tượng điều này xảy ra trong đời thường, hẳn các object khác sẽ bị bế hết lên đồn 
Làm thế nào để sửa design trên theo OOP
Ở class Validation
, cậu có thể áp dụng tính chất tổng quát hoá, design 1 flow chuẩn cho việc validate, và áp dụng tính đa hình để định nghĩa riêng cách validate cho từng bài toán cụ thể.
public interface Validation<T> {
/**
* Validate against a particular instance, and throw ValidationException when it is invalid.
*
*/
void validate(T instance) throws ValidationException;
}
//...
public class ValidDefendValidator implements Validation<Integer> {
// Overide the validate method here
}
Ở bên class Fighter
, cậu nên để hằng số private, và đưa ra getter nếu cần, hoặc tách toàn bộ phần hằng số này ra 1 class Configuration
nào đó, và cung cấp method getConfig
với tham số configName
nào đó.
Khi nào cậu cần thông tin config “MAX_HEALTH”, cậu chỉ cần lịch sự hỏi object Configuration
:
Configuration.getInstance().getConfig("MAX_HEALTH");
Khi đó, Configuration sẽ đưa cho cậu thông tin cậu cần
Điểm khác biệt nằm ở thái độ của một quý ông, khi cậu không phải xông vào nhà Fighter
và lấy đi bí mật thầm-kín-nhưng-bị-public của nó, mà lịch sự hỏi Configuration
xem cậu ấy có thể giúp không.
Có nên sửa design trên theo OOP không?
Hì hì.
Như cậu thấy ở trên, sửa design theo OOP trông khá nice, nhưng sẽ khá tốn công. Vậy nên, cậu cần phải thực sự cân nhắc điều này: cậu cần 1 design trông đơn giản, và hiệu quả, hay cậu cần 1 design chặt chẽ, đúng, nhưng cực kỳ tốn công để tạo ra và maintain?
Như Lão Hạc có đề cập ở trên, đó thực ra là 1 quan điểm rất thực tế, và tớ không thể đồng ý hơn
.
Cá nhân tớ không có vấn đề gì với class Validation
của cậu. Nó đơn giản và hiệu quả (miễn là cậu không để static method ở các chỗ khác, hoặc class này nằm trong framework mà bên cậu đang sử dụng, thứ nên được design 1 cách trừu tượng
). Class Fighter
tớ cũng không có vấn đề gì, trừ khi có object khác đọc thông tin MAX_HEALTH
thật 
Vậy nên, cậu sẽ nên là người quyết định, tùy vào tình huống mà có design phù hợp.
Hope it helps!