Các lớp tĩnh với các phương thức tĩnh có được coi là RẮN không?

RẮN bao gồm công cụ thay thế Liskov có khái niệm rằng các đối tượng trong một chương trình nên có thể thay thế bằng các thể hiện của các kiểu con của chúng mà không làm thay đổi tính chính xác của chương trình đó.

Vì các lớp tĩnh với các phương thức tĩnh (hơi giống với Mathlớp) hoàn toàn không có các thể hiện, nên hệ thống của tôi có được coi là RẮN nếu tôi có các lớp tĩnh với các phương thức tĩnh không?

language-agnostic solid static-access

— Pacerier
nguồn

Tôi nghĩ rằng câu hỏi này là tuyệt vời. Hãy xem những gì cộng đồng cung cấp.

— Saeed Neamati

Một lớp Toán không bao gồm nhà nước. Vì vậy, bạn không bao giờ thực sự vượt qua các đối tượng loại này xung quanh. Vì vậy, tôi không chắc làm thế nào điều này thậm chí có liên quan.

— Martin York

Tôi không nghĩ các lớp tĩnh thực sự có thể được coi là RẮN thuần túy (phần lớn vì một số lý do tương tự như đã đề cập) tuy nhiên tôi sẽ coi chúng là một công cụ và công cụ tuyệt vời cho nguyên tắc DRY.

— dreza

Làm sao vậy Từ kinh nghiệm của tôi, việc lạm dụng các lớp tĩnh hầu hết dẫn đến việc mọi người lặp đi lặp lại mọi lúc với một nửa mã thao túng vĩnh viễn một đối tượng thần tĩnh toàn cầu.

— back2dos

Tôi đoán tôi đang suy nghĩ nhiều hơn về các lớp tiện ích để cung cấp mã chung. Tôi đồng ý rằng chúng dễ sử dụng và thường bị sử dụng sai nhưng vẫn nghĩ rằng có thể cung cấp các phương tiện hữu ích để nhóm lại mã chung trong đó trạng thái không phải là vấn đề

— dreza

Câu trả lời:

LSP áp dụng để chuyển một thể hiện của một lớp vào một phương thức, có phương thức thực hiện một số nội dung với thể hiện đó và thường tạo ra một số loại kết quả. Điều này không quan trọng đối với các lớp tĩnh vì trong C #, bạn không thể tạo một thể hiện của lớp tĩnh.

Thậm chí quan trọng hơn, các lớp tĩnh được niêm phong và do đó không thể được kế thừa. Điều này làm cho câu hỏi của bạn không còn xa nữa khi C # đi.

Bạn có thể nói rằng các lớp tĩnh luôn tuân thủ LSP vì bạn không bao giờ có thể tạo ra một lớp con vi phạm nguyên tắc đó. Bạn cũng có thể nói rằng các lớp tĩnh không bao giờ tuân thủ LSP vì lý do tương tự.

Trong Java, các lớp tĩnh hơi khác nhau. Bạn không thể đánh dấu một lớp cấp cao nhất là "tĩnh", vì vậy nếu bạn muốn tạo một lớp tiện ích tương tự như các lớp tĩnh của C #, bạn phải khai báo nó dưới dạng finalvà ẩn hàm tạo của nó. Tuy nhiên, khi bạn làm điều đó, chúng hoạt động tương tự như C # - bạn không thể khởi tạo chúng hoặc phân lớp chúng. Bạn có thể khai báo một lớp bên trong là static, nhưng điều đó không có nghĩa giống như trong C #: nó chỉ đơn giản là biểu thị một lớp cấp cao nhất lồng nhau .

VB.NET hoạt động chính xác giống như C # trong trường hợp này, theo như tôi biết.

Bạn đã không đề cập đến việc bạn có quan tâm đến các nguyên tắc khác hay không, nhưng dù sao tôi cũng sẽ đưa chúng vào để hoàn thiện chúng.

Nguyên tắc trách nhiệm của S ingle : một lớp tĩnh dễ dàng tuân theo nguyên tắc này.
O bút / nguyên tắc khép kín : từ lớp tĩnh được niêm phong, họ có thể không bao giờ làm theo nguyên tắc này. Nguyên tắc thay thế
L iskov : như trên.
Tôi nói trước nguyên tắc phân tách : không áp dụng cho một lớp duy nhất, nhưng tách một lớp tĩnh lớn thành các lớp nhỏ hơn, chuyên biệt hơn có thể là một bước để tuân theo nguyên tắc này. Nguyên tắc đảo ngược
D ependency : các lớp tĩnh không thể thực hiện các giao diện, vì vậy bất kỳ lớp nào sử dụng nó sẽ luôn phụ thuộc vào bất kỳ triển khai nào tồn tại vào thời điểm đó. Do đó các lớp tĩnh vi phạm nguyên tắc này.

Vì các lớp tĩnh không thỏa mãn cả 5 tiêu chí, nên chúng không RẮN.

— Adam Lear
nguồn

vì là RẮN có nghĩa là chúng ta phải đáp ứng tất cả 5 tiêu chí, điều đó không có nghĩa là chúng không RẮN?

— Pacerier

@Pacerier Có, nhưng người ta không nên cố gắng chuyển một lớp thành RẮN mọi lúc nếu không cần thiết; nó phụ thuộc vào bối cảnh của lớp học. Nếu đó là một lớp tiện ích hoặc một cái gì đó, thì IMO không phải là "RẮN", nhưng nếu đó là một lớp miền thực tế có sử dụng tên miền cụ thể ...

— Wayne Molina

Tôi sẽ không phân loại một lớp như là hướng đối tượng và do đó tôi sẽ nói rằng nó không thể (và không nên cố gắng) đáp ứng các nguyên tắc của thiết kế hướng đối tượng.

Các lớp này chỉ đơn thuần là một cách giải quyết cho việc không thể cung cấp mã bên ngoài một lớp bằng các ngôn ngữ như Java và C #. Nếu có thể, chúng nên được định nghĩa là các hàm độc lập vì chúng không thu được bất kỳ lợi ích nào từ hướng đối tượng.

— Gyan aka Gary Muan
nguồn

Tôi sẽ không đồng ý với việc đặt các chức năng độc lập bên ngoài lớp học. Khả năng đơn giản để nhóm các chức năng liên quan (tĩnh hoặc không) dưới một tên chung là hữu ích cho khả năng đọc. Các hàm toán học phù hợp hoàn hảo với hóa đơn.

— jojo

@jojo Đồng ý. Các ngôn ngữ hỗ trợ các hàm được định nghĩa bên ngoài các lớp cũng hỗ trợ nhóm logic các hàm này, ví dụ như các không gian tên trong C ++.

— Gyan aka Gary Buyn

Điều đáng nói, vì bạn đã chỉ định không có ngôn ngữ, nên trong C ++, bạn có thể vượt qua các lớp chỉ có thành viên tĩnh và truy cập các thành viên đó qua khuôn mẫu, và do đó có thể thay thế một lớp chỉ có thành viên tĩnh và có thể cho rằng các phương thức gọi là "giao diện".

— DeadMG
nguồn

vb.net / c # / java

— Pacerier