Читаючи жахливу статтю про недоліки ООП на користь якоїсь іншої парадигми, я натрапив на приклад, з яким я не можу знайти занадто багато помилок.
Я хочу бути відкритими до аргументів автора, і хоча я теоретично можу зрозуміти їхні точки, але, наприклад, мені важко намагатися уявити, як це було б краще реалізовано, скажімо, на мові ПС.
// Consider the case where “SimpleProductManager” is a child of
// “ProductManager”:
public class SimpleProductManager implements ProductManager {
private List products;
public List getProducts() {
return products;
}
public void increasePrice(int percentage) {
if (products != null) {
for (Product product : products) {
double newPrice = product.getPrice().doubleValue() *
(100 + percentage)/100;
product.setPrice(newPrice);
}
}
}
public void setProducts(List products) {
this.products = products;
}
}
// There are 3 behaviors here:
getProducts()
increasePrice()
setProducts()
// Is there any rational reason why these 3 behaviors should be linked to
// the fact that in my data hierarchy I want “SimpleProductManager” to be
// a child of “ProductManager”? I can not think of any. I do not want the
// behavior of my code linked together with my definition of my data-type
// hierarchy, and yet in OOP I have no choice: all methods must go inside
// of a class, and the class declaration is also where I declare my
// data-type hierarchy:
public class SimpleProductManager implements ProductManager
// This is a disaster.
Зауважте, що я не шукаю спростування аргументів письменника або проти "Чи є якась раціональна причина, чому ці 3 поведінки повинні бути пов'язані з ієрархією даних?".
Що я конкретно запитую, - як би цей приклад був змодельований / запрограмований мовою FP (фактичний код, а не теоретично)?
44
Ви не можете з розумом розраховувати порівнювати будь-які парадигми програмування на таких коротких і надуманих прикладах. Кожен тут може придумати вимоги до коду, які дозволяють зробити власну переважну парадигму краще, ніж відпочинок, особливо якщо вони реалізують інші неналежним чином. Тільки коли у вас є реальний, великий, мінливий проект, ви можете отримати уявлення про сильні та слабкі сторони різних парадигм.
—
Ейфорія
Немає нічого про програмування ОО, що передбачає, що ці 3 методи повинні поєднуватися в одному класі; аналогічно немає нічого про програмування OO, що наказує, що поведінка повинна існувати в тому ж класі, що і дані. Тобто за допомогою програмування ОО ви можете помістити дані в той самий клас, що і поведінка, або розділити їх на окрему сутність / модель. в будь-якому випадку, OO нічого насправді не може сказати про те, як дані повинні стосуватися об'єкта, оскільки концепція об'єкта в основному стосується моделювання поведінки шляхом групування логічно пов'язаних методів у клас.
—
Бен Коттрелл
Я отримав 10 речень у цій розпусті статті і здався. Не звертайте уваги на людину за цією завісою. Іншими новинами я не мав уявлення, що справжні шотландці - це насамперед програмісти ООП.
—
Роберт Харві
Ще одна розпуста від того, хто пише процедурний кодекс мовою ОО, то дивується, чому ОО не працює на нього.
—
TheCatWhisperer
Хоча це, безсумнівно, правда, що OOP - це катастрофа дизайнерських помилок від початку до кінця - і я пишаюся тим, що є її частиною! - ця стаття не читабельна, і приклад, який ви наводите, в основному робить аргумент про погано розроблену ієрархію класів.
—
Ерік Ліпперт