Như chúng ta đã biết, SRP tuyên bố rằng mỗi lớp nên có trách nhiệm duy nhất và trách nhiệm đó phải được gói gọn trong lớp.
Nhưng setters và getters không phục vụ một trách nhiệm khác - họ thực hiện truy cập thuộc tính lớp dữ liệu (dữ liệu) trừu tượng.
nếu Setters và getters thực hiện truy cập thuộc tính lớp trừu tượng, thì chúng sẽ phục vụ một trách nhiệm khác .
Vì vậy, nếu tôi có một cái gì đó như thế này,
class Config
{
private location;
public function write(array $data)
{
....
}
public function read($key)
{
...
}
public function exists($key)
{
...
}
public function delete($key)
{
...
}
// Below comes property abstraction
// Here I doubt - I CANNOT USE this class without them
// but they seem to break the SRP at the same time!?
public function setFileLocation($location)
{
$this->location = $location;
}
public function getFileLocation()
{
return $this->location;
}
public function setConfigArray(...)
{
...
}
public function getConfigArray()
{
...
}
}
Tôi phá vỡ SRP. Vấn đề là, đó là cách duy nhất lớp có thể tồn tại.
Vì vậy, câu hỏi là
Trong tình huống của tôi, hầu như không thể tránh setFileLocation()và getFileLocation()phương pháp với CRUD.
Vì vậy, nếu bằng cách kết hợp các phương thức CRUD với trừu tượng truy cập dữ liệu, tôi sẽ phá vỡ SRP,
Có cách nào để tôi có thể tuân thủ SRP và giữ khái niệm chung về lớp Cấu hình (hoạt động CRUD) cùng một lúc không?