Lập trình hướng đối tượng: getters / setters hoặc tên logic

Tôi hiện đang nghĩ về một giao diện cho một lớp tôi đang viết. Lớp này chứa các kiểu cho một ký tự, ví dụ: cho dù ký tự đó được in đậm, in nghiêng, gạch chân, v.v. Tôi đã tranh luận với chính mình trong hai ngày liệu tôi có nên sử dụng getters / setters hoặc tên logic cho các phương thức thay đổi giá trị thành những phong cách này. Mặc dù tôi có xu hướng thích các tên logic, nhưng điều đó có nghĩa là viết mã không hiệu quả và không logic. Tôi sẽ cho bạn một ví dụ.

Tôi đã có một lớp CharacterStylesmà có các biến thành viên bold, italic, underline(và một số người khác, nhưng tôi sẽ rời chúng ra để giữ cho nó đơn giản). Cách dễ nhất để cho phép các phần khác của chương trình truy cập vào các biến này, là viết các phương thức getter / setter, để bạn có thể làm styles.setBold(true)và styles.setItalic(false).

Nhưng tôi không thích điều này. Không chỉ bởi vì nhiều người nói rằng getters / setters phá vỡ sự đóng gói (nó thực sự tệ đến vậy sao?), Mà chủ yếu là vì nó có vẻ không hợp lý với tôi. Tôi hy vọng sẽ tạo kiểu cho một nhân vật thông qua một phương thức, styles.format("bold", true)hoặc một cái gì đó tương tự, nhưng không phải thông qua tất cả các phương thức này.

Dù vậy vẫn có một vấn đề. Vì bạn không thể truy cập biến thành viên đối tượng theo nội dung của chuỗi trong C ++, tôi sẽ phải viết một thùng chứa if-statement / switch lớn cho tất cả các kiểu hoặc tôi sẽ phải lưu trữ các kiểu trong một mảng kết hợp ( bản đồ).

Tôi không thể tìm ra cách tốt nhất là gì. Một khoảnh khắc tôi nghĩ rằng tôi nên viết getters / setters, và khoảnh khắc tiếp theo tôi nghiêng về phía khác. Câu hỏi của tôi là: bạn sẽ làm gì? Và tại sao bạn lại làm vậy?

Có, getters / setters thực hiện đóng gói phá vỡ - về cơ bản chúng chỉ là một lớp bổ sung giữa việc truy cập trực tiếp vào trường bên dưới. Bạn cũng có thể chỉ cần truy cập trực tiếp.

Bây giờ, nếu bạn muốn các phương thức phức tạp hơn để truy cập vào trường, điều đó hợp lệ, nhưng thay vì phơi bày trường, bạn cần phải nghĩ phương thức nào mà lớp sẽ cung cấp thay thế. I E. thay vì lớp Ngân hàng có giá trị Tiền được hiển thị bằng tài sản, bạn cần nghĩ loại truy cập nào mà đối tượng Ngân hàng nên cung cấp (thêm tiền, rút ​​tiền, lấy số dư) và thực hiện thay thế. Một thuộc tính trên biến Money chỉ khác về mặt cú pháp so với việc hiển thị trực tiếp biến Money.

DrDobbs có một bài viết nói nhiều hơn.

Đối với vấn đề của bạn, tôi có 2 phương thức setStyle và clearStyle (hoặc bất cứ điều gì) có thể liệt kê các kiểu có thể. Một câu lệnh chuyển đổi bên trong các phương thức này sau đó sẽ áp dụng các giá trị liên quan cho các biến lớp thích hợp. Bằng cách này, bạn có thể thay đổi biểu diễn bên trong của các kiểu thành một kiểu khác nếu sau đó bạn quyết định lưu trữ chúng dưới dạng một chuỗi (ví dụ để sử dụng trong HTML) - một cái gì đó sẽ yêu cầu tất cả người dùng của lớp của bạn cũng phải thay đổi nếu bạn sử dụng nhận / đặt thuộc tính.

Bạn vẫn có thể bật chuỗi nếu bạn muốn nhận các giá trị tùy ý, có câu lệnh if-then lớn (nếu có một vài trong số chúng) hoặc ánh xạ các giá trị chuỗi sang con trỏ phương thức bằng std :: mem_fun (hoặc std :: hàm ) vì vậy "bold" sẽ được lưu trữ trong khóa bản đồ với giá trị của nó là sts :: mem_fun thành phương thức đặt biến đậm thành true (nếu các chuỗi giống như tên biến thành viên, thì bạn cũng có thể sử dụng macro xâu chuỗi để giảm số lượng mã bạn cần viết)

Một ý tưởng bạn có thể không cân nhắc là Mẫu trang trí . Thay vì đặt cờ trong một đối tượng và sau đó áp dụng các cờ đó cho bất cứ điều gì bạn đang viết, bạn bọc lớp thực hiện cách viết trong Trình trang trí, lần lượt áp dụng các kiểu.

Mã gọi không cần biết có bao nhiêu trong số các hàm bao này bạn đặt xung quanh văn bản của bạn, bạn chỉ cần gọi một phương thức trên đối tượng bên ngoài và nó gọi xuống ngăn xếp.

Đối với một ví dụ mã giả:

class TextWriter : TextDrawingInterface {
    public:
        void WriteString(string x) {
            // write some text somewhere somehow
        }
}

class BoldDecorator : TextDrawingInterface {
    public:
        void WriteString(string x) {
            // bold application on
            m_textWriter.WriteString(x);
            // bold application off
        }

        ctor (TextDrawingInterface textWriter) {
            m_textWriter = textWriter;
        }

    private:
        TextWriter m_TextWriter;
}

Và như vậy, cho mỗi phong cách trang trí. Trong cách sử dụng đơn giản nhất, bạn có thể nói

TextDrawingInterface GetDecoratedTextWriter() {
    return new BoldDecorator(new ItalicDecorator(new TextWriter()));
}

Và mã gọi phương thức này không cần biết chi tiết về những gì nó nhận được. Miễn là SOMETHING có thể vẽ văn bản thông qua phương thức WriteString.

Tôi nghiêng về giải pháp thứ hai. Nó trông thanh lịch và linh hoạt hơn. Mặc dù thật khó để tưởng tượng các loại khác ngoài đậm, in nghiêng và gạch chân (gạch chân?), Sẽ rất khó để thêm các loại mới bằng cách sử dụng các biến thành viên.

Tôi đã sử dụng phương pháp này trong một trong những dự án mới nhất của tôi. Tôi có một lớp có thể có nhiều thuộc tính boolean. Số lượng và tên của các thuộc tính có thể thay đổi theo thời gian. Tôi lưu trữ chúng trong một từ điển. Nếu một thuộc tính không có mặt tôi giả sử giá trị của nó là "sai". Tôi cũng phải lưu trữ một danh sách các tên thuộc tính có sẵn, nhưng đó là một câu chuyện khác.

Tôi nghĩ rằng bạn đang suy nghĩ quá mức vấn đề.

styles.setBold(true) và styles.setItalic(false)ổn