Do getter and setter methods violate the Single Responsibilty Principle

class Rectangle {
    private int width;
    private int height;

    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }

    public void setWidth(int width){
        this.width = this.width;
    }
    
    public void setHeight(int height){
        this.width = width;
    }
    public int calculateArea() {
        return width * height;
    }

Does this class adhere to the single responsibility principle? From what I understand the SRP states that a class should have only one reason to change. I've read that a good rule of thumb for the SRP is, that if you state the responsibility of your class and you can do that without using the word AND then your class is fine.

However this class has the responsibility of representing a rectangle AND providing methods for setting the width&height AND calculate the Area of the rectangle.

Questions

1. Can this be seen as all the same responsibility of just handling different rectangle related things or does this code actually violate SRP? If so in what way, is it just the calculateArea method that violates the SRP or do the setters/getters also violate SRP?

2. Also is the SRP something that must always be followed, or is it more a guideline that should be considered as much as possible, but if it doesn't fully check out thats alright as well?

3. Doesn't strictly adhering to SRP cause a lot of very small classes, which makes it difficult to keep track in bigger projects?

I would be careful with SRP as Bob Martin introduces it as it doens't make much sense when you look straight at it. It's perfectly fine to have a class that has many reasons for change as long as they are abstracted correctly and are those responsibilities are cohesive. To add to this, good designers usually mention that a class usually have around 2-3 responsibilites. A good book to read on design is Object Design: Roles, Responsibilities, and Collaborations, it's 20 years old but the concepts are still 100% relevant. I would also suggest to watch Kevlin Hennely presentation(s) on deconstructing SOLID.

The problem with setters in particular as in the example above is that nothing is validating that the values are correct. What if I set the width as 0 or negative? This example is trivial and already poses some issues. If you have a class with a few more attributes, validating that the class is always consistent might become quite complex.

about your questions

1. The calculate area is in the right place. Setters are very often bad.
2. Again, SRP from Uncle Bob makes no sense. It's important to define what responsibilities a class has and be concious as one is growing those classes and have a feeling of what goes in and what should go somewhere else. And also when refactor and extract a responsibility.
3. A lot of small classes is not a problem. The problem is the ability to have a good overview of the system in an easy way. A lot of small classes might help or hinder this.

I think this is an overly strict interpretation of the single responsibility principle. This class stores the dimensions of a rectangle and the fact that they're mutable is probably inconsequential - that's just Java for you. The only "real" functionality this class has is to calculate the rectangle's area, and the only reason for it to change is if you invent a new type of math that has a different way of finding a rectangle's area.

I'm not aware that Bob Martin himself has said, "without using the word AND." The problem with that (over-) simplification is I can describe any class with or without the word AND by describing it at different levels of abstraction; so I don't find that particular phrasing helpful.

> Can this be seen as all the same responsibility of just handling different rectangle related things...

Yes.

> ...or does this code actually violate SRP?

No.

> Also is the SRP something that must always be followed...

I'm always curious what sort of answer people imagine when asking a question like this. Do they expect to hear yes, this is an ironclad law that must never be broken else the software police will lock you away? Of course the only answer you will ever receive to this type of question is, use your judgement and violate the pattern when necessary. But I suspect the questioners already know this and are merely seeking permission to do what they wanted all along.

> Doesn't strictly adhering to SRP cause a lot of very small classes...

Clean Code (page 139)
> Many developers fear that a large number of small, single-purpose
classes makes it more difficult to understand the bigger picture. They are concerned that
they must navigate from class to class in order to figure out how a larger piece of work gets
accomplished.
>
>However, a system with many small classes has no more moving parts than a system
with a few large classes. There is just as much to learn in the system with a few large
classes. So the question is: Do you want your tools organized into toolboxes with many
small drawers each containing well-defined and well-labeled components? Or do you want
a few drawers that you just toss everything into?